Velocity vs. Quality
Last week, I started working at a very fast growing startup that has been opened for a few years, and I had a chance to look and examine one of the project’s codebase and then get to know what’s the next move for the business …
It really surprised me.
But not in a good way though.
.
The project structure and design patterns implemented in the project are almost impossible to do unit testing. Tight couplings, single layer implementations, and unnecessary TCP handshakes everywhere.
What’s the problem with that ? Right ? As long as the software is up and running why should someone cares ?
.
You’re right … as long as you’re so COMPLETELY SURE that there won’t be another feature that your company’s board wants to add into the product.
and YES! you’re right again. Not in this case (and most other cases as well). There are tons of features in the backlog, waiting for 10+ different engineers to develop and implement… and that’s not all…We are hiring MORE.
.
After I processed all of those messy stuff in my head, I finally went to ask the CTO and my team about the reason behind all this. The reason I got was understandable and I learned one of the most important things when running a company with some technologies driving it.
Pressure is on us
The company’s board wants this new product to be on the market as soon as possible, so there is very little time left for thoroughly thinking and designing code structure. After working really hard (and fast), the team puts the product on the market…
Yey!, it’s up. The board is happy because the product is working on the fly without any complaints from the users… So they thought the product’s quality is high… as well as the velocity… and they thought if they hire more, the new version of the product should be out faster and faster.
Well, they’re wrong. Their view on quality is only on the surface of the product, which is one valid view but there are more than that. The internal structure of the product needs to be well implemented so the future developing speed can be retained. It’s harder and consume more time to add new features into the messy code than the structured one. Not to mention that there are tens of individuals fixing and implementing on the same ‘zero-unit-test’ project.
How hard is that .. ? How many times will the newly developed feature of one engineer brakes another engineer’s code on staging/production server ? How many hours will it take to investigate and fix those bugs ?
.
Yes. You may get the early versions of the app working really fast.
But the technical debt you created will gradually slow down the development speed … and one day … you might have to rewrite all the codes again from scratch.
Understands then compromises
The only way to fix all this requires each party to understand each one another. Business needs to understand us and we have to understand business. They need to understand the debt of developing with zero research, and we also have to understand the effect on the market shares when our product is being developed slower than competitors.
If those can happen … compromises are yet to come.
.
E: Can we have one more time for refactoring ?
E: We really need to write tests, so can we work on this feature on the next sprint instead ?
.
B: Hey guys, we really need to provide our users the payment feature. Can you finish that on Thursday please :) ? we want to get feedbacks from the customers
.
Developing a software is a craft. It takes time to research and design. On the other hand, building a company somewhat requires execution. There is a first mover advantage so you have to move fast. However, those two things can be merged if each part of the company understands one another.
Remember. People, product, then profit.
