21–30 of 115 posts
You’re mixing product decisions with code decisions. Product should make sure to create an MVP aka the fastest solution for A-B. Code should be done right no matter what, you’re being paid as an expert to do that, if they would want whatever crappy code gets it done they would do it themselves with some nocode solution and test the hypothesis.
An alternative: Build a PoC first. The reason coding the shortest path first feels better is that you hit milestones early. However, it is a major generator of technical debt, and fleshing out the project is the hard part that takes longer and introduces breaking changes. Taking time to plan, getting the API planned in advance, generalising the code (obviously not TOO much), and so on might feel less rewarding at fir…
> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.
You’re mixing product decisions with code decisions. Product should make sure to create an MVP aka the fastest solution for A-B. Code should be done right no matter what, you’re being paid as an expert to do that, if they would want whatever crappy code gets it done they would do it themselves with some nocode solution and test the hypothesis.
> Code should be done right no matter what, you’re being paid as an expert to do that As I've written in a recent thread... that may be the case in the academic world, but certainly not in the business world, where time-to-market and profitability always trump code quality if not explicitly required / audited by client contracts.
What actually happens is more like :
"deliver as fast a possible, no matter what"
...
"The poc was delivered in a week, why are new features so slow? And can you explain what this refactoring item adds to the bottom line?"
Earlier quoted context omitted.
> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.
There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.
Earlier quoted context omitted.
> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.
> I think this is a relatively popular development strategy. ...And this is why PoCs should be small-scale but technically sound things, rather than a shortcut competition. People are rarely going to complain about a PoC delivered a week late, but they are definitely going to complain later on, after they ship the PoC against your opinion and development slows down.
If a PoC is later extended, it will of course have limitations. We do not need to change the meaning of PoC to full product to preemptively solve that.
Instead, when a PoC is done everybody involved needs to understand the implications. If people insist on misinterpreting them, that is on them. Those are political problems, not technical ones. They can be solved by aligning incentives.
TLDR. A PoC is a PoC, not a full product.
You’re mixing product decisions with code decisions. Product should make sure to create an MVP aka the fastest solution for A-B. Code should be done right no matter what, you’re being paid as an expert to do that, if they would want whatever crappy code gets it done they would do it themselves with some nocode solution and test the hypothesis.
Earlier quoted context omitted.
> Code should be done right no matter what, you’re being paid as an expert to do that As I've written in a recent thread... that may be the case in the academic world, but certainly not in the business world, where time-to-market and profitability always trump code quality if not explicitly required / audited by client contracts.
> where time-to-market and profitability always trump code quality What actually happens is more like : "deliver as fast a possible, no matter what" ... "The poc was delivered in a week, why are new features so slow? And can you explain what this refactoring item adds to the bottom line?"
Earlier quoted context omitted.
Which in itself is a short form of "make it work, make it pretty, make it fast, in that order", which tackles both over-engineering on an architectural and a performance level. For the vast majority of any task that requires writing code, performance is the least of your concerns; your code is fast enough, your compiler and runtime is fast enough, the hardware is fast enough. Use decent algorithms / don't do anything…
This approach of "things being fast enough" leads to everything being slightly slow - we literally had better usability and latency on our devices in the 90s than we have now. It all adds up.
Earlier quoted context omitted.
> because you don’t build on the PoC Ah yes, I remember that idea. Naturally we shipped the proof of concept. Also "it is known" that rewrites from scratch are bad things, so it got iterated on instead of replaced. Based on the internal architecture of other software I've seen I think this is a relatively popular development strategy.
There is a somewhat malicious compliance way of avoiding this, and that's to write the proof of concept in an obscure language or using some other set of tools that makes it impossible to pick up as-is by the rest of the team. The downside is that it also adds an additional cost to you when building it.