Experience Required

was intrigued by Neil Deakin’s recent post "urn:schemas-microsoft-com:office:office" /> where
he says that when he was a young user, he got mad about all kinds of things that,
after a few years as an implementor, he didn’t feel mad about anymore.


with ya, Neil.  Many of my computer geek
high school friends were rather surprised to learn that I had taken a job at Microsoft,
given my earlier criticisms of all x86 based software.  (I
was an Amiga partisan as a teenager.) I feel the same way you do — I was a naïve


however, doesn’t actually explain why it is that he finds his former beliefs to be
naïve.  I can’t speak for Neil, but I
can take a stab at explaining what the revelation was for me.  Basically
it comes down to realizing two things:  (1)
good design is a series of difficult compromises,
and (2) software is by its nature incredibly complex.  I
failed to appreciate either of those facts until I’d actually done a lot of it myself.  Once
I appreciated these things, I understood that we have imperfect software BECAUSE the
people who make it are dedicated to writing quality software for end users, not in
spite of that fact.


it doesn’t matter what your business model is — open source or closed source, give
away the software and sell consulting, shrink-wrapped boxes, micropayments, freeware,
whatever.  The money story is irrelevant;
all software development is about coming up with an implementable, usable design
for a given group of end users and then
finding enough resources to implement that
.  There are only a finite number
of programmers in the world, and way more problems that need solving than there are
resources available to solve them all, so deciding which problems to solve for what
users is crucial.


— not always, but sometimes — not fixing a trivial, obscure bug with an easy workaround is the
right thing to if it means that you can spend that time working on a feature that
benefits millions of customers. Sometimes features that are useless to you are life-savers
for someone else.  Sometimes — not always,
but sometimes — using up a few more pennies of hard disk space (ten megs costs, what,
a penny these days?) is justifiable.  Sometimes
— not always, but sometimes — proprietary designs allow for a more efficient design
process and hence more resources available for a quality implementation.   These
are all arguable, and maybe sometimes we humans don’t make the _best_ choices.  But
what is naive is to think that these are not hard problems that people think about


I was a teenager, I thought software engineering was trivial — but my end user was
myself, and my needs were simple.  Software
development doesn’t scale linearly!  Complex
software that exists to solve the real-world problems of millions of end-users is
so many orders of magnitude harder to write, that intuitions about the former can
be deeply misleading.


this is true in ALL design endevours that involve tough choices and complex implementations!  I
was watching the production team commentary track for the extendamix of The Two Towers
this weekend, and something that the producers said over and over again was that they
got a lot of flack for even slightly changing the story from the book.  But
before you criticize that choice, you have to really
think through all the implications
of being slaves to the source material.  How
would the movie be damaged by showing Merry and Pippin’s story entirely
in flashback
?  By not interlacing
the Frodo-and-Sam story with the Merry-and-Pippen story?  By
making Faramir’s choice easy? By adding Erkenbrand as the leader of the Westfold?  Yes,
these are all departures from the book, but they also prevent the movie from being
confusing and weak at the end.  None are
obvious — they’re all arguable points, and ultimately someone had to make a tough
decision to produce a movie that wasn’t going to satisfy everyone fully, but would
nevertheless actually ship to customers!


is no perfect software; the world is far too complex and the design constraints are
too great for there to be anything even approaching perfect software.  Therefore,
if you want to ship the best possible software for your users, you’ve got to carefully
choose your imperfections.  As the guy
who writes tools for you software engineers, my mission is to make tools that afford deeper
and hence require fewer developer
to implement.  That’s the
only way we’re going to get past the fundamental problems of complexity and expense.

Comments (6)

  1. Martijn says:

    OK, about that software geek thingie, you are probably right, I can’t tell, but please don’t say they had to make all these changes to the Lord of the Rings book.
    Peter Jackson has a pretty good insight what the books where about, but I think that he has made some fatal errors in the second movie, by changing the story.
    I think the book is all about choices (what do you do when you are confronted with evil/power), and Peter has changed that behavior of some characters in the movy in a really bad way.

  2. Daniel says:

    So what are your thoughts on this:

    "This software never crashes. It never needs to be re-booted. This software is bug-free."

    can NASA can get perfect software ?

  3. sil says:

    I agree entirely that your eyes are opened when you get into collaboratively developing code with a big team and putting together proper stuff rather than one-shot code for yourself, absolutely. However, the shift from user (or one-man coder) to software developer can also bring with it less of a focus on usability, because you forget everything that you didn’t know as that user; some stuff is just so *obvious* as a hacker that it never occurs to you that it’s confusing or non-obvious to others. I’m not necessarily suggesting that you’re guilty of this, Eric, but there’s not a lot of difference between "you don’t understand how putting software together works — you’re naive and should learn" and "you don’t understand how software works — you’re naive and should learn", I feel. Dangerous ground, where it’s easy to sell out those youthful passions and compromise too much…

  4. Stuart Dootson says:

    Daniel – no, NASA cannot get perfect software..or rather, they *may* get perfect software, but they cannot know it – they cannot know if there are still defects in their software, unless they’ve decided to leave them in.

    The other thing to think about is that by deciding to try and minimise the number of bugs in their software, NASA have effectively decided that they are going to spend an awful lot of money on what is effectively a small functionality set. They probably spend 10-100 times what Microsoft (or any other PC software vendor) spend per function point – possibly more. The testing budget is probably 50-60% of the total budget. (and yes, I’m speaking from experience – I’ve developed safety-critical software to DO-178B Level A).

  5. Peter Torr says:

    It would be more correct to say "This software has never crashed". Also Eric is talking about building software for millions of people who do arbitrarily complex things with it, combine it with other arbitrary software and hardware, and so on. The Shuttle group has an incredibly narrow focus for their software: It must launch the shuttle, and that’s it.

    I bet they don’t let the crew watch DVDs or run the SETI screen saver on the same machine that fires the engines ;-)

  6. Mike Dimmick says:

    The space shuttle software also has an extremely limited range of hardware that it has to run on, while Windows has to run on the entire gamut of PC hardware.

    NASA reportedly had a bit of a crisis recently because they weren’t able to source 8086 processors for the space shuttle computers.