A Doesn’t equal B but could equal C or maybe a different letter no has yet mentioned. If you are really unlucky it might be number :-)

People apply linear thinking to software development. Cause and effect, action and reaction. They start at one point and finish at the end point.

Requirements in → Software out

Software development is never that simple, the journey isn’t a straight line from A to B. It’s more like starting at A, rolling down a hill through a patch of stinging nettles, run into the sea, get eaten by a whale, sicked up a remote island, live for 6 months only eating bananas only to find on the other side of the island there is an all-inclusive holiday resort. Then you show the customer exactly the software the requirements ask for, only to find they now realise they don’t want that software.

Software development is not a logical game of chess, it’s more like a game of poker. We don’t have all the information. There is luck involved, and it's a complex system of interrelated processes/people.

In software development. A doesn’t equal B, nothing is as simple as it first appears. Today's problems were caused by yesterday's solutions. Like updating a piece of code here, it breaks code somewhere else that you didn’t even know was linked.

Shifting problems, not solving problems

Most solutions to problems either push the problem to another area or shift the problem to the future.

Speed, pressure, people, emotions and lack of understanding force people to react to situations. Reactions bypass thinking and grab the simple solution, which does something right now.

Software development is a system and a creative process where you need to out-think your problems instead of trying to outwork them.

The simple thinking of A equals B is the source of much frustration and torment on software projects for customers, managers and developers

Why doesn’t A equal B

A doesn’t equal B because by simplifying problems isn’t to standalone issues often end up solving the symptom or shifting the burden to a different place or time (delayed).

Linear thinking views a problem as event A happened. This caused event B. Developer Bob was to blame, put this process in and to stop it happening.

Examples of simple thinking would be

• we are going to miss the deadline, add more developers, create software faster.
• A bug is found in production, the developer who changed the code last is to blame.
• The project is took 1 year, it’s taken 2 years, the development team underestimated and now wants more money but it’s their fault.

Fast development with no documentation is great for now but in the future and if people leave, it creates chaos and confusion. Trying to identify problems in production by looking at the code is a stressful way to live life.

This design was wrong, the project was late. There are many reasons a project could be late and almost never because of one reason. In many scenarios the design becomes wrong later when new requirements are discovered and added to the project.

The simple solution treats the symptom and shifts the problem to somewhere else. The common example of adding more developers to go faster, doesn’t identify the cause of the project missing the previous deadlines. Adding more developers to a badly performing project can make it take longer and cost more money.

Blame and scapegoats

Software projects have witch hunts looking for the person to blame or the source of the problem. The project wants a scapegoat to put the blame on one person/team and absolve everyone else.

One individual does not cause problems. The fault is the system or process with many people contributed to a problem. System thinking is difficult, it's easier to find a scapegoat.

The pressure of projects with money, reputations and expectations on the line pushes people to find a quick answer.

Short cuts give the illusion of taking action and fixing the progress

Many problems are system problems, process problems, with multiple contributing factors. Blaming an individual isn’t productive. Why was the person put in that position where they could make a mistake?

How Software Development Really Works — Always Blame the Developer Who Left. Scapegoating can be useful because in certain situations, it allows the rest of the team to start new and not be tarnished with previous failures.

It’s useful to blame developers who left or a previous team who has been kicked out. They won’t know, it won’t hurt them and they would do the same.

Blaming people is a waste of time and energy. The motivation of the people looking to blame someone is to push the blame from themselves individually. Find the route cause is productive but only if you use that knowledge to fix processes and systems.

Software isn’t created by an individual and software projects aren’t delivered by a single person.

Software development is a long-term game

If you inverted software development and tried to make software as bad as you could, you would do some of the following

• Rush as fast as you could (impossible deadlines)
• Create low quality software
• No documentation
• Have no process or best practices
• Manual activities (and each person do it differently)
• Unskilled developers (wrong skill or too many juniors)
• Change requirements, find missing requirements
• Change priorities and plans

This would initially create software quickly, but the problems it causes will soon after 3 months slow development. The problems the fast/low quality approach creates would soon plague the project. This will have an amusing effect of encouraging people to get off a painful project and contributes to more problems.

The initial speed of development raises expectations and will add to the loss of confidence and relationship between developers and business users when things go wrong.

The above list seems to be a playbook for many software projects. Software development is a losers game, avoid mistakes first and focus on quality because Quality is fastest way to get code into production

Solutions cause problems

Bad developers are so bad they don’t realise how bad they are. Their solutions create problems!

Many short-term solutions are so bad, no realises the long-term problems they create.

When reaching for a short-term solution, ask yourself, how long do I expect to be here? If you are planning on being on that project for longer than six months, you will experience the pain of those decisions.

Will the company and development team be on this project for longer than six months?

You need to stop, explain the long-term view and take the long-term option and create quality.

Conclusion

The fastest way to create software is creating quality and thinking long term. The long term decision don’t have immediate benefits.

Software development creates pendulum swings of emotion with missed deadlines and increasing costs. It’s tempting for software projects to choose the easy option, make the decision which gives immediate benefits.

The short-term decisions will slow the project down in the long term and increase the pressure on everyone involved as development gets harder.

Software projects need to not react to situations but make rational decisions that are best for creating software. You need to step back and assess the bigger picture and the entire system.

A does not equal B, you cannot trust your eyes in a software project because it’s more complex than you think.