Thursday, December 07, 2006
  Grady Booch called from 2004. He wants his ideas back.
Software development has been, is, and will remain fundamentally hard.
Grady Booch, factories help you produce lots of bad software

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.
Fred P. Brooks, No Silver Bullet

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.”
Ellen Ullman, The dumbing-down of programming, part two

Comments on “Grady Booch called from 2004. He wants his ideas back.:
"The first is to understand the problem and generate an ideal solution in the mind or minds of the programmers. The second is to translate the ideal solution into a language that the computer understands"

That sound very waterfall (first, second) - my experience in programming is rather that of trying to find an ideal representation of the problem in the computer's (conceptual) language. This requires going back and forth, and the computer "helps" me by experimentally or analytically pointing out weaknesses of my program.

I doubt anyone can think the ideal detached from any implementation. Even UML is just a diagrammatic representation of a computer language.
first, second

You're quite right, there is no reason to try to do them in that strict order.

I certainly don't, and I don't know anyone who does... unless you count school exercises where the teacher demands that the students submit "pseudo-code" in advance of submitting working code.

I will edit the prose to eliminate the possibility of misinterpretation.


<< Home
Reg Braithwaite

Recent Writing
Homoiconic Technical Writing / raganwald.posterous.com

What I‘ve Learned From Failure / Kestrels, Quirky Birds, and Hopeless Egocentricity

rewrite_rails / andand / unfold.rb / string_to_proc.rb / dsl_and_let.rb / comprehension.rb / lazy_lists.rb

IS-STRICTLY-EQUIVALENT-TO-A / Spaghetti-Western Coding / Golf is a good program spoiled / Programming conventions as signals / Not all functions should be object methods

The Not So Big Software Design / Writing programs for people to read / Why Why Functional Programming Matters Matters / But Y would I want to do a thing like this?

The single most important thing you must do to improve your programming career / The Naïve Approach to Hiring People / No Disrespect / Take control of your interview / Three tips for getting a job through a recruiter / My favourite interview question

Exception Handling in Software Development / What if powerful languages and idioms only work for small teams? / Bricks / Which theory fits the evidence? / Still failing, still learning / What I’ve learned from failure

The unary ampersand in Ruby / (1..100).inject(&:+) / The challenge of teaching yourself a programming language / The significance of the meta-circular interpreter / Block-Structured Javascript / Haskell, Ruby and Infinity / Closures and Higher-Order Functions

Why Apple is more expensive than Amazon / Why we are the biggest obstacles to our own growth / Is software the documentation of business process mistakes? / We have lost control of the apparatus / What I’ve Learned From Sales I, II, III

The Narcissism of Small Code Differences / Billy Martin’s Technique for Managing his Manager / Three stories about The Tao / Programming Language Stories / Why You Need a Degree to Work For BigCo

06/04 / 07/04 / 08/04 / 09/04 / 10/04 / 11/04 / 12/04 / 01/05 / 02/05 / 03/05 / 04/05 / 06/05 / 07/05 / 08/05 / 09/05 / 10/05 / 11/05 / 01/06 / 02/06 / 03/06 / 04/06 / 05/06 / 06/06 / 07/06 / 08/06 / 09/06 / 10/06 / 11/06 / 12/06 / 01/07 / 02/07 / 03/07 / 04/07 / 05/07 / 06/07 / 07/07 / 08/07 / 09/07 / 10/07 / 11/07 / 12/07 / 01/08 / 02/08 / 03/08 / 04/08 / 05/08 / 06/08 / 07/08 /