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
 
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 ...
 
Dear Microsoft: No Thanks for the Updates
 
Raymond Chen: What Feature Did You Remove Today?
 
More Spolsky Gems: Open-Source, the Desktop, and S...
 
Is There an MVC in the House?
 
Nano-ISV Are I, Are I
 
Amazon.com: Your Order Has Shipped - Joy to Book R...
 
Tweaking, Tweaking, Tweaking, Roll-on ...

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-03-11

 

Recipe for Nano-ISV Success?

J. D. Meier just posted a prĂ©cis of agile-manager David Anderson’s recipe for success:

  • “Focus on Quality
  • “Reduce Work-in-progress
  • “Balance capacity against demand
  • “Prioritize”

It is Meier’s description of these critical elements that caught my attention.  I can see how, in my latest solo-developer, nano-ISV project, I have been providing precisely these elements and with more consistency than I first realized.  That’s startling for me and I am going to want to come back and develop my report card more thoroughly as a record on which to base future work.

For one thing, I thought that these practices wouldn’t scale down to sole-developer nano-projects, because of the problem of attention and focus in a human being (especially when that’s myself).  My experience says otherwise, and that is very exciting to see unfolding into full bloom.

It’s great to be led back to Anderson’s work via Meier’s links in the article.  I subscribe to the blog, but sometimes another perspective drives me back with new eyes for what’s there.  This time, I even resorted to Wikipedia so that I could figure out what a kanban system is.  I also wonder why I resist applying that specific technique, now that I understand how it provides critical focus.  I do know that right now I am risking the “overhead of running each iteration like a mini-project.”

Experiencing Focus on Quality

One of the ways that “Focus on Quality” and pushing quality upstream showed up for me is in visualizing the end-point qualities from the beginning and coming up with an evolutionary development approach that I could envision constantly reinforcing quality in my particular project.  This has given me surprising adaptability, and I now have a safety net that permits me some aberrations and adjustments that I could not have imagined at the start. 

As I approach public beta and an opportunity to report more of the experiences when the open-source code comes out of embargo, I have found myself in an interesting situation.

Inside a Relentless Process, You Can Permit Shortcuts

There is a sponsoring customer that is putting my software to work inside of a specific product, on behalf of a specific customer of their own.  As I approached the end of alpha-level deliverables and moved into private beta deliverables, I modified my approach to releases in ways I did not expect. 

Having achieved the major design and implemented key functionality, I have now begun to short-circuit some of my testing and deployment investments in order to deliver the few remaining features that will provide the greatest first-customer utility.  This isn’t good enough for a public distribution of the software for reuse.  It is more than good enough for a specific integration inside of a specific release of application software.  So my attending to that at this time focuses on the least that could possibly work for the initial customer, accomplishing earlier availability and opportunity for further experience and correction.  (It is also remarkable to me how much “the least that could possibly work” arises in the selection of iterations.)

The point I want to make is that I have designed and I am evolving toward a public product with all of the stability and conceptual coherence such an effort requires.  However, for the first use, I can cover a point space that is good enough for the initial application and in which my later-hardened software can be slipped underneath without impact and with greater confidence in continuing stability in the face of changes in the application software. 

What’s clear to me in this experience is the deficiency of code-and-fix point-solution development, the kind that often happens inside of an application-software development setting and for which testing and hardening is usually just enough to get things working in the context in which the software has been conceived.  This variant of code-and-fix creates two well-known prospects for later failure: the cost of maintenance/re-engineering and the illusion of reusability (potentially for resale of what was originally an internal software development).  The second effort often dies a grizzly death in consequence of the unaffordable maintenance and support costs.

The Bet with Myself

I claim that I have avoided that limitation because the points I fix are inside of a coherent design.  That design dominates the development, as does the quality progression for which there is always a way to recover from (intentional) deviations and continue.

As I cross over to public beta, I know what cracks I must seal and I will do so.  What struck me on reading Meier’s post today was realizing that I have permitted myself some code-and-fix expedients simply to have my sponsor able to satisfy their immediate needs.   So, for a short time, I am actually doing one-feature-fix-at-a-time, clean-up mini-drops (0.56, 0.57, …, 0.59) before catching my breath and declaring the 0.60 public beta.

With the logistics arrangements between my working in Seattle and the sponsor in Europe, I do have an incentive to package the deliverables in a way that has them be usable without my presence.  This has been critically useful although I still probably over-do it.  I am trusting that to pay off big in the home stretch, though.

So now, back to work.  I have a roadmap to update and continue.

 
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 $