thoughts on software construction

I’m changing some untested code today and I want to make sure I’m not breaking things as I go, but I don’t want to slow down my development because timelines are tight.

I’m going to use Watir and WatirRecorder (was WatirMaker) to help speed up my manual testing through the user interface. If that goes well I might add some asserts where it makes sense. If I have time I’ll check out WatiN as well.

I’ll write another post to let you know how it went.

I just read a great post that describes and compares the often confusing and scary landscape of patterns for achieving separation of concerns in applications requiring user interaction.

http://ctrl-shift-b.blogspot.com/2007/08/interactive-application-architecture.html

On Friday I held a class on test driven development for the group of developers that will be expected to start developing using TDD soon. For many it will be their first experience with TDD.

I demonstrated how to do TDD in a live coding session where I rapidly added features to a web service application by cycling through the red-green-refactor process several times.

I think the concepts and practices were well understood by everyone and I’m hopeful that we’ll be successful in migrating from a non test-driven culture to a test-driven culture.

The questions after the coding session were mostly focused on how to test the existing code; the code that has low cohesion and high coupling; the stuff that’s hard to test.

How to start testing large, untested applications

I suggest the following approach:

1. rank application features by total cost of ownership by looking at how much time and money is spent fixing defects and handling customer support issues
2. look at upcoming feature requests and consider where the system needs to be changed

Start by testing the areas that cost the most to support and the areas that need to be changed significantly or frequently.

Choose black box tests that cover the visible features rather than the implementation details behind those features.

Use tools like WATIR or WATIN to assist with manual testing by using them to execute test setup while still using manual verification.

There is no silver bullet. Untested codebases are expensive to test. In general I think the best you can do is to control costs, focus on tests with the highest potential ROI, and ensure that new features are tested.

I just read a great post on Logic+Emotion called Waking Up Sleeping Giants. I think the younger entrepreneurs who are involved in creating new companies will get first-mover advantage in this changing environment and many established companies risk falling behind very quickly if they don’t embrace change.

I love the quote from Fuzzy Tail -

We can no longer afford to over-analyze our challenges. We must try to get things launched—learn from these experiences and refine. We must define ourselves and what we do more broadly while retaining the potency of our our crafts. It’s about going from left brain to right brain and ending up on “light brain”. We must become “fuzzy”.

JumpBox provides pre-packaged OS and software bundles that are ready to run inside a virtualization system. For example, one JumpBox is preconfigured to run WordPress on Linux.

I stumbled onto JumpBox this morning and was surprised when I read that there are currently no (affordable) hosting solutions for JumpBoxes.This leaves a huge opportunity for someone to create a hosting solution that would allow people to quickly and cost-effectively spin-up JumpBoxes. I can’t believe JumpBox missed this.