Thinking Inside a Bigger Box

If a beginning programmer was to read just one book, this would definately rank high on a list of candidates. (But then again, why should a beginning programmer only read one book)

“Agile Software Development: Practices, Principles, and Patterns” is in many ways Robert C. Martin’s magnum opus. After having read much of his papers on Dependency Inversion Principe, the Open-Closed Principle and other object-oriented methods, as well as Extreme Programming, Agile Software Development puts it all together. More than any other book I have read, possibly including Beck’s excellent “Test-Driven Development”, Agile Software Development makes a very strong case for writing the test before the code. Most of the examples in the book, even when Martin does not talk about testing, start out by writing a test to explain a concept. The book goes a long way to normalize the sensibilities of Extreme Programming.

As the full title implies, Agile Software Development spans a wide range of subjects. The book starts off explaining Agile software development and Extreme Programming in some depth before covering principles of program design. While using a lot of examples and good case studies to clearify his points, Martin then goes on to explain, each in it’s own natural time, 14 of the most crucial design patterns from Gang of Four, as well as a few from other sources. Agile Software Development does not study each pattern in as much depth as the gang of four, but the author provides a good trade-off between giving the motivation for each pattern, explaining the mechanics of the pattern and putting it into context.

All in all, the book tours a great number of subjects that are critical to the design and implementation of software projects. I would be much relieved about the competency of any colleague if I knew this book was on the list of books he or she had read. More than explaining the basics, Martin argues for why and when they are important and just as importantly: when they should be ignored.

But the Satire of Two Companies in the appendix is just lame. ;-)

I have come to a conclusion: I do not want to be on any more fixed price, fixed scope projects. From what I hear, that is all the projects the consulting business is getting today — if that is the case, I will have to find something else to do.

The main reason I take this stance is simple: To me, seeing the value of my work in the real world is the only real measure of accomplishment. And I believe fixed-price, fixed-scope projects always have a very poor ROI.

The detailed argument is too long to get into, and better minds than mine have already extolled them (Kent Beck, Mary Poppendieck). I will restrict myself to partially sum up my position:

• 65% of delivered software features is seldom or never used. Being forced to decide the scope up front will force the customer to include in scope much more than what an adaptive scope would require. This will only make the situation worse. (Source: Standish Group’s CHAOS 2002 report)
• In a marked where providers are in cut-throat competition, the result will be that the providers will be forced to be more and more reckless. This increases the risk for late, insufficient, poor quality, excessive changes, and failure to deliver. All these risks are carried by the customer. Some people refer this as a competition to see who can lean the furthest out of the winding (while holding on to the customer)
• Fixed-price, fixed-scope tend to have drawn out deliveries. This means that the supplier will interpret the real user needs more than with an iterative process. This is probably an important factor in the number of software projects that are delivered according to specification, yet do not fullfil the real need of the system. In addition, drawn-out deliveries postpones ROI (See Poppendieck’s work)
• Fixed-price, fixed-scope treats software delivery like procurement of commodities, something it is definately not.
• Specifications are inherently vague, incomplete, open for interpretation, and often wrong. Competing on a specification is more a question of who can hide the largest part of the project in change requests down the road. (A secondhand comment from a big Norwegian hospital project: “If we ask for 9 billion NOK, they will not approve the project. We’ll ask for 6 billion and just blow our budgets”)
• Fixed-price, fixed-scope projects create a adversary relationship between the customer and provider. This hinders the task of creating the best ROI. (I have heard the contracts referred to as “ping-pong” contracts: Send the ball back to the other party until someone lose)

In conclusion: I believe it is professionally irresponsible to deliver projects in this way. If you ask what I propose instead: Some variation of fixed-price, variable scope, highly iterative process. But that is a whole other argument

As an example: When the Norwegian tax authorities had to cut the contract with their provider for their “SKARP” project, the project had already incurred on the provider a cost of 250 Million kroner (about $30 million). Even if the tax authorities did not have to pay for this work, the project was cancelled after (I believe) two years. This mean that no matter what way you look at it, the SKARP project is delayed 2 years. I am hoping that if my government projects, say $50 million on a project, they are hoping for a return of, say $100 million over 10 years life time. This means that the project must be worth $10 million per year. This means that either the project has an insanely stupid ROI, or they have just lost $20 million due to lost opportunities. I think this is grossly negligent.

Update: Cleaned up mess made by “WYSIWYG” tool)

Rating: Must-buy

The agile movement has started to gain speed and become more mainstream, and the Poppendiecks’s “Lean Software Development” added an important part of the puzzle for me.

Like so many manifestos before it, Lean Software Development compares software development to other industries (lean thinking takes its roots in the Toyota manifacturing system). However, the authors reach a very different set of conclusions. The crux is to not compare the practices that were useful in other industries, but the principles underlying these practices. The ideas developed in the book are very much like the agile manifesto.

