How we try to speed up IT projects and why it doesn’t work
The methods we use in the short term to speed up a project, slow it down in the long term
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning. Rick Cook
Code not being used by users is worth nothing, you no return on investment for code that is in development.
People get lost in the fog of a project and forget the purpose isn’t to deliver the project on time, it’s to create software which helps the business.
No one cares about technology, its an aid to doing your job, quicker or automating it. To get a return on this investment of creating software, you need employees using it.
Until the code is in production, it has no value to the business
Releasing quickly
Code should be measure not by how fast it’s written but by how fast working software makes it into production.
Code should be production ready at all times and automated builds to deploy it quickly as soon as business says it’s ready to go.
Some believe a faster release schedule means reducing quality steps, such as testing but the bugs will slow it down the delivery to in the phases beyond development.
Traditional thinking of speeding up projects
The traditional method of speeding up projects is taking shortcuts, working more (weekends, evenings) and creating code faster.
I have written about how rushed projects leads to lower quality
and What’s slowing down your CRM development? for other thoughts on development/release cycle and project quality.
Common methods to speed up projects
- Add more people
- Work weekends
- Reduce quality
- Reduce testing
- Reduce scope
The most effective is reducing scope and this is the choice customers don’t like. One benefit of Scrum is the simple rules regarding scope e.g. if you add a story to the sprint, you must remove a story but often people want to squeeze in one more story but Scrum doesn’t allow that.
Adding more people
Adding manpower to a late software project makes it later. Fred Brooks
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.
Why adding more people to a project doesn’t make it go faster
Adding more developers is like 9 people trying to write a chapter of a book at once, each person writes 5 pages. All 9 people need to know the characters, the plot, what’s happening now, what’s happening in the future, writing standards, where to store it.
The chances of the chapter being written 1st time is tiny, it will take many iterations before you create a coherent story. This is like a team of developers creating one solution, communicating, checking code works with the existing code, code works as specified by the requirements.
Adding more developers increases the technical debt because they work on seperate 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
Adding manpower to a late software project makes it later. Fred Brooks
Brooks explains the problems in seeing people as interchangeable better than I can
“Hence the man-month as a unit for measuring the size of a job is a dangerous and deceptive myth. It implies that men and months are interchangeable. Men and months are interchangeable commodities only when a task can be partitioned among many workers with no communication among them… This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming” Fred Brooks
e.g. 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
Work weekends
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.
When development teams work harder they lose their spark, churn out code of lower quality and contains more bugs. Private lives suffer, weakening their relationships with friends and family. Unless it’s a short time, it will be the start of a downward spiral.
Reduce quality
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
Reduce testing
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.
Reduce scope
You can speed up a project by reducing the scope. Less software to create, equals less to develop and test.
This is effective but unpopular because no one wants to give up functionality and the reason it’s rarely implemented.
I’m a fan of delivering simplified functionality to get it into production and get feedback. Often this is good enough. Simplified functionality is rarely agreed in principle but can gain momentum when seen in action.
Summary
Working functionality is the measure of all projects, the smaller the release cycle, the quicker value is generated.
Large IT projects are difficult, the bigger the project the harder it is. I have read statistics that projects which go longer than a year have a 50 percent failure rate (I can’t remember where I read that state). The difficulties of scaled agile projects.
The traditional measures of speeding up projects are adding more people, working harder or reducing quality (less testing). 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.
Reducing scope is not removing scope entirely but delivering a simpler version to begin with, get it used and make changes from feedback. You can deliver smaller updates and everyone feels good.
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.
The goal of a project is to create a solution which works, it’s better to create a quality solution which takes a bit longer than rush something which doesn’t work. Production issues cause panic, it’s better to fix these when the stakes aren’t as high.
A great book on the problems of IT Projects (mostly people related)
