Timeline for How do you avoid endlessly iterating through equally sub-optimal designs?
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 1, 2018 at 22:25 | comment | added | Dunk | "they've cut their responsibilities in a way that is unnatural to the problem at hand. No good option can be a smell that there's something fundamentally wrong with your approach." I'd bet on this one. Some developers never run into the OP described issues and others seem to do it quite frequently. Often the solution isn't easy to see when posed by the original developer because they have already biased the design in the way they frame the problem. Sometimes the only way to find the quite obvious solution is start all the way back at the requirements for the design. | |
| Feb 28, 2018 at 12:36 | comment | added | Telastyn | @Jonathan - all designs are a series of trade offs. Yes, you should iterate immediately if the design is flawed and you have a clear way of improving it. If there’s no clear improvement, stop fucking about. | |
| Feb 28, 2018 at 12:21 | comment | added | Jonathan | Just thought I should say that I have cleared up some misinterpretations in the edit. I generally do the "get it working" and refactor approach. However, often this ends up leading to a lot of technical debt in my experience. For example, if I just get a thing working, but then myself or others build on top of it, some of those things may have unavoidable dependencies which then also need a ton of refactoring. Of course you can't always know this in advance. But if you already know the approach is flawed, should one get it working and then iteratively refactor before building on the code? | |
| Feb 28, 2018 at 4:10 | history | answered | Telastyn | CC BY-SA 3.0 |