Fabulous IT

So, originally I had intended to blog about the whole process of refactoring the Twitter RDF feed tool. I also had intended to doing the whole project in a week, or even two at the most. This brings up two very important Agile concepts:

1. Documentation and other deliverables, while sometimes important, significantly drive up the cost of development. In this case, the documentation isn't directly related to the product, but the process of creating it. Real documentation would not have resulted in this much of a delay unless it was a severe case of design/analysis paralysis. While there is quite a bit more to document on the process, some outside pressure has necessitated a speedy release. In this case the value of documenting the process does not out weigh the "losses" incurred by the service being down in the meanwhile.

2. Continuous delivery is key. The process of "improving" a product should not result in a severe (or even significant) delay in being able to make the next release. That is to say, if I've been doing this right, I should be able to push out a working product very quickly even though I am no where near done making all the improvements I would like. The account that the software was originally developed to enable has been "noticed" by a large number of people on campus. If I don't get it working soon many of them will likely unsubscribe from the service and while they are not "paying customers" the point isn't to directly profit, it is strategic placement.

As such, I have decided to cut back on the refactoring blogging (because I've been too busy to do it lately in any case) and focus on getting a working, cronable, script in place ASAP. My new goal is to have a working version in place by Monday.

The product itself will be documented, in so far as it will have PHP Doc generated information. Once operational, I'll do one or two more blog posts, postmortem discussing the work that went into converting the use cases into reusable components.