Timeline for How to stop the development spec from changing in mid development?
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 2, 2012 at 19:27 | comment | added | frankc | A good quote associated quote from Eisenhower: "I have always found that plans are useless but planning is indispensable" | |
| Feb 2, 2012 at 11:47 | history | made wiki | Post Made Community Wiki by shieldfoss | ||
| Feb 1, 2012 at 17:57 | comment | added | StasM | @sleske I agree, and here is a good place to exercise you judgement. I've seen code that had variables like "days in a week", this is nonsense. But, say, if you have some timeout value, you may want to think "what if the user would want shorter/longer timeout here because his network is very slow or ultra-fast?", etc. | |
| Feb 1, 2012 at 7:48 | comment | added | sleske | @StasM: What Michael Borgwardt wants to point out is: Making things configurable should only happen once you know they must be configurable. There are a million different ways of making something configurable, and if you do it "just in case", you'll likely pick the wrong way - or make things configurable that never change. This actually makes maintenance much harder. Encapsulation on the other hand is a design principle, and usually a good idea. | |
| Jan 27, 2012 at 19:17 | comment | added | StasM | @MichaelBorgwardt I disagree. Simplicity is good, but it can only take you so far by itself. If you have the code: print "OK" it's simpler than variable = getTranslation("OK"); print variable but at the cost of not allowing you the flexibility. Of course, your layers of abstraction should not be empty - YAGNI principle is a good guide. Encapsulation allows you to hide and manage complexity - which sometimes is unavoidable - and make it more change-proof. Of course, you have to know why you doing it, not just do it because you can. | |
| Jan 27, 2012 at 9:32 | vote | accept | David | ||
| Jan 27, 2012 at 8:47 | comment | added | Michael Borgwardt | "invest in configurability, encapsulation" is very, vary dangerous advice. It can too easily lead to inner-platform effect and empty layers of abstraction, both of which actually make it much harder to change a system. The most easily changeable system is the one that is most simple. | |
| Jan 26, 2012 at 22:20 | comment | added | Agos | would +∞ this. points 4, 5 and 6 are really winning strategies. | |
| Jan 26, 2012 at 18:29 | comment | added | Adam Jaskiewicz | Short cycles are key. People are much less upset about something getting pushed into the next two-week sprint than when the "next release" is six months away. | |
| Jan 26, 2012 at 15:31 | comment | added | Joshua Drake | +1 for number 6. I had an excellent experience with the PM implementing that requirement alone. | |
| Jan 26, 2012 at 15:15 | comment | added | tardate | Formalising the change process and being clear on scope is great advice - if you are doing fixed scope/price contract work. In other settings, this approach grinds since it gives schedule and price precedence over scope and quality. Maybe that is what you need in a given situation. But then again, maybe it is not... | |
| Jan 26, 2012 at 10:43 | comment | added | Grant Thomas | You can also 'freeze' them in phases and push changes into the 'next version'. | |
| Jan 26, 2012 at 9:43 | history | answered | StasM | CC BY-SA 3.0 |