But... "time to market!", "we won't have cash by the time this gets implemented properly" etc etc are the usual suspects here.

▲

conductr 5 hours ago | parent [-]

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.

▲

skydhash 4 hours ago | parent [-]

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.

▲

rob74 3 hours ago | parent | next [-]

> 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.

	▲	skydhash 26 minutes ago \| parent [-]
		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.

▲

mapleleaf1921 3 hours ago | parent | prev [-]

I agree, but I think you've not understood what the reply above is saying.

You will never get the chance of "customers requesting changes" if you never ship.

The company with the janky code that shipped will. And they will iterate and get better - as described by your process.

	▲	skydhash 31 minutes ago \| parent [-]
		> 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.