Lean Thinking uses the following principles (each described in a separate chapter in the book):

1. Eliminate waste
2. Amplify learning
3. Decide as late as possible
4. Deliver as fast as possible
5. Empower the team
6. Build integrity in
7. See the whole

As you might notice, the list is not specific to software development. Each chapter is rich in great examples, both from the software industry and other industries of how to do and not do lean thinking. One of the greatest parts of the book is the table comparing the wastes in manifacturing to the wastes in software development:

As the table shows, “Lean Software Development” very much supports the position of Agile software methods, but adds a new facet to the discussion: Why does agile work, and where can we see similar ideas bringing success in the non-software world. In conclusion: Why agile makes business sense.

If you are addressing software from a business point of view, or if you are trying to convince people why Agile development is a good idea from a business point of view, you need this book.

The video from my presentation at this year’s JavaZone are available. The conference has done a lot better job of follow-up this year than last. Thanks, JavaBin.

This is actually the first time I get to see a full-length video recording of myself speaking. I was afraid I would be real disappointed, but I am actually fairly happy. Most of the problems with the presentation was things I already was aware of, like the fact that I had way too little time. I do agree with one critic however: I will try not to move around so much in the future.

From what I can hear of the audience in the recording, it seems like I did a fairly good job at entertaining people, too.

(Warning: Boring, personal entry)

I am writing this entry on a bus. More specifically, on the bus from the airport to the conference Sanntid 2003 (Real-time 2003), where I am scheduled to speak tomorrow. The airport in question is Kjevik airport, which is a military/civilian airport in the south of Norway.

Normally, when I ride busses, I like to read. I brought along Mary Poppendieck’s fascinating “Lean Software Development”. This time is different. I cannot concentrate.

Driving past the military base at Kjevik made me think about the last time I was here. That time I was serving in the Norwegian military forces as a conscript communcations assistant. The memory made me unable to concentrate on the book, hence this post.

The last few years, I have had an increasingly ambivalent feeling towards the millitary, even including the Norwegian armed forces. The more I learn about politics and history, the more I am convinced that war, or any form of forceful confrontation, extremely rarely improves the state of the world. This realization is made stronger when I look at my own reaction to physical (historically) or emotional bullying. In general, forceful techniques rarely make me change my mind, other than becoming more negative towards the bully. I believe groups of people act the same way. In short, spending money on military is counter-productive (plus it means you can’t spend money on sensible stuff). I guess I would classify myself as a political pacifist.

Yet, I have always been attracted to something abouit the military. Perhaps it is the seriousness of it all. Perhaps it is the undertone (with the Norwegian armed forces, anyhow) of violence. Even though I consider violence to work against its intent, I appreciate the use of violence in the entertainment industry. I enjoy violent movies and violent computer games. I probably enjoy them more because of the violence. I guess I am contradicting myself, at least on an emotional level.

Now for the hard part: When writing a blog-entry, we are supposed to say something profound. This entry is mostly just written because I cannot concentrate on anything else. I guess if there is something to be leaned from all this, it is the following:

• People can hold contradictory views. That is just a part of being human. Recognizing it in my own views makes it easier to accept contradictory beliefs in others.


• The forceful approach probably doesn’t work so well. You catch more of the proverbial flies with honey than with vinegar.

I hope that is profound enough for you, gentle reader.

[…]

Are those CMM-mandated procedures too difficult and onerous to complete? People will find a work-around, bypassing the intent of the CMM and filling in whatever documents are required to get by. Is that comprehensive (and manual) test plan overly lengthy and tedious? People will take short-cuts. The “extra-legal,” or alternative system will evolve in any social setting where the official mechanism doesn’t cut it.

[…] 

Beyond Software Architecture (Luke Hohmann) is an invaluable read for any aspiring project manager or program manager. There is so much more to getting successful programs out the door than just the classical analysis, design, development, test.

The most important feature of this book is how it helps frame software development in a larger picture. The point of software development is to create value for someone. It is important not to lose sight of that fact. There is more to value than just features, and Hohmann gives a good overview. My only problem with the book is that I found it to be a little encyclopedic at times. This does not detract from the value, but it makes it a little harder to read.

My favorite part of the book is the introduction of the concepts of marchitecture and tarchitecture, and Hohmann’s descriptions of the very important marchitectural considerations that must be present for a development effort to be successful.

I am sure there is much more to this subject than is covered by the book. I am also sure there is much more to know about each subject. For someone like me, who likes to get a full understanding of the activity that is software development, it provides a good introduction to an important part.

I recommend this book if you are currently or in the future planning on being project manager, program manager or (t)architect on a software project. It is a fairly quick read, and covers a lot of ground.