 |
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. The Difference Between Resolution and Size: Or, My Abstraction Leaks More Than Yours, so there!Speaking of leaky abstractions, I just ran across this interesting problem in Doug Mahugh’s post, Doug’s World » What Resolution is best?.
I love (that is, hate with intense envy) the photographs that Doug posts on his site. If he doubled the pixel dimensions of his images, I’d still find some way to look at them. The problem with Doug’s analysis, of course, is that 1024 x 768 is not a resolution. Resolution has to do, roughly, with pixel coverage in a unit area. (In photography and imaging that’s not quite right, which shows that even straightening this out is an improvement but not the whole story.) There needs to be something about the quality of those pixels too (8 bit, 24 bit, 32 bit color for example) and the fidelity with which they are imaged on a display surface. A second problem is that any browser report on “resolution” is presumably about the pixel coverage of the entire display and we have no idea (1) what the physical dimensions of that display are nor (2) do we have any idea how much of it is being used by the browser and (3) how well the browser is rendering the image. This handling of abstractions is so leaky (and so commonplace) it is not clear there is any abstraction at all. It’s just noise about two numbers that are taken to be measures of something. Of course, I could simply be objecting because my 19–inch LCD monitor provides 1280 by 1024 pixels and, in my normal way of working, there are browser pages that don’t fit properly even when I go to maximum screen and I usually don’t want all of my screen consumed by a single application. When I am on Quadro, my tablet PC, 1024 by 768 is the best I get, making it even more difficult to browse some sites (and use some applications). If I change to a portrait view (that is, 768 by 1024), it may be even more difficult. So long as Doug puts up decent thumbnails and lets me choose which ones I want to see done large, I am very happy. As a regular visitor to his blog, I also know what to expect: Viewing his pictures is invariably worth the effort to bring them to my browser. I can also compensate for the browser changing the dimensions (resizing) and then resampling the image on me, especially now that Internet Explorer 7 makes it easy to detect and over-ride that behavior. It doesn’t hurt that I am getting 4 Mbps downloading on my Here’s the lesson I want to emphasize: What Doug is doing is like guessing the ideal bench seat setting for everyone’s car, based on some averaging of ergonomic statistics. This does not mean his choice is a bad one. It is just that his analysis doesn’t answer the real question, which is what really works for his readers. (My using two computers makes it more like bucket seats for very different people, so now what? When I’m on wireless on the Tablet changes everything, of course, as if I’ve got a Ferrari and a Vespa in the same garage.) This is a common pitfall in the design of software and computer-based systems generally. Useful examples are important to notice. And yes, the difference between coverage/density, size, and resolution will be on the quiz. The difference between those technical metrics (gotten right) and what works for the user will be on the final.
Specialization is for InsectsI’ve become a regular reader of Oren Eini’s blog, “Ayende @ Rahien.” Although I don’t toil in the same developer space as Oren, I find that his introspective illustrations of methodology and technique yield little diamonds every day. His attention to testing is heart-warming. Today, in a theme-titled post, there is this great observation:
I think it is more than that. We must stop Surprising the User (including the Developer special-case), for all of the same reasons. It seems to me that plugging-up the abstractions, and knowing how to have them fail appropriately when fail they must, is a perfect agenda for conquering the complexity that we have unleashed on the world in the name of mastering complexity. There’s a lot more in Oren’s post and I recommend that you digest all of it (and then subscribe to his RSS feed). |
||
|
You are navigating Orcmid's Lair. |
template
created 2004-06-17-20:01 -0700 (pdt)
by orcmid |