4 ms·
I proposed a re-write for a tool that we needed to use in a different context recently. We built an MVP relatively quickly, but ended up throwing out the rewrit
by jonfw 3y ago
I proposed a re-write for a tool that we needed to use in a different context recently. We built an MVP relatively quickly, but ended up throwing out the rewrite. We had two issues-
1. when we did the rewrite, we ran into a lot of the same constraints we ran into on the original application, and we didn't come up with significantly better solutions
2. we had to continue using and improving the original tool to serve it's original use case, and the dual maintenance was terrible
But there was a huge positive as well. Without worrying about breaking the original use case, we could hack on the new tool all we wanted without regard for stability or reverse compatibility. We got a thorough understanding of how to serve the new use case and why the original tool was designed the way it was
We ended up taking the best stuff from the new tool and bringing it to the original tool, and made the original one better. I am not sure that it was the best use of time, but I'm also pretty sure that we would have never been able to modify the tool as well as we did without the benefit of the rewrite
- throwuwu 3y agoThis is a good example of why it is useful to have more than one person or team work on the same problem in parallel. Yes you duplicate effort but you often come up with better solutions especially if the teams regularly meet to compare notes.
- isaacremuant 3y agoAs long as their "career performance/review" doesn't depend on making their solution/big project work. Otherwise, you're setting either for failure and creating a culture averse to sharing, collab and positive but passionate debate.
- throwuwu 3y agoHow detached does your management need to be in order to f this up? You’d obviously have to coordinate this in a large corp.
- isaacremuant 3y agoYou'd be surprised how common this is. You gotta remember the managers are people playing the career game too. And if it's one of the large corps with a lot of turnover, they have to move fast. Speak with people who work in large corps and you might here similar stories. Problem is people online naturally can't go too deep to avoid doxxing.
- nonethewiser 3y ago> But there was a huge positive as well. Without worrying about breaking the original use case, we could hack on the new tool all we wanted without regard for stability or reverse compatibility. We got a thorough understanding of how to serve the new use case and why the original tool was designed the way it was Maybe good for your understanding, but this is pure waste.
- christophilus 3y agoEnhancing understanding is not waste.
- Kinrany 3y agoThis is no more wasteful than discarding a prototype, the only possible problem here is putting too much effort into throwaway code.
- jimbob21 3y agoHow is more thoroughly understanding an important service pure waste? I could agree with inefficient, but definitely not pure waste.
- nonethewiser 3y agoWhat did thoroughly understanding it produce? It consumed a shit ton of resources - what was the product?
- jonfw 3y agoWhat is software development if not thoroughly understanding the problem? Implementation is rarely the hard part
- ilikecakeandpie 3y ago#2 is the biggest problem I've faced. It's nigh impossible to truly revamp what you have while also having to sell/serve/use/change the existing product. You either have to leadership who is willing to take the hit and stop new features/bugfixes from coming in while you're redoing the product, or you have to pad timelines for new features/bugfixes but that's risky too because you can be seen as someone moving too slow