Hangout for experimental confirmation and demonstration of software, computing, and networking. The exercises don't always work out. The professor is a bumbler and the laboratory assistant is a skanky dufus.
MF Bliki: DesignStaminaHypothesis. Martin Fowler considers that it is sometimes possible to abandon design-related activity and submit to the "enough with design we've got code to ship" syndrome. He points out that "we don't need no stinkin' design" can be valid ... if you happen to know what you are doing and when the conditions are right.
Fowler offers what he terms a pseudo-graph as part of his thought experiment into design omission as a trade-off (with his legend):
The pseudo-graph plots delivered functionality (cumulative) versus time for two imaginary stereotypical projects: one with good design and one with no design. The project that does no design expends no effort on design activities, whether they be up front design or agile techniques. Because there's no effort spent on these activities this project produces function faster initially.
The basic idea is quite simple: There is some point where omitting design activities may earn deliverable functionality quicker than with any kind of design-tax payments. Fowler examines this and the related risks.
This is a great challenge for cybersmiths, those journeyman/apprentice developers who are just beginning to grasp more of the software and development lifecycle than what imprisoned their novice attentions: the basics of programming languages and the tools that support them. Here's why:
Consciously making this tradeoff depends on knowing what good design is. If good design is not an option, design stamina is irrelevant.
If you don't "know design" then your "no design" effort probably has a far lower design payoff point. Experienced designers can loft far more code without design than no-know-design developers. I suspect that is because they manage to do just-enough design seemingly without effort or having to stop to do it. However, the knows-design developer will ultimately be caught on the wrong side of the design payoff line, it will just be higher in her case.
For the no-know-design programmer to navigate this abyss, some designer guidance is required, even if in a textbook or some existing code. A seasoned player-coach can ensure that the assignment of tasks will be challenging but not overpowering and also be worthwhile efforts, falling within a project's tolerance for low-design chunks. Without that, you're also probably unable to refactor your way out of the bind that happens at some point along the way.
This explains common novice blunders: having an appetite beyond our capability and our stamina. I've got the tiger by the tail, now how do I get it into the frying pan? I could have saved my ass by envisioning the endgame first, but I don't know that, do I? I will be operating somewhere out in the no design region where I don't deliver any functionality whatsoever. I suppose that has to be somewhere on the imaginary plane above Fowler's safe-landing territory.
This also explains some common management blunders: taking out crushing technical debt without recognizing it and then having no means to ever repay it. Management probably needs to understand software lifecycles and risk management far more than the cybersmiths, even without the skill (and certainly no foolish inclination) to do the work themselves.
So your cybersmith sensibilities are developing when you grasp the significance of Fowler's hypothesis, even if you don't know how to exploit it in practice. Knowing that you don't know, as it were, is the beginning of cybersmith wisdom .
Fowler applies two useful notions in his analysis: design stamina and technical debt.
is a term coined by Ward Cunningham. Quick-and-dirty solutions accrue technical debt as a result of their complexity, brittleness, low understandability, and any other deficiencies (i.e., deficits). At some point in the future, interest must be paid as part of any further development. One can view high cost and proportion of maintenance effort as a demonstration of technical-debt interest payment. Very little of that continuing cost goes into reduction of principle. Ultimately bankruptcy may be declared. Seem familiar?
refers to the idea that good design provides a non-decreasing rate of return as a software deliverable is maintained and enhanced with greater functionality over time . In contrast, low- and non-design activities tend to collapse under technical debt without some sort of in-the-nick-of-time intervention. I find it useful to think of the Tortoise-and-Hare analogy, where the hare wins if the initial sprint is all that is ever required. The hare never sees the finish of a marathon. Fowler explains why this is a hypothesis, even though an article of faith for many of us, in his article.
 Going beyond to knowing that you don't know what you don't know marks the onset of professional mastery. No, I can't explain it; it would do no good to do so.
 To be fair, we must presume that accrual of technical debt is inevitable, but that refactoring and other design-survival efforts can pay back the principle and gain new life for the now-rather-different-internally software. With adequate attention to software lifecycle, it may even be possible to keep up with changes in platforms and environments for a considerable time. It is not easy to know whether a good design will survive such disruptions, but it is far more likely than with no design. And before anyone brings it up, no this isn't by gold-plating. Good designs tend to keep options open for substitution and change as an inherent quality.
This timely posting by Fowler is helping me sharpen the line between novice and cybersmith, as well as look at areas that cybersmiths are still developing in.
This topic raises another interesting question for me. I want to live a Zero Waste life, but I can't understand the economics of living waste free. If I use the price of goods, something that is very easy to do, I notice that on price alone the packaged, chemical-laden items are much lower in price than their organic, ecology-friendly substitutes. Someplace in here there's an unidentified debt and hidden externalities. I wonder if Fowler's thinking can be interpreted in a way that helps me with this. This household question has been on our minds for the past three days.