A development team either creates order or succumbs to chaos

If the development team doesn’t bring order, standards, best practices and documentation to software development, it creates chaos. Each developer does things differently and information is passed verbally between team members.

Bad development makes development harder and creates more problems for the developers and the project. Mistakes are made because no best practices are used and no lessons are learnt from past experience.

The reason this suboptimal approach is used because the developers on the project don’t know (or believe) a better way to create software. A customer are paying for professionals, but getting amateurs.

Your code is like bad medicine

I have worked in some bad development teams, taken over from bad development teams and joined projects where my goal was to fix the problems created by previous bad development team.

Before I joined one project, my manager said

“there is nothing you can do to make this project worse, so go there and make it better”.

This proved accurate. A large development team confronted me, working hard but creating chaos.

It was constant fire fighting, builds breaking, teams overwriting each others code and the scope changing all the time.

Bad development has a common approach, creates common problems and usually ends with new senior developers/architects or a new development team coming in.

Inexperienced developers without guidance create low quality software because they don’t know what quality code looks like and have gained the knowledge/experience to create it (which is why senior developers play a key role in the success or failure of software projects)

The bad (inexperienced) development team approach

Bad developers' approach is to write code as quickly as possible. Manually deploy it and get it into production ASAP.

Initially, and in the short term, this works and from a manager/customer point of view, it's great. Quick development and high fives all round.

Problems appear when you scale (add more developers) and the software grows. Complexity in software increases with more connections/dependencies. Good development practices manage the complexity, low-quality development practices exaggerates problems. Low-quality code will create more problems and faster.

Problems from bad code have a delay before they kick in. You get a couple of months and a few initial releases before problems appear. This is because of a delay in the feedback of low quality code. Then development slows, problems are harder to fix and problems grow in number.

No standards, low-quality, no testing, no best practices, no DevOps, no documentation start to punch the bad development team in the mouth. Working on the project becomes a nightmare. Developers leave and with them go the knowledge they were too busy to write or create procedures for.

The team tries to outwork their problems, but it's too difficult and more developers leave.

The poor developers who join the project are in a state of confusion, the code is complex, and no is sure how things were done.

What happens next?

At this point, a few things usually happen

An enormous problem detonates on the project, and the development team cannot get out of the mess. Escalation occurs, and the company brings in some of their best developers/architects/people to sort out the project (and save the contract)

The customer kicks our the company and a new company and Dev team are brought in.

Scapegoat required

It’s necessary to create a scapegoat of the past developers. Put all the blame on them, so the new development team can start fresh with no stench of failure on them.

The first stage is confusion with a tiny sliver of admiration.

When good developers look at terrible development, it makes no sense. The code, approach and ways of working don’t resemble how a good development team works. Good developers won’t have worked like this for 5 or 10 years, it makes no sense to them.

Everything done by bad development teams is confusing and chaotic. This is where the sliver of admiration comes. How have they worked like this for so long?

Not only is chaotic development low quality, the developers have to remember more and work harder.

It’s like living in a house where the front door is broken, everyone climbs through the window. A new person asks why they don’t fix the door, but to everyone else climbing through the window has become normal.

Change expectations

The new development has a tough start. They have to create the foundations and build on top of them.

They have to create standards, best practices and processes from scratch.

• Nasty, complex code to fix.
• DevOps and deployments to create
• Documentation of processes

The customer is willing at the start because they of their frustration with the problems of the last development team.

It’s still a tough sell because the customer needs to be trained in the process of good development and the benefits, e.g. fewer problems and steady momentum and creation of software.

Why does this happen?

Software needs to be built for scale and maintenance. Bad development only focuses on creation only works on small projects where the complexity is low, number of developers is few.

Bad development on big projects doesn't smash into a wall. Instead, it slowly gets tangled and choked to death after a few months and a few releases.

There is a delay before the low quality code creates problems. There are few visible signs of low quality from the outside. In fact it’s the opposite, bad developers make fast initial progress because they take shortcuts and don’t create solid foundations.

Bad development teams are cheaper (Why the Cheap Option in Software Development Costs More?) and don’t realise their approach will be their downfall. Bad developer a don’t know how bad they are or what good looks like. They are blind to the fact they are digging their own graves.

It doesn’t matter bad development teams load projects up with as many people as possible for the initial phase of good fast progress. They keep dancing as long as the music is playing and get paid for as long as they can.

The new development team will be appalled at the poor quality of code, the lack of standards.

Conclusion

Software development is not a numbers game, developers are not commodities that are all the same. You need developers with the right skills, experience and knowledge to do the job.

On small projects development teams can deliver software with low standards and poor processes. As soon as the software project becomes bigger, standards and quality becomes key to a successful project.

If there are lots of inexperienced developers, it’s difficult to learn to create quality software because they don’t know what quality code looks like.

Signs of bad development

• Manual releases and release problems
• Lack of documentation (no standard procedures)
• Information held in developers' heads (developers can’t go on holiday)
• Different problems keep appearing and difficult to fix