“The future always arrives too soon, and in the wrong order.” This just blew me away.
(And yes, I should be putting together a mid-term, revising the Software Carpentry course notes, catching up on book reviews for DDJ, and looking for a job—what’s your point?)
I have a new theory. It’s not about why there are no toilets on the Enterprise (hint: transporters). This one’s about why bad software exists.
Fact #1: the two biggest causes of software failure are requirements failure and integration failure: either the wrong thing is built, or the pieces don’t work together when they’re assembled.
Fact #2: the only way to get and check requirements, and to make sure that the Fred and Jane’s code will play nicely together, is in live discussion. (I’m sorry, but email just doesn’t cut it.) That means (drum roll) have meetings.
Fact #3: most people are really bad at meetings — they don’t have an agenda going in, they don’t take minutes, they waffle on or wander off into irrelevancies, they repeat what others have said or recite banalities simply so that they’ll have said something, they hold side conversations (which pretty much guarantees that the meeting will be a waste of time), and so on.
Conclusion: people create bad software because they’re bad at meetings.
Corollary: improve people’s meeting skills, and you’ll improve the software they produce.
So, here are Greg’s Rules for Good Meetings:
And that’s it. Run all your meetings like this for a month, with the goal of making each of them one minute shorter than the preceding one, and I promise that you’ll build better software.
Uncategorized
Following links from the latest Subtext demo, I came to Martin Fowler’s article “Language Workbenches: The Killer-App for Domain Specific Languages?”. It’s well written and thought provoking, like everything else Martin writes, but I think there’s one glaring oversight. Two thirds of the way through, he says:
…there are three main parts to defining a new DSL [Domain Specific Language]:
- Define the abstract syntax, that is the schema of the abstract representation.
- Define an editor to let people manipulate the abstract representation through a project.
- Define a generator. This describes how to translate the abstract representation into an executable representation. In practice the generator defines the semantics of the DSL.
That’s great — but #4 should have been:
- Create an inspector that allows people to debug their DSL’s behavior in its own terms.
Now, you could claim that the debugger was implied by #2 (the editor), but i practice, it never works that way. Time and again, I see people struggling with systems that don’t provide tools for debugging: Makefiles, Antfiles, config.xml files for servlet containers, and on and on and on. When something goes wrong, the only options are (a) tweak it until it converges on what you wanted, or (b) debug the implementation of the nice abstraction you were just thinking in.
I think that the inability of today’s C++ debuggers to display something useful when confronted with templated code is the singlest biggest obstacle to their wider use. I think that Java made a horrible mistake in deciding to erase type information when compiling generics, so that what’s actually executing can only say, “Yup, it’s another Object.” Extensible languages could revolutionize software development, but it’ll only happen if we focus on closing the debugging gap.
So, anyone looking for a Ph.D. topic? 
Wondering what to read next? Try whichbook.net. Proof (if more was needed) that everything is still up for grabs when it comes to social interfaces…
Even Google sometimes gets it wrong—this map of participants in the Summer of Code has me in eastern Kazakhstan. It also appears to have me working for Google, which is just cruel…
(Thanks to Greg Lapouchnian for sending the image.)
No, I’m not having morbid thoughts (well, not that morbid)—it’s a quote from Charles Petzold’s talk Does Visual Studio Rot the Mind?, which is well worth a read.
Want to see where Google Summer of Code participants were from? Now you can.
Uncategorized
There’s a new demo of Jonathan Edwards’ Subtext system online. This is the best example I’ve seen yet of an extensible programming system. It’s pretty cool—once you stop insisting that programs have to be directly presentable as ASCII strings, many new thoughts become possible.
Quote: “It’s good to remember that with practice, you can even learn to read Perl. Humans are not good at abstract thinking, but they’re great at pattern recognition. I think it’s a win to trade one for the other.”
(And to follow up on the “many new thoughts become possible” meme, I once saw a talk by Richard Dawkins on “The Evolution of Evolvability”. Dawkins’ thesis was that some evolutionary changes give evolution new things to act on—segmented bodies, for example, allow for specialization of segments and limbs. Code-in-database systems almost certainly have this property.)
I didn’t go to OOPSLA this year (OK, I’ve never gone to OOPSLA, despite meaning to several times), but from what I’m reading, one of the most entertaining events was the Scrapheap Challenge, in which participants were given a problem to solve by downloading freely-available code from the Internet and gluing it together. Some people have started referring to this as “post-modern programming” (PM because no one creates anything new any more, we just remix what’s already been done). I wonder what kind of third-year programming assignment it would make? Or, a better question, I wonder what kind of course we could teach for which this would be a natural programming assignment?
For the past few weeks, Heather Mayer has been turning my scratchings into some really rather beautiful drawings for the Software Carpentry course. If you’d like to see more of her work, Pyre is now hosting her site. And if you’re looking for a graphic designer, I’d recommend her highly.
Recent Comments