4 ms·

> Since we were only “two months” from shipping, making changes to the engine for the better was regularly passed over for band-aiding existing but sub-optimal

by kqr 4y ago

> Since we were only “two months” from shipping, making changes to the engine for the better was regularly passed over for band-aiding existing but sub-optimal solutions, which led to many months of suffering I'm having a version of this problem right now. One of our products is not going to be sold to new customers at some point soon (but will continue to have plenty of existing customers), so it receives a small-ish budget for maintenance. A lot of people seem to believe that this means any problems should be patched over with duct tape at the cheapest possible up-front expense, even if it comes at the cost of increased complexity. I think of it the other way around: we are going to be forced to maintain whatever complexity we add to this with a very small budget, so at this point we shouldn't make any change that increases complexity. Ideally, we'd only make changes that decrease complexity! Even at higher up-front cost. But it's hard to get people to understand the logic of that. I might not be phrasing it well. It's a little like business people and developers think that most of the budget of an actively developed product goes to new development and only a small fraction is needed for maintenance, when in practise it seems to me to be the other way around.

grecy 4y ago
During my Software Engineering degree it was hammered into us that 20% of the cost of a Software Project comes before launch day, and the other 80% is maintenance. In my experience, I'd go 10/90.
- celdon25 4y ago
  What school was that if I may ask?
  - grecy 4y ago
    Swinburne University in Melbourne. The degree is accredited by the Australian Institute of Engineers. (At the time, the only Soft. Eng. degree that was)
- kqr 4y ago
  I feel like that rule conflates two different things: initial launch and maintenance. New development (creation of new features etc) can happen past launch, and maintenance (fixing bugs in "finished" features) can happen before launch.
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.
sethammons 4y ago
"There is no time to get in the car; hurry up and push it!"
sfteus 4y ago
This was one of the larger of many reasons I left my previous company, which was a holding company that owned several products with similar audiences and feature sets. They bought a new product at the beginning of the pandemic that was deemed the primary replacement for the rest. Basically spent ~3 years as the sole developer on an application in "maintenance mode" that kept getting more customers since it supported a bunch of features the intended replacement didn't. That increased client base wanted new features in the maintenance product that leadership wouldn't turn down. The product still maintained a turn-around time an order of magnitude less than the primary replacements. A few days before I tendered my resignation, the company had laid off about half the development team for the primary replacement (even though they had contracts promising work that was planned to take 12+ months with the full dev team), and declared a different product as the "primary replacement" for the other ones they held. Don't know how that will work out for them, don't really care either. New place has a standing policy that basically says if we can prove a maintenance system is taking more than a few hours a month, they'll authorized repairing/replacing/removing said system. It's incredible how much of a difference it makes on employee morale not needing to constantly context shift to spend a few hours fixing some broken system over and over again.

by kqr 4y ago

grecy 4y ago

During my Software Engineering degree it was hammered into us that 20% of the cost of a Software Project comes before launch day, and the other 80% is maintenance. In my experience, I'd go 10/90.

celdon25 4y ago
What school was that if I may ask?
- grecy 4y ago
  Swinburne University in Melbourne. The degree is accredited by the Australian Institute of Engineers. (At the time, the only Soft. Eng. degree that was)
kqr 4y ago
I feel like that rule conflates two different things: initial launch and maintenance. New development (creation of new features etc) can happen past launch, and maintenance (fixing bugs in "finished" features) can happen before launch.

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.

sethammons 4y ago

"There is no time to get in the car; hurry up and push it!"

sfteus 4y ago

This was one of the larger of many reasons I left my previous company, which was a holding company that owned several products with similar audiences and feature sets. They bought a new product at the beginning of the pandemic that was deemed the primary replacement for the rest. Basically spent ~3 years as the sole developer on an application in "maintenance mode" that kept getting more customers since it supported a bunch of features the intended replacement didn't. That increased client base wanted new features in the maintenance product that leadership wouldn't turn down. The product still maintained a turn-around time an order of magnitude less than the primary replacements. A few days before I tendered my resignation, the company had laid off about half the development team for the primary replacement (even though they had contracts promising work that was planned to take 12+ months with the full dev team), and declared a different product as the "primary replacement" for the other ones they held. Don't know how that will work out for them, don't really care either. New place has a standing policy that basically says if we can prove a maintenance system is taking more than a few hours a month, they'll authorized repairing/replacing/removing said system. It's incredible how much of a difference it makes on employee morale not needing to constantly context shift to spend a few hours fixing some broken system over and over again.