Speed and quality are two conflicting factors of a software development project. The proper development process includes analysis, design, solid implementation and rigorous testing. Because of tight deadlines management is often willing to speed up or skip steps that are deemed less necessary entirely and trade delivering the best overall solution for delivering quickly. Of course, both code quality and shipping speed are essential. Shorter time to market increases the chances of the product we are building, and good code quality makes the product more stable and making changes in the future becomes significantly easier and faster.
Factor #1 — Bad process
Development speed improvement does not necessarily degrade code quality. It depends a lot on the process you have within the team — how well written and thought through user stories are if you have both system design and UI designs prepared and done correctly, is everybody in the team on the same page and understand what and why they are doing.
It also depends on the decisions made by developers previously — how well they mitigated risks, how good are the options to proceed created by previous code and deploys, completeness of the code and if developers need to rewrite it after code review. Management process plays a significant role too — a lot of improvement can be made if you analyze how fast decisions are made on the run, how well team coordinates and how often the ball is dropped because of the flaws in communication or processes.
Having everyone to have their head in the game will also give you a big boost. Magic happens when every team member is looking to understand as much as possible and do his best for the project, reaching out for clarification and help when needed. There’s a big difference between semi-automatic coding and coming up with the best options and solutions. You’ll be super fast and efficient if you do all those things correctly, and you won’t have to sacrifice code quality at all.
Factor #2 — Not addressing technical debt
Technical debt is a big topic itself, I will talk about in a separate post, but it can and will slow development speed of your project significantly. Growing technical debt over time is inevitable for any long-term project — typical application contains a lot of moving parts that need maintenance and upgrades. Updating one part of the system can have a rippling effect across the whole application, so these updates are postponed and pile up creating a debt.
Another source of technical debt is when things haven’t been implemented correctly or were postponed due to emergencies. These trade-offs and shortcuts asked by management, like ’making it scale later’ are slowing down the development team until implemented properly. They are causing double work to the point where you can no longer measure true development speed.
When technical debt is building you need to find time to pay it off. Building it up is inevitable, but you need to find time to refactor and fix it. Having to do extra work for the sake of the system health should not be considered as slowing down. We have to admit that software development is not just about cracking out features but the entire set of activities to keep the product well, scalable and happy.
Factor #3 — Team size
It’s natural for management to hire more people of more work needs to be done. Unfortunately, nine women can’t make a baby in one month. Adding more people to the team will only work if you can divide bigger tasks into smaller subtasks where individual contributors won’t affect the work of each other. Otherwise, a lot of time will be spent on coordinating developers working on the same parts of the code.
Communication becomes a bigger problem as the number of people working on a project grows. If you don’t manage that well a growing amount of time will be spent on useless meetings and activities that don’t lead value and make work even more confusing.
Note that adding people to the team will slow down development in the short-term — conducting technical interviews will require developers to switch from the job at hand. New hires will also need at least a couple months to get onboard and appropriately trained to get up to speed.
Factor #4 — Team’s skill level
It’s not a secret that developers with higher skill level solve problems faster and tend to create simpler solutions. Consider hiring specialized senior developers if your project is on a tight schedule. They will be able to handle more complex work in a shorter period of time while less skilled developers work on tasks that are more typical.
If you are planning for long-term, you should encourage your team members to learn and develop new skills continuously. Send them to conferences and workshops, award them with the subscription to online learning materials and let them buy books they need. Not-so-skilled developers are still a good investment for the team as long as they are enthusiastic and keen to learn. Investing in your team’s skill level will improve product quality and increase development speed over time.
Do you think you can increase development speed without making your team hate you? I’m pretty sure it’s possible. One of the key things is to have clear goals set in time. Never have your team working in an endless sprint where the goal they are trying to pursue is moving away all the time. Short sprints are acceptable from time to time and can even be beneficial, but if you exploit sprints too much, your team will get burned out.
Don’t forget to make sure that everything you team develops actually becomes part of the product. There’s nothing more demotivating than spending months on building a feature that was never needed by the end users. Regularly check with users to make sure you are building the product they want. It will also help you guide the team and ensure that the right things are prioritised. Make sure that everyone understands the high-level vision.
