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
design. 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
abstrations and hence require fewer developer
resources to implement. That’s the
only way we’re going to get past the fundamental problems of complexity and expense.
You must be logged in to post a comment.
- MartijnOK, 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.
- Log in to Reply
- November 24, 2003 at 8:11 pm
- DanielSo what are your thoughts on this:
http://www.fastcompany.com/online/06/writestuff.htmlcan NASA can get perfect software ?
- Log in to Reply
- “This software never crashes. It never needs to be re-booted. This software is bug-free.”
- November 24, 2003 at 10:02 pm
- silI 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…
- Log in to Reply
- November 25, 2003 at 2:57 am
- Stuart DootsonDaniel – 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.Log in to Reply
- 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).
- November 25, 2003 at 4:15 am
- Peter TorrIt 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.Log in to Reply
- I bet they don’t let the crew watch DVDs or run the SETI screen saver on the same machine that fires the engines 😉
- November 25, 2003 at 12:41 pm
- Mike DimmickThe 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.Log in to Reply
- NASA reportedly had a bit of a crisis recently because they weren’t able to source 8086 processors for the space shuttle computers.
- November 25, 2003 at 2:48 pm
C# Scripting JScript VBScript Language Design COM Programming Rarefied Heights Puzzles Rants Performance Security C# 4.0 Non-computer SimpleScript JScript .NET Immutability Code Quality Pages Recursion Books
- November 2012 (5)
- October 2012 (5)
- September 2012 (2)
- August 2012 (5)
- July 2012 (2)
- All of 2012 (47)
- All of 2011 (66)
- All of 2010 (90)
- All of 2009 (100)
- All of 2008 (43)
- All of 2007 (63)
- All of 2006 (25)
- All of 2005 (97)
- All of 2004 (167)
- All of 2003 (88)