3 ms·
In 20+ years I don't think I ever worked on a "well-defined problem". It's always a fuzzy nebula and the only way to get insight is to build some prototype, se
by MichaelRo 3y ago
In 20+ years I don't think I ever worked on a "well-defined problem".
It's always a fuzzy nebula and the only way to get insight is to build some prototype, see how it behaves and improve upon it. With the inevitable "suboptimal" early design somehow enduring and adapting through successive iterations, never have time or be able to afford a full rewrite from a business perspective: stuff works for the client, regardless how terrible the engineers view the build process. So people love to lament how awful the early choices were and how far in outer space we'd be, should some shiny late-stage idea have been applied. But it's a lot more like the x86 CPU architecture, in spite of all the detractors, it endures.
Ahh, and I've also worked for a company that did rewrites. A lot of them. Like every time the product reached some 80-90% of functionality, they'd throw everything away and redo from start. Never shipped anything in my entire stay there. Again in my life I never seen such a thing, it's like the managers were not right in the head and developers were lacking any common sense. So it shouldn't come as a surprise that now (after some 5+ years of this) they closed and fired everyone.
- camjohnson26 3y agoOn the flip side the code bases I’ve worked with that were built with exploratory coding, instead of deeply understanding the problem and designing a solution, tend to be buggy, slow, and stressful to work on. I think it’s a balance like anything else.