Software Development is not a Honest, Rational Endeavour

Obviously, the kind of people who write software are the kind of people who want to be seen, and seen themselves as honest, rational. And obviously some aspects of software development are rational. But the overall arch of a the development of a software project isn't rational.

Why? Because of the nature of the projects that get funded that we talked about on day 2. The kind of projects that get funded are funded on the basis of big, shiny, simplistic concepts, New, Digital, Different or "What our competitors are doing."

But this is the central contradiction at the heart of any project, certainly any that involves software development.

Starting to implement the idea that got the project funded, naturally results in the idea that got the project funded being attacked and undermined. If the idea of the proejct is attacked and undermined, then, by implication, the people who came up with the idea and the people who supported it being developed it are undermined. The kind of people who are good at getting projects funded are often quite good at defending themselves, especially they are good at defending themselve from lowly suppliers who are supposed to just do as they are told, whilst making sure that they continue to look good in the eyes of the people who funded your project.

This is the fundamental toxic dynamic at the heart of software development projects. Here's the paradox in all its full horror.

If you start the engine (of software development) it will start to show the flaws in your idea.

If you don't start then engine (of software development) there's no chance that your software development project will get delivered.

There are at least two solutions that I know of to this problem.

1. Run the project but don't let it have any contact with reality.

This is essentially the way that "traditional" projects were run before Agile iterative software development became a reality. And this is the reason that the first two major traditional projects that I worked on (over twenty five years ago, since you ask) resulted in litigation. In both cases, for several years the customer had been able to sell themselves - and their boards - the idea of a new, better, different thing. When that thing arrived, it was a nasty surprise, that had them calling their lawyers.

Traditional project management was very good at keeping the bad news about a project away from the customer for years.

The iterative process of Agile throws up that bad news really quickly, and every couple of weeks.

But there's a really simple way of making sure that an Agile project doesn't cause any more upset than a traditional project (for a while, at least). And that is to simply not report the bad news to the customer.

This might seem like a terrfically dishonest thing to do (it is). It also might seem that it's not honest (it isn't). But almost always it's what the customers want.

When asked, of course customers might say that they would want to know if there were anything wrong with their project. But in reality, the way that they behave, often makes it very difficult for a development team to raise these issues. Part of the reason for this is that there are only really two alternatives to ignoring the challenges that a project throws up.

2. Ditch the project

So much of the time, from the point of view of the organisation paying for the project, this would probably be the best thing to do. But it happens very rarely. Why? It's simple really. Because if the project ends, everybody looks bad and nobody gets paid. The people who came up with the idea of the project - they look bad. They had an idea, they persuaded people to give money to the idea, and then the idea turned out to be bad. The people who funded the people who looked bad, they gave money to a bad idea. And the people who were supposed to be doing the work, they feel bad, the project's being cancelled - they're not going to get paid!

Once you walk through how badly this works out for everybody involved, it's perhaps not so surprising that so many fundamentally flawed project continue for months and even years.

But there always door number 3.

3. Craft a solution which is valuable to users (the people who actually use the system) and customers (the people who actually pay for the system)

This is far from an easy option. Mainly because of the psychodrama that is pretty inevitable once a team attempts any move away from reporting good news and hiding bad news.

This is an option that moves away from the big, shiny, persuasive - but undeliverable - concepts that sold the project in the first place and towards a partial, particular solution. What makes this particularly hard is that the contrast between the partial, particular solution and the general shiny idea is at it's absolute worst at the point when you're trying to make the transition.

For example. One project that I worked on was six months and one million pounds in before it had it's first working demonstration. That demonstration brought up a dialog box in a browser. The text on the dialogue button was misspelled, and when the button was pressed the user got an error. One million pounds.

But this project was a success. The demo was a tipping point. It was the point where the customer started to be weaned off of kudos for getting the project going and started to see the possibility of kudos for deliving something that was actually valuable to customers.

But you have to wonder - at that point - is it rational?

This post has throw-up (urgh), brought-up (not much better) raised (OK). A lot of other things that I can write about.

The miserable nature of initial examples of working software.
Agreed activity.
Finding pull.