GUIs are built at least 2.5 times
patricia.no
GUIs are built at least 2.5 times
1–10 of 155 posts
Re: GUIs are built at least 2.5 times
#2I 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).
Re: GUIs are built at least 2.5 times
#3I 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 yo…
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.
Re: GUIs are built at least 2.5 times
#4I 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 yo…
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 ma…
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.
Re: GUIs are built at least 2.5 times
#5I 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 yo…
4. Now you arrive at a point where you really know exactly what you want, you throw it all away and rewrite the whole thing in a better more elegant and performant way.
Re: GUIs are built at least 2.5 times
#6I 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 yo…
"Plan to throw one away. You will anyhow."- Fred Brooks, _Mythical Man Month_
A software engineering book written decades before I was born- my college assigned us the 25th Anniversary Edition- and yet I re-read it every few years and find some new way to apply its lessons to my current problems.
Re: GUIs are built at least 2.5 times
#7I think agile approach to iterative building is kind of obsolete with AI. There is no "12th step agile fast process", with all stakeholders involved. Instead you get experts throwing slop over the wall to stakeholders, to see what sticks.
I made webservice recently. To help me debug and test results, I asked AI to make me a simple CRUD web UI in Vue. Customer liked it, and it was kept in final version.
This UI was not even a prototype. There was no request, ticket or problem to solve. I just needed it to fix other problem, and it was kept as a bonus.
Re: GUIs are built at least 2.5 times
#8I 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 yo…
4. Now you arrive at a point where you really know exactly what you want, you throw it all away and rewrite the whole thing in a better more elegant and performant way.
Number 4 is “huh I wonder if I should rewrite it in rust” ;)
Re: GUIs are built at least 2.5 times
#9The only metaphor I’ve come across that is relatable to non-software people is building a house(in particular Australia because we do it so badly).
As mentioned humans are terrible at imagining things that don’t exist yet.
Re: GUIs are built at least 2.5 times
#10I 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 yo…
Hard agree. (2) is all about building out the test suite; once you have this (3) becomes a cake walk.
I've worked in a lot of places where end to end testing is performed manually by a SIT team who absolutely do not like to re-run a test once it's been passed. These people hate the idea of (3) and will overestimate the costs to the PM in order to avoid having to do it.