Grady Booch called from 2004. He wants his ideas back.
Software development has been, is, and will remain fundamentally hard.
Grady was talking about software factories, components, and yes, even domain-specific languages. Or rather, he was talking about their limitations. There is
No Silver Bullet (the one essay is available for free
here, but the entire book is outstanding).
This does not mean that we can’t
improve the way we write well-understood kinds of software, or that we can’t write
new kinds of software that would have been impossible to write with older ideas and tools. Or that we can’t write software with smaller teams and
less overhead than with older processes and methodologies.
Here’s the deal:
Writing a program requires two activities. One is to understand the problem and generate an ideal solution in the mind or minds of the programmers. The other is to translate the ideal solution into a language that the computer understands (hint: the computer’s favourite ‘words’ are
one and
zero).
The translation activity is overcoming the impedance
mismatch between our thoughts and the machine. Every step we take with tools and languages and processes removes another portion of this “accidental difficulty”. But it does nothing for the fundamental hardness of understanding problems and formulating the solutions.
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.
As many people have pointed out, building software is
exactly like building a building, only:
We are always building a building that has never been built before, with materials that have only just been introduced to the market, on a scale that has never been attempted by our team before, and finally we have completely automated the construction process with our marvelous compilers, so all we have to do is come up with a perfect set of blueprints, and did we mention that the client has never used a building for this exact purpose before, and therefore they have very little idea what they will need until the building has been completed and they can try it out?
But that’s ok. Honestly, if it isn’t hard,
why bother? The point of our languages, our tools, even of sharing our ideas so we can improve is so that we can spend more time on the problems of the problem, rather than the problems of the tools.
In the end, the overall “productivity” of the system, the fact that it came into being at all, was the handiwork not of tools that sought to make programming seem easy, but the work of engineers who had no fear of “hard.”