Crisis Driven Development

I recently heard someone refer to their day as an example of Crisis Driven Development. I have recent experience with an organization which seems to believe that Crisis Driven Development is the only viable SDLC process. For those who may be unfamiliar with CDD, here are some of the signs of a CDD process:

  1. Thinking that modifying estimates to fit predetermined timelines will cause a date to be met.
  2. Thinking that when timelines are proven to be unrealistic, throwing more people at the project (see Brooks law if you don’t understand why this is generally bad idea).
  3. Thinking that an agile process means putting everybody in a war room for the duration of the project.
  4. Thinking that requirements aren’t important since we are agile.
  5. Thinking that developers are interchangeable cogs in the great software development machine.

As you can see, each of the signs starts with the word thinking. They think something will work, because they heard something somewhere, or simply don’t understand software development. I know, some are saying that developers are just prima donnas that won’t stick to the game plan. I’ll certainly admit I’ve seen some of that over the years, but overall I have worked with good developers that want to turn out a quality product in a reasonable amount of time.

The problem is there are people that don’t understand the development process. I don’t mean a project manager that doesn’t know how to code, I mean people that don’t understand that software development means building something. These are the people that would have a truckload of building materials delivered to a sight, order up a bunch of construction workers, and tell them to get to work, with no blueprint or plan of any kind. They think that because everybody works construction it doesn’t matter who shows up today, not realizing that you need a foundation poured before the framers show up. That until the walls are framed you don’t need the electricians. That there is a fixed logical order to things, and that the roofers show up after the framing carpenters.

I have worked with some good project managers in my career, but I have worked with more bad ones, most live by the Peter Drucker quote “So much of what we call management consists in making it difficult for people to work”. I’ve seen project managers schedule a day of meetings to brainstorm about why nothing is getting done. I’ve seen projects where the project managers outnumber the developers 20+ to 1, and every one of them wants a status report in their own format, sometimes daily.

Years ago I led a team where each of us had a sign in our cubicles that said “We do 3 kinds of work around here; good, fast and cheap; you can have any 2”.

Writing code is but a small part of what I do. I must be a teacher, a mentor, a sounding board, an analyst, a leader, a team member, a listener, one who can see the big picture, while at the same time looking for the smallest details. In order to do any of these successfully I must remember to always be a student.

Sometimes people are determined to follow the CDD process, for them there is no hope, and the best you can hope for is to escape with your sanity. Sometimes however we are fortunate enough to make a difference, and those times make it all worth while.