Building software is not all fun. Some parts of it involve considerable tedium. Robert Glass, in his recent IEEE Software column (unfortunately, subscription required), talks about Bruce Blum’s fun-tedium ratios for various phases of software development. I am sure you can relate to this…
- Phase 1 is selling the idea. Fun-tedium ratio is: 100-0. After all, with a wave of the hand almost any objection can be overcome.
- Phase 2 is developing the requirements statement. Fun-tedium is: 50-50. Understand the problem is the fun part, writing everything down is tedium.
- Phase 3 is high-level design. Goes down to: 40-60. Got to start keeping promises. Also, have to review stuff.
- Phase 4 is detailed design. Gets worse: 33-67. It’s irritating that arm-waving is no longer enough.
- Phase 5 is programming. Fun ratio rise to: 75-25. Coding is fun, why else open source hackers would choose to build software and not get paid for it!
- Phase 6 is testing. Fun plummets again to: 33-67. Relationship with testers becomes adversarial.
- Phase 7 is maintenance. Pure tedium: 0-100. You know why.
In essence, most of the fun is in the idea stage and the coding stage of building software. In one sense, Agile Programming (AP) reinvents the process around these fun parts (if you don’t believe me you just have read their manifesto) to deliver better software and happier programmers.
I have concluded that writing an essay-type blog (like mine) is the AP version of writing a book. In writing a book you have to worry about all this scaffolding (structure, index, references, etc.) that you don’t have to bother with in a blog. You just focus most on the idea and the writing. And since you are interacting with your readership on an ongoing basis, the process is much more living and breathing.
In fact, this parallel between AP based software development and essay-type blog writing goes deeper. Writing, like coding, is pleasurable. Both are immersive and therapeutic. They involve creating something out of nothing that gives an idea a life. Paul Graham, the famous pioneer of web-apps and a practicing programmer and writer (unlike me who gave up any meaningful coding years ago) compares writing and coding. He says that “writing [is] harder than coding. But like coding its fun.”
He goes to explain that in coding “if there’s something you don’t like, you change it. So programming has the same relaxing quality as building stuff out of Lego. You know you’re going to win in the end. Succeeding is simply a matter of defining what winning is, and possibly spending a lot of time getting there. Those can be hard, but not frightening.”
In contrast, while writing you “don’t have the same total control over the medium”. Paul concludes that “the result is that writing and painting have an ingredient that’s missing in hacking and Lego: suspense.”
There you have it. Writing is like coding only more difficult but equally fun. No wonder erstwhile programmers (like me) take to blogging. They are trying to re-live their wonderful coding days :-).
[Paul Graham’s post found via Alex Kosorukoff’s blog, Social Computation and Creativity]
While programmers may love blogging, I feel after reading more than a few blogs, a programmer’s blog could be quite different from a non-programmer’s. A programmer in solving a problem ensures that the problem is well understood, several solution prototypes are tried out and a well thought out design that addresses most nuances is figured out as the code unfolds. While the fun-tedium ratio may be lower in detailed design, this may refer more to the detailed design document that a programmer may detest writing but probably not for the effort that goes into mentally thinking through the solution in detail — the journey is a good chunk of the fun! What I’m saying is, a programmer’s way of thinking is highly structured, logical and methodical. A programmer’s blog is the same way.
Sharad’s blog is a good example. A monthly summary, statistics, series of articles, thoughtful rebuttals supported by data and logic — you ain’t gonna see this is a non-programmer’s diary.
For a user/customer of software a programmer’s blog is fantastic — given software documentation is often written by someone other than the programmer, one rarely gets to see the mind of the person who developed the program and documentation that is as nicely structured as the solution — blogging solves that nicely.