1 week ago 🤯 for day 281, with 415 words.

Tech that was never paid

When a small company starts its life, building "next great thing", it always takes the shortcuts. Most of them are reasonable since for small companies that are just starting, it's matter of life or death. Bad decision or lack of velocity may show company as insignificant in comparison to other players on the market. In development, tests are one of the shortcuts that are taken early on — or exactly not writing them.

It all makes sense but when this small company eventually stays afloat for some time and it grows, this lack of tests may bite at some point. This is something in industry we call "tech debt" but I'm not sure if that's correct phrase for that. Tech debt seems to resonate with me — and I assume with other — like something you borrow and with time you have to pay back with additional interest. For me, tech debt is just saying "since this doesn't has to be done now, it can be postponed later". It's more of a prioritisation that actually "borrowing" something.

Now the question stands "what can be postponed during software development? What shouldn't?". This is kinda tough because it has to balance both business side of providing value to the customers with software engineering quality assurance. There are some questions that may help with that like "will we change this in any near future? can we write it that it will be easier to extend or even remove?". There are patterns that may help in object-oriented programming with that. Or just use functions if you fancy functional style.

Tests though is something I think should never be tech debt. Tests are something that speeds up velocity by automating quality assurance process. You can hire quality assurance specialist or just automate most of the work he does. There — obviously since there is still such position — is need for those people. Unfortunately, in my experience so far in the industry, I saw those people used as a manual testers that just click app around making sure that developer didn't break something.

Developers should take responsibility for what they ship. It doesn't mean that they cannot make errors — they are still humans and all humans make them. But throwing responsibility of results of own work to other people seems amateur. And in bigger scale, I think it's also inefficient.

And the title of this post? Well, let's just say that today I found lack of tests in some places.

User Photo

By Bartosz Łęcki

🤯

Product engineer on a journey to actually learn how to write and get inspired by other people writing here!

Get Bartosz Łęcki's newsletter

Almost there! Check your inbox and click the link to confirm.

Subscribe to Bartosz Łęcki's latest writing to get it right in your inbox.