3 ms·

Time to have a conversation with your manager to understand his point of view. I am managing teams that are shipping new products and I have a very different an

by IMTDb 4y ago

Time to have a conversation with your manager to understand his point of view. I am managing teams that are shipping new products and I have a very different answers to these kind of questions based on the business needs : - Sometimes we are fully convinced that the new feature/product is going to be used and generate revenue and that we will have to maintain it for months after ship date. In this case it's often worth it to do things "right" as a bit more time early can save a ton of time afterwards. This is typically the case for incremental updates of an existing product with an established client base. - Sometimes we have no idea on the success of the product/feature. Doing things "right" is far less critical that just shipping, as their is a non negligible chance that you are just unknowingly wasting time on a useless component. Doing a useless thing "right" has no value, spending more time on it is pure waste. You often see "horror stories" written by engineers about products that were rushed too fast to prod, became a hit, and had to be significantly re-engineered. Business wise, these actually are success stories as the business was able to create a successful product, sell it, then improve it. Even if things were a mess behind the scene. You also sometimes see engineer being proud of winning a fight with management in order to improve a product before shipping, and then having that product being a massive success. Take care that there is significant survivorship bias here: you almost never see the same engineer writing about the product he perfectly engineered, fought to push the release date and that got 0 user. He'll consider that the lack of business success has nothing to do with him. These things happen all the time, you should consider that the default state of any new significantly innovative product or idea is to generate a total of 0 revenue, and you should act accordingly by helping the business validate the idea as early and fast as possible. And sometimes that means taking on technical debt. A great engineer will be able to accept that estimating the success of a brand new product/idea/feature is extremely hard and adapt his approach depending on the situation, accepting debt in the process if needed, going to prod "too quick if needed etc. The same engineer can also afford to be ruthless in asking for time to do things right when the business aspects have been validated because he has shown his ability to compromise and understand the context in which he operates.

kqr 4y ago
You're absolutely right! In this case we're talking about an old feature with known proven value that has stopped working in a new deployment context, and will take some reworking to get going. That said, I'm not married to the idea of getting it working at all. I'm perfectly fine with scrapping it entirely. That's a business decision I currently don't have the data to judge on. All I'm saying is that this is something where if we are going to build it, we know are going to have to support it for a long time into the future. So if we fix it, it should be fixed at low added complexity. But it's also an alternative to declare it dead, of course.
prox 4y ago
Thank you for that point of view. Thinking as a customer here, the amount of times I didn’t buy a product because it was bad or in a state I would call incomplete is great indeed. Shipping something incomplete, broken or not up to task can kill a product well before it’s given a good chance. Only a few times I have given a product a chance if I saw some hope in it.
chmod600 4y ago
There are a few things you left out: 1. Doing things right often results in releasing faster. But wildly unrealistic schedules sometimes cause teams to reject the right thing infavor of the "quick" thing you pay for ten times over before release. 2. The word "debt" implies that it can be paid off. In many cases, removing the complexity introduced is simply inteactable. 3. Complexity has a huge cost throughout the entire stack -- testing, building, fixing bugs, etc. A shortcut may just be a shortcut, but if it introduces additional complexity, that's qualitatively different and you need to be careful.

by IMTDb 4y ago

kqr 4y ago

You're absolutely right! In this case we're talking about an old feature with known proven value that has stopped working in a new deployment context, and will take some reworking to get going. That said, I'm not married to the idea of getting it working at all. I'm perfectly fine with scrapping it entirely. That's a business decision I currently don't have the data to judge on. All I'm saying is that this is something where if we are going to build it, we know are going to have to support it for a long time into the future. So if we fix it, it should be fixed at low added complexity. But it's also an alternative to declare it dead, of course.

prox 4y ago

Thank you for that point of view. Thinking as a customer here, the amount of times I didn’t buy a product because it was bad or in a state I would call incomplete is great indeed. Shipping something incomplete, broken or not up to task can kill a product well before it’s given a good chance. Only a few times I have given a product a chance if I saw some hope in it.

chmod600 4y ago

There are a few things you left out: 1. Doing things right often results in releasing faster. But wildly unrealistic schedules sometimes cause teams to reject the right thing infavor of the "quick" thing you pay for ten times over before release. 2. The word "debt" implies that it can be paid off. In many cases, removing the complexity introduced is simply inteactable. 3. Complexity has a huge cost throughout the entire stack -- testing, building, fixing bugs, etc. A shortcut may just be a shortcut, but if it introduces additional complexity, that's qualitatively different and you need to be careful.