 |
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.
Blog Feed Recent Items 
The nfoCentrale Blog Conclave nfoCentrale Associated Sites |
2007-03-11Recipe for Nano-ISV Success?J. D. Meier just posted a précis of agile-manager David Anderson’s recipe for success:
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 QualityOne 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 ShortcutsThere 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 MyselfI 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.
|
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |