I have only skimmed the text but regarding GUIs specifically the list in the end is spot on.
With that being said, I firmly believe that all software (given that one is not already deeply familiar with the domain) is/can/should be written three times to end up with a good product:
1. Minimal prototype. You throw something together fast to see it can be done, taking shortcuts and leaving out features which you know you will want later(tm).
2. First naive real implementation. You build upon the prototype, oftentimes thinking that there is actually not that much missing to turn it into something useful. You make bad design decisions and cut corners because you haven't had a chance to fully grasp all the underlying intricacies of the domain and the more time you spend on it the more frustrating it becomes because you start seeing all the wrong turns you took.
3. Once you arrive at a point where you know exactly what you want, you throw it all away and rewrite the whole thing in an elegant way, also focusing on performance.
(1) and (3) are usually fun wereas (2) fast becomes a dread. The main problem is that in a work context you almost never are allowed to transition from (2) to (3) because for an outsider (2) seems good enough and nobody wants to pay for (3).
dustingetz•1d ago
i would add that the reason no product manager wants to pay for #3 is because historical attempts to do so have overwhelmingly resulted in cost/schedule overruns; did-not-finish outcomes are common. Let he who believes otherwise demonstrate so with his own money, this is called a startup and note that virtually all startups fail i.e. run out of some critical resource without finishing! So what is a wisened product manager to do? No easy answers here - simply look to the industry to see what the average outcome is. And it is not for lack of trying. in my opinion software delivery is not a solved problem. but it is really hard to make money as a software delivery expert by going around and saying that you don’t know how to deliver software.
bonki•1d ago
I hear what you're saying but my experience is that dwelling in #2 without seeing the bigger picture does very often just as much result in cost/schedule overruns, because shoving certain features or trying to improve certain aspects just collides with the status quo and sometimes cannot be easily accomplished if things are built "wrong" to begin with (wrong often just meaning that they were based on then-relevant prerequisites/assumption which are no longer relevant). Also, the cost of maintenance is often just not taken into account, which means that in the end you have to spend way too much time to shoehorn a half-baked solution into the status quo which has the appearance of delivering what was requested (but doesn't always, because you had to compromise, leaving everybody unhappy) while taking way too much time and at the same time just piling more bloated poo on top of what's already there, making maintenance in the long run even harder. I can't count how many times I've been in a situation where implementing something shouldn't have taken more than 30 minutes but because the codebase was in a not-so-good(tm) state took several days instead. This piles up exponentially, resulting in frustrated developers, a worse product and cost/schedule overruns. In a perfect world, code should improve over time, not deteriorate.
bonki•1d ago
With that being said, I firmly believe that all software (given that one is not already deeply familiar with the domain) is/can/should be written three times to end up with a good product:
1. Minimal prototype. You throw something together fast to see it can be done, taking shortcuts and leaving out features which you know you will want later(tm).
2. First naive real implementation. You build upon the prototype, oftentimes thinking that there is actually not that much missing to turn it into something useful. You make bad design decisions and cut corners because you haven't had a chance to fully grasp all the underlying intricacies of the domain and the more time you spend on it the more frustrating it becomes because you start seeing all the wrong turns you took.
3. Once you arrive at a point where you know exactly what you want, you throw it all away and rewrite the whole thing in an elegant way, also focusing on performance.
(1) and (3) are usually fun wereas (2) fast becomes a dread. The main problem is that in a work context you almost never are allowed to transition from (2) to (3) because for an outsider (2) seems good enough and nobody wants to pay for (3).
dustingetz•1d ago
bonki•1d ago