[pxc]

> If most software engineers want to legitimately call themselves engineers, the field should be formalized as an engineering discipline, including coursework, certification/licensure and, better yet, apprenticeship-like experiences required for "real" engineers working toward their Professional Engineer license.

I agree, although in reality it's not chiefly developers themselves who are responsible for quick, lazy approaches, is it? Developers are typically the parties most pained by technical debt. If the discipline of software development is to become software engineering in earnest, there will have to be some pressure all the way up the management chain— pressure strong enough to outweigh software's low cost of iteration. I imagine this is really rare outside of highly regulated industries and very specific applications, and even with a formalized software engineering discipline, many companies will prefer sloppy software development and many competitive markets will 'select for' such companies.

[ethbr1]

> although in reality it's not chiefly developers themselves who are responsible for quick, lazy approaches, is it? Developers are typically the parties most pained by technical debt.

I'd agree with you, except... ooh, a new, shiny, untested language / framework / platform to rewrite the codebase in!

[hello_moto]

Yup, like for example: Rust!

[pxc]

Rust isn't really new or untested, though. I issue with RIIR isn't Rust so much as the act of rewriting, which carries inherent risks.

I think the temptation to rewrite also reflects how messy and unworkable we let codebasee get— sometimes that impulse is more about the pain of working with the existing codebase than anything else.

[ethbr1]

To me, the tragedy of rewriting is the underappreciation of why the gnarliest 5% of the codebase is there.

Occasionally, usually because initial requirements were sorely lacking or changed, you can simplify the system via rewrite.

More often, everyone ends up realizing they didn't actually understand that last 5% of edge cases.

And then you've either replaced the working system with a 95% complete solution (so common in modern software) or you produce a system equally ugly once you handle that last 5%.