The oak sprint
Starting Monday, August 8, I have four weeks to work on Mindwrapper, not all day every day, of course, but probably around 200 hours total. For reasons to be elucidated below, I am calling these 28 days the oak sprint, and here are my goals.
My highest priority is to develop a useful working application in Mindwrapper, something I've not done before. I have tested most, if not all, of the various components of Mindwrapper, but I have never put them all together in a completed application. Nothing would boost my confidence more than being able to do this. Of course I will have to be careful about the requirements. It wouldn't be enough just to make a trivial toy application, for example, but by the same token I surely don't want to set goals that are unreachable.
In the time available, it would seem feasible to wind up with a program that calculates, stores, and retrieves basic hyperalimentation fluid (HAF) orders. No bells and whistles, and perhaps not even the capability to print the orders at first, but even if the program will need to be extended and enhanced afterward, as long as it can at least store and retrieve the essential data and compute the necessary dependent values, then the sprint will have been a success.
To accomplish this goal in the time allotted, an agile approach will be essential. In particular, I will follow lean thinking principles, unit testing, and iterative development. The iterative development process is more like growing an oak tree from an acorn than building a house. Hence, the code name oak for this sprint.
One benefit of the iterative process is that we can save a snapshot of each iteration and later use them to write a Mindwrapper tutorial. Likewise, these snapshots could become part of the documentation for the resulting Oak application. I say "later" because agile methods value working software over comprehensive documentation. During the sprint, then, the only formal documentation written will be in the source code and unit tests.
A significant hurdle is the fact that at the present time Mindwrapper is neither stable nor complete. Thus, another goal for this sprint is to come up with a stable Mindwrapper API (and an effective implementation). Since it is easier to establish a useful syntax when it is actually being used, the oak sprint would seem to be an ideal occasion for completing this task as well.
Now, let me confess that even now I am thinking about writing a whole new implementation of Mindwrapper someday. I can see ways to implement the emerging Mindwrapper API without resorting to many of the "magic" techniques that I currently use (such as metaclasses and the "universal method" decorator). It would clearly be a mistake, however, to embark upon a rewrite now or anytime soon. First, I need to get some experience using Mindwrapper before refactoring it to any extent, and second, I need to get some practical use out of Mindwrapper as soon as possible.
But wait. Wouldn't it also be a mistake to write a lot of applications in Mindwrapper knowing that it is going to be changed? The response to this challenge is that only the implementation details will change. I am basically happy with the Mindwrapper framework as is. (1) The single-tier, two-layer abstraction-presentation architecture is fine the way it is. (2) The directed, acyclic, labeled graph information model is just what I want as well. Moreover, I am getting closer and closer to having an API that I am happy with. What I realize then, is that the Oak application (and its unit tests) will be a set of "black-box tests" of the essential framework with no dependency on the specific implementation. If and when I get ready to re-implement Mindwrapper, then, the new version can use Oak as its test suite.
So, here are the "deliverables" of the oak sprint.
1. a working application, Oak (HAF order calculator)
2. the basis for a Mindwrapper tutorial
3. early documentation for the Oak application
4. stable API for Mindwrapper
5. black box tests for Mindwrapper
Finally, I am not planning to blog regularly about the sprint, but I may post occasional reports to the Mindwrapper-users mailing list.
My highest priority is to develop a useful working application in Mindwrapper, something I've not done before. I have tested most, if not all, of the various components of Mindwrapper, but I have never put them all together in a completed application. Nothing would boost my confidence more than being able to do this. Of course I will have to be careful about the requirements. It wouldn't be enough just to make a trivial toy application, for example, but by the same token I surely don't want to set goals that are unreachable.
In the time available, it would seem feasible to wind up with a program that calculates, stores, and retrieves basic hyperalimentation fluid (HAF) orders. No bells and whistles, and perhaps not even the capability to print the orders at first, but even if the program will need to be extended and enhanced afterward, as long as it can at least store and retrieve the essential data and compute the necessary dependent values, then the sprint will have been a success.
To accomplish this goal in the time allotted, an agile approach will be essential. In particular, I will follow lean thinking principles, unit testing, and iterative development. The iterative development process is more like growing an oak tree from an acorn than building a house. Hence, the code name oak for this sprint.
One benefit of the iterative process is that we can save a snapshot of each iteration and later use them to write a Mindwrapper tutorial. Likewise, these snapshots could become part of the documentation for the resulting Oak application. I say "later" because agile methods value working software over comprehensive documentation. During the sprint, then, the only formal documentation written will be in the source code and unit tests.
A significant hurdle is the fact that at the present time Mindwrapper is neither stable nor complete. Thus, another goal for this sprint is to come up with a stable Mindwrapper API (and an effective implementation). Since it is easier to establish a useful syntax when it is actually being used, the oak sprint would seem to be an ideal occasion for completing this task as well.
Now, let me confess that even now I am thinking about writing a whole new implementation of Mindwrapper someday. I can see ways to implement the emerging Mindwrapper API without resorting to many of the "magic" techniques that I currently use (such as metaclasses and the "universal method" decorator). It would clearly be a mistake, however, to embark upon a rewrite now or anytime soon. First, I need to get some experience using Mindwrapper before refactoring it to any extent, and second, I need to get some practical use out of Mindwrapper as soon as possible.
But wait. Wouldn't it also be a mistake to write a lot of applications in Mindwrapper knowing that it is going to be changed? The response to this challenge is that only the implementation details will change. I am basically happy with the Mindwrapper framework as is. (1) The single-tier, two-layer abstraction-presentation architecture is fine the way it is. (2) The directed, acyclic, labeled graph information model is just what I want as well. Moreover, I am getting closer and closer to having an API that I am happy with. What I realize then, is that the Oak application (and its unit tests) will be a set of "black-box tests" of the essential framework with no dependency on the specific implementation. If and when I get ready to re-implement Mindwrapper, then, the new version can use Oak as its test suite.
So, here are the "deliverables" of the oak sprint.
1. a working application, Oak (HAF order calculator)
2. the basis for a Mindwrapper tutorial
3. early documentation for the Oak application
4. stable API for Mindwrapper
5. black box tests for Mindwrapper
Finally, I am not planning to blog regularly about the sprint, but I may post occasional reports to the Mindwrapper-users mailing list.
0 Comments:
Post a Comment
<< Home