maintenance for startups - the holy grail of opportunities

There is a preconceived notion about maintenance that it is a “janitor job”. I think this idea stems from big old prehistoric corporations, like Microsoft, Aol, Dell, where the chain of command is so big that it kills your desire to make a change to a broken process before you even get through the half of necessary approvals.

Young tech startups are different! As a developer you have more power than you think and building the next shiny feature should not be the only focus.

First let’s agree on one thing - no matter what type of product you sell, your code needs to be maintained. And I bet you that your code sucks and you know it.

Here is a typical startup story:

You write your first prototype, it’s shitty and breaks, but you get enough attention from VCs or whoever is going to put the money in your pocket and now you can get a few developers on the board and make your prototype a product. The only problem is that your investors want to see the return on their investment as soon as possible. So, your few developers now scramble to build the necessary features. If there is any luck, there might be some documentation and some comments sprinkled across the code base.

You deliver your first product to a customer and it works! You can’t believe it and you go to celebrate it! But there is this nagging feeling that tells you that you left a trail of bugs here and there. You also know that you did not make the best decisions regarding the infrastructure and the architecture, but hey you had to deliver and you did. So, you promise yourself that you will go back and clean it all up. Only now you have 5 more clients to onboard or you have thousands of users that are pushing your app to the limit and you have to deal with that first!

The investors are happy with the first run through and they poor more money into your startup and you get more developers, hoping they can clean up the mess. Only now you need to add even more features and the dev ops person keeps asking for more resources and the sales people selling features that has not been even planned to be built, and your 10,001 user just brought your server down and etc.

This happens across most startups and if you say your startup doesn’t suffer from this plague and your code is squeaky clean, then you are lying to yourself.

So, where I am going with this. Remember how in the beginning you were fascinated with programing because you loved the idea of fixing problems and you could use different tools and you felt like a king of the world? Well you have the opportunity to do all of that again in the world of maintenance. Maintenance is not just squishing bugs; “firefighting” shouldn’t even be the main goal of maintenance. Maintenance includes constant refactoring of dead and ugly code, improving the infrastructure of the product and coming up with better preventive and tracking scripts that will identify problems before they even happen! And here you ask -“When am I supposed to do all that? I have to deliver this new feature by morning and another in the evening and etc.”

The problem we have in startups is that we do not understand how important the proper maintenance process is! If your developers spend 70% of their time putting out fires and squishing bugs, they will burn out and quit. We all know how hard it is to find good developers; so, why push them to the limit? Get dedicated people, just a few, and let them focus on the gaping holes in your code base. Let your junior new hires to help with maintenance; they will learn your product so much better and faster that way. Believe me your developers will thank you for this and not only your product will be much better but the work culture will get better. Maintenance is not a solution to all problems but it is definitely a step in a right direction and be honest with yourself - your startup needs it!


Now read this

working remotely - how to make it work for you and your company

It’s been almost three months since I have moved to LA and started working remotely. Being the first remote software engineer for Jibe made both me and my company a little worried about how this would work out. I have not been fired yet;... Continue →