Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

The Contract-Driven Serial Development Movement

March 2nd, 2008 · 1 Comment

There is a movement in software development that I call the contract-driven serial development movement. There are two distinguishing characteristics of software development lifecycles created by proponents of this movement: 1) the definition of deliverables in contractual form and 2) the delivery of deliverables in phases (i.e. requirements, design, construction, etc.). I suppose you could also call this the “waterfall of blood” movement because it’s essentially waterfall with wet signatures at every stage. Many of its proponents would take this signatures in blood if they could.

Every movement is trying to solve at least one specific problem. This movement is trying to solve two, as far as I can tell:

  • To mitigate the high cost of change by creating obstacles to change in the form of contracts and change control procedures
  • To facilitate the assignment of blame when things go poorly by defining all requirements rigidly, completely, and legalistically
  • I don’t believe this movement makes IT a better place.

    In fact, I think it is a horrible movement, spread by technology people with thin skin, self-serving intentions, and weak imaginations. There are much healthier ways of dealing with these problems, and I am going to talk about a few of them. First, however, I want to debunk a few things.

    You can’t beat the cost-change curve by making change MORE expensive
    Change control procedures do not reduce the cost of change. They add overhead to change, which makes it more expensive. Legalistic requirements documents add more cost – when “the business” has to commit to a set of documents being what they want, all they want, nothing more, and nothing less, it takes a significant effort to make sure those documents are correct. Especially if it means they have to wait twelve to eighteen months before they can realize any return on their investment, as is typical of serial development.

    The cost change curve is one of the first things they teach project managers. “A change of requirements at the end of the project is a bazillion times more expensive than a change of requirements at the beginning.” It makes sense, and it sticks. PMs don’t forget that mantra.

    Unfortunately, the cost change curve is also a function of the methodology you follow. The bazillion dollar cost of late change is a feature of serial development (waterfall), a self-fulfilling prophecy that is forced to be true by the project structure itself. Of course late requirements changes are orders-of-magnitude more expensive because you’ve already made all sorts of decisions based on them that would have to be unmade. You’ve built a huge pile of documentation with little or no business value that has to be re-vamped in order to make the change “right”.

    You can beat the cost-change curve by delivering incrementally
    Let’s say that instead of delivering in phases you decide to deliver in increments. In other words, instead of delivering requirements after three months, then design after another three, and so forth, you instead deliver little chunks of working valuable software every one, two, or three months. You start each increment by working with the business to define that piece of functionality, then you build and deliver it as quickly as possible.

    Change doesn’t cost as much when you do it this way. If your business partner decides that feature Y is suddenly critical while your building feature X, you can usually placate them by reminding them that feature X will be complete in a few weeks and then you will start on feature Y.

    What if they decide to change feature X, which you’ve already built? Well, you just plan another increment to change it. It’s not unusual for people to change their minds about something they’ve previously only imagined once they see it built?

    What if they decide to change feature X while you are building it? Just do it. If you are building in short increments, the impact of a change will be small. Maybe it adds a week, perhaps two. Tell the business what the change means and see how they respond. Big deal.

    Building software in small incremental chunks flattens the cost-change curve.

    You can reduce the likelihood of change by building in small incremental chunks
    The longer the amount of time lapses between the definition of a feature and its delivery to the business, the more likely it is to change. Change could be prompted by many factors such as government changes, market forces, and personnel changes. Heck, it could even be influenced by changes in the prescription medications your overwhelmed business partner consumes.

    Change happens – and the longer the window you give it to happen in the more likely it is to occur. This is the great irony of the CDSD movement – it asks for more time for requirements and what-not, ignoring the dramatically increased likelihood of change that it’s approach to resisting change creates.

    Laying blame isn’t any easier just because you have contracts
    Just ask a lawyer. Contracts don’t necessarily make it any easier to stop your business partner from throwing you under the bus when bad stuff happens. In fact, these contracts are frequently more ammo against you.

    “IT said they would deliver this, but they did this instead.”

    More importantly, if a technology solution is bad for the business, it doesn’t really matter if the contract specified that solution or not. Companies don’t get a get-out-of-jail-free card when it comes to market forces and competition. If you build the wrong thing and miss a market opportunity as a result, contracts are of little concern. The whole business is going to suffer, and you might have a smug sense of satisfaction because your petty little contract “proves” it’s the business’s fault and not IT’s, but it doesn’t make your project a success.

    Perhaps if you hadn’t shoved CDSD down the business throat you might have been able to collaboratively deliver a better solution. Maybe it is your fault after all. That’s what it always boils down to. When these projects fail, IT says it’s the business’s fault. “See, it’s right here – you signed it.” The business sighs and says, “Yeah, we signed it… but if IT was more flexible, more able to respond to change, we would have solved this problem differently.” And then they outsource you.

    Reduce the impact of mistakes by delivering incremental chunks of working valuable software
    Screwing up doesn’t have to hurt so bad. Mistakes happen, and blame gets apportioned, often unfairly. That blame, however, is typically proportional to the cost of the mistake. Because mistakes are so outrageously costly in CDSD, blame is often a pound of flesh or more. It doesn’t have to be that way.

    Incremental delivery reduces the cost of big mistakes by reducing the amount of time it takes to discover them. Since you deliver working software every month or two, the business gets to see the project as it is built. This means they will identify mistakes early and you can correct for them. The worst cost of a mistake is typically one implementation cycle, and if you keep that down to a month or two, it’s not that big of a deal.

    Redefine project failure with incremental delivery
    I’ve seen CDSD projects shutdown after eighteen months or more, having never delivered a line of code. That hurts. That’s money down the drain. What a demoralizing waste of resources. How sad. There is no hope of picking up such a project where it was left off – requirements documents, design documents, the labor of love of CDSD, have a very limited shelf life. They go bad faster than new bananas.

    You can cancel any one of my projects six months in and I won’t be upset. Why? Because we have already delivered valuable working software. Generally speaking, we’ve already delivered the most important features. Move those resources around, assign us to something else, it doesn’t matter. It’s not money down the drain. We delivered something the business wanted, and then we shut it down. Big deal. We shipped software, software that worked and that had business value. We were successful.

    Don’t buy into the Contract Driven Serial Development movement. It’s not good for you, for IT as a career, or for the business you signed up to serve. Kick it to the curb as a stupid idea, and then go write some code.

    If you enjoyed this post, make sure you subscribe to my RSS feed!
    Stumble it!

    Tags: Project Management

    1 response so far ↓

    • 1 Allen // Mar 3, 2008 at 2:22 pm

      lol. Great sign off. You are definitely onto something here. Keep stirring these ideas around and you may have a PM book here =)

      The more we can stand in the shoes of the user, the happier they will be with the software, and the more successful the finished product will be. A tool falls flat on its face if the customers don’t use it fully.

    Leave a Comment