Lessons from the Road

I have spent the past two weeks on-site with a client. This is a Greenfield project. Essentially it is making data accessible via the web. The iterations are one week long.

Although the assignment is not yet complete, there are some important lessons I want to share about my experience so far.

TDD Works
I am an avid “test first” developer, but it is often on an existing codebase. This project gave me the perfect opportunity to go TDD all the way. The number one rule was no domain or model code gets written without a corresponding unit test, and that test must be written first. Period, no exceptions.

Being disciplined and following this one simple rule allowed me to breeze through the code. It also allowed me to easily and constantly refactor the code without fear or hesitation. I let the design unfold organically and only implemented code that solved the problem at hand. I was unconcerned with what might be needed for a future iteration or feature. When the requirements changed or it was time to add a new feature, it was a painless process.

Access to the Client Works
I realize this one is not always practical. In this case, the office I was working in was two doors down from my main user. If there were any questions about how something should be implemented, feedback was immediate. Which leads me to…

“Specless”, Simple Design Works
There was no predefined technical specification, functional specification, or DSD (Design Specification Document), and no “big up front design” (BUFD). We simply had a set of user stories, written after two meetings with the client to discuss their needs. Our user stories formed the basis for all of the unit tests which guided the development of the code, architecture, and application design.

In fact, using this approach, along with the client’s accessibility, ensured the design was flexible enough to survive any of their changes.

We had a feature that was implemented incorrectly. At our next demo, the client noticed it right away. Two hours later, it was refactored to meet their needs precisely and in production. If we had been using a BUFD approach, we wouldn’t have known there was an issue until after the release date.

Conclusion
In a budget sensitive project (and they all are), there is never enough time to go back and fix those critical imperfections. The client is left wanting, the users are disappointed, the check-singers are angry, the developer looks like an amateur, and the company looks unreliable. It is a fail for everyone.

Following the techniques described above have kept the code lean and clean, kept the client happy, and kept the project on schedule and under budget, so far…