Home Home Posts Rants about IT DevOps Stuff I'm working on

Dockyard of ships which can’t sail

Arseni Mourzenko
Founder and lead developer, specializing in developer productivity and code quality
115
articles
September 27, 2013

Badly managed projects often share an element: the willingness to deliver all features in a given amount of time and within budget.

Given how we conceptualize the notion of a deliverable outside IT world, it feels intuitive. When I order a piece of hardware online, I expect it to be delivered on time and expect the package to contain everything I ordered, not only a part of it. When I buy an object in a supermarket, I expect it to be available immediately, undivided.

But again, our representations which work outside IT world fails miserably when it comes to software development. If you want to fail a project, if you want to obtain fiction instead of a working product, then requiring the whole project to be finished for a given deadline is the most effective thing to do.

Building fiction

We, developers and project leaders, build fiction because, within the model of a fixed, complete, deadline-bound delivery, this appears to be the only possible way to respond to customers’ needs. In a wrong way, but still respond.

IT projects are, in essence, organic systems which constantly grow and evolve. This process stops only in two cases: either because the system reached its stable state, which, in practice, is extremely rare, or because the system is considered dead, in other words either suspended without precise plans to maintain or change it, or definitively abandoned.

If we accept this assertion as granted, it appears that delivering the project for a precise deadline makes no sense whatsoever: since it evolves organically all the time, the only way to “deliver” it for a deadline is to consider it dead when it reaches it—not something to wish for a project.

Agreed, there are a few cases where the project has a finite state, i.e. when the original WBS, SOW and functional and non-functional requirements are so complete that there is no room for randomness or fuzziness. Note that this requires not only to know exactly every aspect of the future software product, but also every quirk which can be caused by the underlying technologies. I’ve never seen such a product.

So, we decide to cram an organic, constantly evolving system into a box of a requirement to deliver the whole thing on an arbitrary date. This can lead to two types of disasters: ghost project or quick-hack mess.

Ghost project

A popular marketing approach consists of preparing content which shows some of the features of a product, without having any product behind, a sort of empty shell. For example, a company can publish a video which shows a user manipulating the future web application, while the video was done from static HTML pages with no code behind.

As a marketing approach, it’s a perfectly valid way to showcase a product which is not yet done.

As a way to make real products for real customers, it’s a total failure. While a public which might, one day, purchase your product, can be satisfied by a “don’t touch that; don’t go there” presentation, a customer who ordered a product and already invested hundreds of thousands of dollars in it won’t be. Even if such presentation would be a success, very rapidly, the customer will start testing the app, interacting with it, dissect it, to find that you delivered just a bunch of fancy pictures.

In practice, companies which deliver ghost projects are nearly inexistent, probably because such companies will come out of business pretty fast.

Quick-hack mess

The quick-hack mess, on the other hand, is very frequent in the world of project failures. It consists of delivering something which looks correct to stakeholders, while the team knows very well that the product is either unfinished, or even realizes very well that the project is a complete failure. The project is still officially considered finished by the team, so they are able to say: “Hey, we delivered the project on time” to the ones who pay them. Later, when the stakeholders start to reveal bug after bug, the team qualifies it as “maintenance of a project delivered on time”. I’m sorry, they are lying.

I won’t even start listing all that’s wrong with this approach. In short, it is one of the four major causes of project failures, the three other being bad management, communication issues and incompetency. There is no way to deliver anything acceptable, since once the quick-hack mess is delivered, the dark period begins for the team: the period where the team will spend sleepless nights fixing one part of the code base just to notice that it broke something elsewhere. The desperate fight for “just make it work” stops either when the customer has enough of reporting bugs, or doesn’t have money to pay extra for a never ready project.

Sometimes, this desperate fight can be short: the project can’t even be deployed in production; the customer understands that he was screwed from the beginning, and cancels the project. Sadly, often, the customer who already spent hundreds of thousands of dollars is hesitating to declare a failure, and continues to pay, erroneously believing that “in a week, all bugs will be solved”, sinking into the self-deception and the denial of the famous 90% Done syndrome.

How to avoid building fiction

Developers do well what you demand them to do. If you ask them to deliver crap under schedule, they do it. If you change the statement of the problem, it would be solved differently. In other words, by shifting the problem out of the familiar concept of deliverable into the world of Agile, the project is magically saved from being disaster, or at least the 100% probability of being a disaster.

In Agile, there is no project as a deliverable: there are tasks, sorted and grouped within a set which can be done within a short period of time (call it Sprint or whatever you like). The ability to sort tasks implies priorities. The ability to group them implies a fully-functional, working system which is pushed into staging, and can be eventually pushed into production, if needed.

This radically changes the rules of the game. Instead of being forced to deliver a system where every aspect looks as working, but none really works, you deliver a well-written, maintainable, extensible parts of the system you finished in a given amount of time, keeping the rest of the system under development.

Target features, and don’t waste time creating schedules.

Deliver regularly, deliver often, and make something which works at every delivery. If the project is cancelled, at least you have something which already works, and works damn well.

What could possibly happen? An unhappy customer would be angry that the product isn’t finished? It wouldn’t be anyways. What would be the benefit of lying, instead of giving a precise image of what is already done and what follows?