No, writing good code doesn’t slow things down.
By: Sergio Cleto
Tags: Code, Engineering Mangement, Clean Code, Startup Lessons, Management

When I was in business school I learned that in project management there are some trade-offs that need to happen in every project. Basically, there were 3 main resources that every project needed to be successful, but only 2 could be maximized and the order had to be left behind for the project to be successful. Those resources are money, time, and quality. It’s the famous cost, speed, and quality triangle and you can find it in every project management book that you gonna read in business school.

The logic is that if you want things to go fast, you have to sacrifice quality or it’s going to cost you a lot of money. In a world where time to mark is essential, and only the newest and shiniest products survive it’s only logical that companies always opt to go fast. But not every company is a tech giant with billions of dollars at their disposal, so, commonly, most companies (especially startups) end up sacrificing quality over their hard earned cash. Well, I’m here to tell you that by doing that you are not only going to sacrifice the product’s quality, but also the time that you tried saving in the first place. Let me explain.

“If you don’t have time to do it right, you will end up doing it twice”

Good code saves time

It may sound counterintuitive considering everything I just said. If I made a conscious choice of prioritizing time over quality, how this is going to cost me both? Well, it happens that what we call “good code” or “clean code” is way easier to maintain and work with than code that is made without the proper care or planning. Sure, pretty much every developer can make a feature “work”. The problem isn’t what the user sees, it’s what the user doesn’t. And that’s why most managers that I have worked with have a difficult time understanding the value of a well-written piece of software. It’s possible that for the end-user a poor code and a brilliant code look just the same. The problem arrives when the code needs to scale.

Let’s say that you finished the first version of your brand new app. Everything is going great, your customers love your app, TechCrunch wrote about your startup and investors are knocking on your door. Probably you’ll want to develop some new features for your app, after all, competition is catching up and you can’t just sit still. That’s when the problems start to show up.

The features that you need are going to take significantly more time than before. Even the developers that worked with the source code before are having trouble understanding it, and the new developers are completely lost. All your deliveries are way slower, and your customers are starting to complain about some bugs they are experiencing. Meanwhile, your competitors are catching up, they seem to have more features now and they are also growing faster than you. There is only one option left: refactor the whole code so that your tech team can work more efficiently. In the end, the time that you saved, in the beginning, is all lost.

Planning also saves time

“If you don’t know where you are going, any road will get you there.” — Lewis Carroll

Throughout my career, I helped several startups create their first product. Some of them succeeded, some didn’t. And the most important thing for a startup is being adaptable. Market needs, technology, and customers change really fast and a startup needs to change too in order to compete in its market. The emphasis is always on adaptability rather than planning, and considering the speed that everything changes this is completely understandable. It’s not that you don’t need a plan, it’s more that you need to be willing to change it constantly according to what the market needs. And a plan is a fundamental part of writing good code.

Some managers think that their developers are only actively working when they are typing something on their computers. Some even measure productivity by the number of code lines written (that is the worst metric to measure developer productivity by the way). The truth is that to write some good code a developer will spend a lot of time thinking and planning. There is an almost infinite number of solutions to the same problem, and the best solution depends on the scenario of the task at hand. Two different companies might choose to tackle the same problem in completely different ways, and both of them can be the best solution considering their current scenario.

Understanding the problem and where the company is headed is vital to create code that will easy to maintain in the future. It’s unlikely that a single person (manager or developer) knows the best solution to every problem, so it’s best to start every planning meeting with “We need to solve this problem…” rather than with “We need to code this”.

Conclusion

It’s impossible to do an in-depth analysis of the importance of clean code in just a single article. My goal here is to introduce the concept and some advantages of focusing on quality rather than speed. I sincerely believe that you can’t achieve long term speed without a constant focus on code quality.

About the author: I’m a technology consultant and engineering manager. I have managed teams of up to 17 engineers and helped many products choose the right technologies to achieve growth and market fit. I graduated in business and taught myself how to code. If you need help developing a product, choosing the right technologies, or want to learn how to code please reach me at LinkedIn page: https://www.linkedin.com/in/sergio-cleto-837572a0/