Discussion
How do you balance code quality and development speed?
Code quality and development speed are two essential - and sometimes conflicting - factors for software development teams.
Proper development requires careful design, solid implementation, and testing. Tight deadlines may compromise this process. On the other hand, applying the best overall solution may stand in the way of delivering speedily.
At Codementor, we believe that both code quality and shipping speed are important. Shorter 'time to market' makes us more agile as a startup, while good code quality makes future development easier, faster, and more stable.
Here's what we do to achieve these goals:
- Make sure all team members from our dev, design, and product teams know why we are building features
- Identify which features are essential for each release
How do you (or your team) balance code quality and development speed?
Let us know in the comments below 👇 or in your own post.
Automated tests
Code Quality is cultural and should always be present. Development Speed is a mix of how well you feed the team their work (well written stories, designs, understanding of what is being done), how well they mitigate risk, that the developers create good options from which to proceed, how fast decisions are made on the fly, how well the team naturally coordinates, the chance of “dropped balls” between people or processes, the quality of the first-write of the code, and completeness of the code. Also include everyone “having their head in the game” meaning that they are looking to understand and do the best for the project so they reach out when they need to for clarification and to come up with the best options, not just robotic coding the minimal.
Do all of those perfectly, and you’ll be fast!
A lot of development speed is lost to things “not done” or “broken things” or “emergencies” that are all artifacts left behind when things weren’t done right to begin with. So trade-offs earlier that leave holes in the system will slow things down later. Any short-cuts you take early like “make it scale later” when it really was almost the same work to just make it scalable the first time – will cause slowness, double work, and problems that eat development team time down the road. At this point you can no longer measure true speed because you muddied the waters by your earlier mistakes.
So if technical debt is building, you have to take the time to unwind it. Refactor it. Fix it. You also need to adjust your thinking (all the things listed above) to limit the build-up in the future. Sometimes it is unavoidable and having the team do work for the sake of the team and health of the system should not be considered “slowing” the team but rather those making this judgement need to understand that not everything built in a system is just the list of features, but the entire ecosystem that keeps the product alive, well, scalable and happy.
One thing that I have never seen improve a development team’s speed is processes such as:
In my opinion it’s not that too difficult to balance code quality and development speed. I believe if we write well thought good quality code eventually development speed will go up. Well thought quality code works on “Write Less, Do More”.
Developers are really code hungry. They directly jump to write code. What I do, first I think whole picture of a problem and figure out 3 alternative to solve that problem and evaluate in mind. Then start with most optimum way and write a code for that. It may take more time to think but will take comparatively less time to write a code.