Frequently, the mainstream media, reporting on computer programming tools, gets the story horribly wrong.
What happens is that some kind of vendor of programming technologies has come up with some product they are claiming makes programming easier. The journalists don’t really understand. What they hear is “programming is going to be easier.” Usually there’s some kind of Lego allusion.
He then goes on to rip the Lego allusion to shreds. But wait a minute. I think that programming is as easy as snapping together Legos! With modern programming tools, I can drag a button on a form, double click it to get the event handler, write my code, etc. That little toolbox in Visual Studio is just like a bin of legos. Need a timer? Drag one on your form! Need a text box? Hey, there’s a bottomless supply in the toolbox! I wish I had a bottomless supply of those little fiddly Lego gears!
But, I still agree with Joel. In fact, by focusing on the fun, play aspect of Legos, he misses the general form of the analogy: programming is exactly like playing with Legos.
Have you ever seen those giant space shuttles and moonwalk scenes made out of Legos? If you gave me an unlimited pile of Legos in various shades of grey and black, it would take me months and months of fiddling with Legos to make a ten foot replica of the Death Star. And it still wouldn’t be very good. I know my artistic limitations. It would be all oblong and weird shaped, and would generally suck.
But if the folks at Lego wanted to make a ten foot Death Star, they would have a project team. They would break out the modeling software, and spend weeks designing their Death Star before anyone snapped together a couple of grey blocks.
Designing awesome things with Legos and playing with Legos are two different skills, just as being a decent application architect and having basic programming skills are two different things entirely.
Now, my not-quite-main-man-but-still-no-slouch-in-the-man-department Wesner Moise wrote a post
hatin’ on Joel for hatin’ on lego programming. Wesner’s point is that there have been huge strides made in programming tools:
I have written about Silver Bullets in the past and emphatically feel the widely regarded author to be irresponsible and premature in his assessment of there being no silvery bullets, which is leading many developers, not the least of which is Joel, to be unimaginative and pessimistic of advances in software development.
For example, Brooks asserts in the start of his essay this bit of false wisdom:
“There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.”
That assertion turns out to be pure nonsense, amply disproven by numerous advances in IDEs, languages, frameworks, componentization over the past few decades. Our expectations of software and our ability have risen. A year of work takes a month or a month of work takes a day. An order of magnitude improvement usually results in major qualitative changes, often resulting in an existing lengthy project becoming a short task item or a new project suddenly becoming feasible, such as when end users start writing applications (using scripting and RAD tools) that were once exclusively the domain of IT.
Fair enough. He uses the example of making a simple game on the Atari 2600 and he’s right: I can write a pacman clone in an afternoon in C#. It’s probably pretty close to impossible to do that on an Atari 2600.
I mean, is Wesner saying the only differences between Wordstar and Microsoft Word 2007 are due to better programming tools?! Does anyone really want to argue that the Mythical Man Month doesn’t apply to large scale software projects?
I say no: Brooks’s law holds true in the modern age, even with quickly evolving dev tools.