I recently started to notice this pattern that some teams create products and move on. Maybe some maintenance until no one sends more bug reports. They just literally move on from that product, to the next one.

Now this is not new, when I was a consultant this was exactly what companies expect. Work on something and make it to the finish line and leave. It makes sense, you don’t want to keep them around because it’s costly. But at a product company? This does not make sense, why wouldn’t you want the product to grow?

A typical example is that you are working on a new product for the company. You usually have a timeline of when are you going to launch, when to do testing and when to fully release. You work during this time, and after making it to the finish line, you release. Then the company expects all your focus and energy on the next thing. This happens because the company wants to grow in many areas, so they don’t want your focus in only on area.

But the problem is they do it in a way that if you touch a software after deadline it looks like a bad thing. It looks like you missed the release. But it’s actually most of the time you have more information when you work on something. This expectation is what I don’t think is right, that you need to deliver and project should be good without you. Otherwise, they say you created something that needs maintenance and is considered bad.

But this is wrong.

The first reason is that when you develop the product, you learn more. So after doing the initial development. There are just some things that you can never discover in the requirements phase. The reason is not that the person did a bad job in the design or coding. When you make something for the first time, you don’t know some unknowns. It’s because they will know more when they make something that works. And for any problem you just realize the problems with your solution when you apply it. So if you stop the development after the release, you loose that extra knowledge. Use the initial development phase to discover them, and even ignore them but fix them afterwards.

The other problem with this mindset is that people stop caring about the product after it goes live. If they find issues, they tend to ignore them if they are small enough. They would not care about 2% of the cases where the endpoint times out. Because, if you committed to the date and delivered, if you go back and touch the product, it means you did not deliver it on time. Now if this is applied to the every feature and product you are left with a product that has issues in every feature. One page is slow, another one crashes. They only happen to you because you are in that 2%.

I don’t consider rewriting and refactoring bad even after you deliver. There are a lot of things that are just not discoverable before you dive deep into a problem. So by encouraging people to deliver and forget, you create this culture that everything is created to be good enough for release.

I don’t mind rewriting what I worked on for few days or weeks. It’s better than lying to yourself that I made a technical debt. It’s a lie because it’s not a tech debt, it’s a defect, and you know it.

So if you do something for the first time. Expect to fail to come up with the right solution. Accept the fact that you might do it wrong, and need to rewrite it. Teams, should not consider this as a delayed lunch. It’s just that the product is live but, we want to make it better.

That’s all I had to say. I saw this pattern in consultancy and said okay. But I also saw it in product companies, and I’m shocked. I don’t want to see it in my own work.

So don’t be afraid to realized you made a mistake, that’s part of the journey. Use it and rewrite your software to be better.