How not to speed up IT projects (the top 3 blunders)

Code not being used by users is worth nothing, you have zero return on investment for code that is in development. And the only way to get code faster into production is not by adding more man power, but by focusing on quality.

Quality code makes maintenance easier and reduces code interaction times. Low quality code slowly creates more problems and slows down development.

Traditional thinking of speeding up projects

The traditional method of speeding up projects is taking shortcuts like working more (weekends, evenings), reduce time needed for automation and quality, adding more people, outsourcing etc.

Adding more people & outsourcing model

One of the most ineffective approaches to speed up project delivery is by trying to add more resources. The more people you add to a project, the more complexity you add. Communication and collaboration becomes harder and the project needs to spend more time communication to avoid creating conflicting solutions, making incorrect assumptions and creating a solution which works.

This is one of the major challenges with offshoring model, where distances, communication, culture, timezones, organizational goals etc. differs and teams get lost in those discussions and politics instead of focusing on the actual requirements and code.

Adding more developers increases the technical debt because they work on separate parts of the code base. Good developers will do it properly and refactor as they go but good developers are hard to find.

Problems that come with adding more people are also known as Brooks’s law from the author of The Mythical Man-Month: Essays on Software Engineering

Software development is difficult and a project needs people to understand all the intricacies of this project (Business knowledge, people, existing technical solution, tools, etc.)

Brooks’s Law focuses on projects who are already late but the main points

• It takes time for people added to a project to become productive.

• Communication overhead of adding more people

• Limited divisibility of tasks

The bigger the project the harder and longer it takes people to become productive. On Boarding is underestimated. When starting a project you need to learn

• Business knowledge

• Existing technical solution

• People on the project

• The way the project works, it’s flow

• Tools and software used on the project

The more people the harder to communicate with them all, the more meetings that pop up! You can slow down the project by adding more people, the opposite of what is intended.

The divisibility of tasks refers means you can’t always split up tasks for multiple people to work on simultaneously. Summarised by this quote

“Nine women can’t make a baby in one month”. Fred Brooks

Working on the weekend

You can work harder, work more days and hours by working weekends, the elapsed project days stays the same but the team can deliver more.

This can work in the short-term, but it should be a last resort. Working weekends is a sign of problems, the development team is overworked. It burns out the developers, giving them no time to rest and recharge.

Longer hours results in developers working harder but not more getting done because IT projects are about quality development. Development needs thinking, creativity and experimentation.

Reduce time spend on automation, quality etc.

Faster development leads to lower quality. Taking shortcuts, cutting corners, delivering to lower standards seems to get the project ahead but it’s an illusion. The code will be more complex, technical debt will build up and the debt will be paid later in the project.

The project will slow down when existing code needs changing or extended, the lower quality (highly decoupled, brittle code) will be harder to change and take longer.

Lowering quality gets you ahead now, only to fall behind later

Unit testing, automated testing and a tester gives the developer a short feedback loop. Short feedback loops allow you to test code and find problems and bugs, you fix them whilst deep into the code and an expert. The further away (longer) your feedback loop is the slower bugs take to fix.

Development is about creating quality, fix code nearest its creation is most efficient.

Quality makes you go faster

If the code quality is low, it leads to legacy code. Low-quality code creates technical debt and has a higher interaction time unless the technical debt is cleared up.

In the short term missing quality steps speeds up the creation of code but long term cost is an increase in the interaction and maintenance. The short-term gain is replaced with long-term pain.

There is a delay before low quality code makes an impact but as the poor quality code grows (as the project progresses) development slows down.

In short development team should focus on practices like

• Code reviews

• Automated code checking tools

• Unit tests

• Definition of done

• Automation

• Culture

• Continuous delivery

• DevOps

• Observability etc.

To create quality code that can move faster from development to production. Inferior quality code is created faster but then slows all the developers and the project down.

Summary

Working functionality is the measure of all projects, the smaller the release cycle, the quicker value is generated.

The traditional measures of speeding up projects are adding more people, outsourcing, working harder or reducing quality. Scaling the team should be done when the existing team is working well. Reducing quality never gets you a head, it moves the problems to later in the project. Most attempts at speeding up projects have been unsuccessful, it often seems people get to a situation where they must hit a deadline but without anyone really thinking why or how this particular date was decided.

Build trust in the developers. Help them to improve. Build a sustainable learning culture. Promote knowledge sharing. Focus on continuous improvement and these will pay off with faster releases and happy customers than the traditional methods.