Discussion

How do you balance code quality and development speed?

Published May 24, 2017Last updated May 31, 2017
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.

Discover and read more posts from Codementor Team
get started
Enjoy this post?

Leave a like and comment for Codementor

15
9
9Replies
Jayson Minard
3 months ago

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:

  • “go faster”
  • “do better”
  • “what did you do yesterday, what are you doing today, are you blocked?”
  • “what is your status”
Malay Ladu
4 months ago

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.

Anand Kumar Keshavan
4 months ago

There are some compromises that one never should make:

  1. separation of concerns ( separating computation from i/o)
  2. Single responsibility
  3. Size of units (functions, classes)
  4. writing pure functions as much as possible
  5. Parametrising assumptions

Apart from that, I have always ensure that the team agrees upon standardized error handling techniques for the entire team. ( For example, if we use Try/Catch, we use throw at the leaf of the programming graph and catch the errors at the top of the program-- this leaves all the code in between uncluttered without any error checks .)

These techniques require a a little bit of practice and conscious application–but once you get used to it they can improve the quality of code without having any impact on significant impact on time.

Cedric Poilly
4 months ago

About the try/catch example, does it mean that you include all the statements in the try, even those that will not throw?
It seems to make the code much easier to read but I am concerned about performance.

Show more replies

Get curated posts in your inbox

Read more posts to become a better developer