Blunder Dome Sighting  
privacy 
 
 
 

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.



Click for Blog Feed
Blog Feed

Recent Items
 
Cybersmith: Ye Motley Or Maven Be?
 
Ed Nisley on Software Engineering
 
VC++ Novice: What's the Visual C++ Express Edition...
 
Code-Monkey Challenge: What is the PSDK Target-Pla...
 
What Is Object-Oriented Design? I have noticed tha...
 
Why Not .rtfx? The Suitability of RTF for Open Int...
 
Recipe for Nano-ISV Success? J. D. Meier just post...
 
The Difference Between Resolution and Size: Or, My...
 
Specialization is for Insects I’ve become a regula...
 
Getting to Unicode: The Least That Could Possibly ...

This page is powered by Blogger. Isn't yours?
  

Locations of visitors to this site
visits to Orcmid's Lair pages

The nfoCentrale Blog Conclave
 
Millennia Antica: The Kiln Sitter's Diary
 
nfoWorks: Pursuing Harmony
 
Numbering Peano
 
Orcmid's Lair
 
Orcmid's Live Hideout
 
Prof. von Clueless in the Blunder Dome
 
Spanner Wingnut's Muddleware Lab (experimental)

nfoCentrale Associated Sites
 
DMA: The Document Management Alliance
 
DMware: Document Management Interoperability Exchange
 
Millennia Antica Pottery
 
The Miser Project
 
nfoCentrale: the Anchor Site
 
nfoWare: Information Processing Technology
 
nfoWorks: Tools for Document Interoperability
 
NuovoDoc: Design for Document System Interoperability
 
ODMA Interoperability Exchange
 
Orcmid's Lair
 
TROST: Open-System Trustworthiness

2007-06-20

 

Cybersmith: Design Stamina and Technical Debt

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.

Cybersmith Challenges

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 [1].

Fowler's Distinctions

Fowler applies two useful notions in his analysis: design stamina and technical debt.

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?
     
Design Stamina
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 [2].  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.

[1] 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.
  
[2] 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.

 
Construction Structure (Hard Hat Area) You are navigating Orcmid's Lair.

template created 2004-06-17-20:01 -0700 (pdt) by orcmid
$$Author: Orcmid $
$$Date: 10-04-30 22:33 $
$$Revision: 21 $