The problem is those shoddy foundations can support a lot of weight before they finally fail. A prototype you write in a day - not a big deal to throw away. However if you have been working for a while that is a lot of effort/money.
Worse, often you need to spend years before you realize how an initial design decision was a mistake - not only are you proposing to throw away millions of dollars worth of work - you also don't know that your proposed better design is really better.
More than half the time it is correct - until you figure out those things you are asking to focus on you won't know what really works. Going for ideal now just means when you get to those things you discover another thing you hadn't thought of in advance and so you are no better off.
Experienced developers in a domain can sometimes anticipate the issues, but experience only comes from failing.
The real answer is allowing some budget to fix things and then fixing them as you go along.
Sounds like valid issues to me. Pristine software isn’t the objective of most businesses. Leaving as a problem for another day, if we’re lucky that day will come, for many businesses, products, and startups it doesn’t and the shoddy prototype usually isn’t to blame.
I feel like SWE’s that make this gripe really need to step back and understand their role and the process for value creation. Because it’s certainly a process, the quality of code/architecture matters little if the low bar of functionality is met. Functionality can be sold to customers or used to test the market. It’s basically the whole MVP thing and the MVP should be a bit jank. If it wasn’t, you spent too much time/effort on it.
All said, there’s definitely some approaches to make it less jank from day one. Unfortunately, jankiness is a subjective metric.
It’s not about pristine software. Customers expect something that works. But changes will then be requested and the expectation is that the software will continue working. It’s hard to do that with janky code.
If you have a good architecture and keep good code hygiene, then velocity is easy. Without that, everything will slow to a crawl.
> If you have a good architecture and keep good code hygiene
That's a big "if" however - customers have a tendency to come up with requirements that aren't covered (or only covered in awkward ways) by the architecture you envisioned initially, while many of the well-architected parts will remain unused.
Then redesign the architecture. No need to go for a full rewrite as it can be done progressively. One thing I’ve seen is that people can be afraid to delete code, even if it’s not used anywhere.
> You will never get the chance of "customers requesting changes" if you never ship.
Why does good code imply never shipping?
Managers and Developers have different thresholds for “good enough to release”. The former are not the one on call for bugs or the one that get blamed for outage, but they are the ones that get praised when projects are completed quickly. Anything that’s past demo level is good for them.
I'm not saying they're mutually exclusive. I'm just saying that we can't expect them to come as a packaged deal.
For example:
Company A - janky code, ships quick
Company B - great code, ships quick
Company C - great code, ships slow
Company D - janky code. Ships slow
The average survival rate will be in the following order:
B > A > C > D
My point is company A will capture the market and iterate quicker than company C.
Company B is what you're probably thinking of , and what many people think they are building.
Company D is what most people are actually building.
Company C will win out in the long run over company B if they have capital and network.
I don't think I've ever not learned a better way to write something after writing it. Sometimes it's small and insignificant, sometimes it "forces" me to start over. The funniest is when more than half the code deals with something that won't happen. The banana that is not a fruit clause.
You can prototype UX with a tools like balsamiq or taking photos of paper sketches with paper-to-app application. No need for code to share an idea. Especially from business to engineering or vice-versa.
Product Managers coding is like Developers writing marketing pitches.
Worse, often you need to spend years before you realize how an initial design decision was a mistake - not only are you proposing to throw away millions of dollars worth of work - you also don't know that your proposed better design is really better.