Beginning Continuous Improvement, A Case Study
by: Glenn Goodrich
This post is the winner of The Great Devlicio.us Giveaway.The story you are about to read is true. The names and identities of the innocent have been changed to protect them and my job. No animals were harmed in the writing of this story.
Roughly three to five years ago I was an intermediate ASP.NET Webforms developer. I had produced several applications for various clients that were in different stages of test/production/maintenance /graveyard. Some of these applications were loved by my clients, others were tolerated, and still others were abhorred. The aspects all of these applications did have in common were a high level of difficulty to maintain and an almost violent resistance to change. Most of my clients tend to generate requirements in a management bubble so during the first round of testing, (if it existed) or the first weeks stumbling through production deployment, the user feedback was very large. Of course, the client always desired make changes accommodating this feedback, which is often where my real troubles began.
There had to be a better way. So, I started combing the web, hoping to find people that solved issues like mine. Googling phrases like “extensibility”, “webforms pain”, and “easy asp.net deployment”. If memory serves, the first fish on the line was Rails. I did the Rails “Hello World” and was amazed at how fast you could get going, how easy you could add views, and how much of my nerd life I had wasted. Realizing that my clients were not quite ready for Rails (“Ruby on what??? Where’s the msi?”) I started looking for MVC in .NET. This, as you’ve probably guessed, landed me at the Castle Project. Monorail was just what I needed. I could shoehorn it past my clients’ open source/never-heard-of-that worries, because it was .NET. But this was just the beginning.
The Castle Project also had the Windsor Inversion of Control (IoC) container, which led me to things like “separation of concerns”, “single responsibility”, and the “open-closed principle”. It really started me down the path of Test Driven Development (TDD) which was probably the single biggest positive change to my coding practices. It was a little bumpy at first, but once I saw that I could get all my code working before I even had a web site application AND I could really test it, I was hooked.
I started reading the Castle Forums as well as Hammet’s blog and Ayende’s blog. Figuring they weren’t the only really smart people out there, I started reading tons of blogs (CodeBetter, Martin Fowler’s Bliki, etc.) which showed me the endless world of better design practices. I started reading books that weren’t from Microsoft Press (nothing against them, but there are a lot of good books out there) including Head First Design Patterns, which was another huge A-HA! moment for my development career. I now read blogs everyday and have at least two books going at any moment in time. I read about Continuous Integration and CI Factory, as well as NHibernate and other OR/M frameworks. This was my first steps into Continuous Improvement.
So, where is this going? Is there a success story in our future? Before you object to the relevance of my opening statement, we have finally arrived at my success. We were handed a very large client from a business partner, partially because that partner could not satisfy the needs of the client. The client (who I will call BigCo) wanted a web-based application to put in front of their customer-facing employees to, basically, figure out if BigCo could provide any services to new clients. There were various factors that affected BigCo’s ability to provide services to a given customer, and the application would have to perform the logic that determined each of these factors. For this article, we will call the application ProviderApp. ProviderApp had to do the following:
Collect information about the customer. Find out where the customer lived. See if BigCo had the ability to provide services to that location. If the location was good, show the employee which of BigCo’s services were available. Persist the results of this interaction.
So, BigCo wanted a prototype. Tapping into my new approach and knowledge, I started writing tests for my (persistent ignorant!) domain model. Customer, Address, ProviderResult, and other classes were the result. All clean and responsible only for themselves and fully tested. I used separation of concerns to partition out the factors into services, being sure to use interfaces. These services were also open for extension, but closed for modification. In fact, for testing, I actually wrote test-only providers, removing the need to invoke some needed external services that would be used in production. I had all the logic for the factors written and tested, all the domain model designed and tested before I had even created a web application. Also, thanks to CI, I knew when the build was broken immediately, so bugs didn’t have a chance to get stale, causing me to have to hunt for hours or days because I didn’t know when the bug was introduced. By the time I got around to the user interface (the web application) it was simply a matter of writing my views and consuming my services. Oh, and the act of writing pure HTML views was a breath of fresh air.
I finished the prototype a couple of days early, so we had to time to actually perform real user tests, which I don’t think I had ever seen before. The bugs found here were relatively small but made a big difference in our demonstration of the prototype. On demo day, BigCo was very happy with the prototype. They were not wowed, they were not dazzled. Their reaction is not the success story. The success story comes from the fact that I was relaxed on demo day, confident the software was solid. I had no anxiety about getting off the beaten path, which was new for me. In fact, I let the BigCo folks drive the application at the end of the meeting and told them to show it to whomever they liked later. There is no way I would have been confident enough in my previous life to let a client demo my “prototype” code.
At the end of the meeting, the BigCo people asked me how long it would take to “make this real”, which is when my success story really sunk in. I realized, right there in front of them, that the application was done. My answer was a matter of days, as I did have to write new providers for a couple of the services, since they were using different back-ends then the prototype, but that was it. They also asked about some changes, a question that would have usually caused my ulcer to start. Each of their requests was a trivial change, taking me a few minutes to incorporate.
I remember walking out of that meeting realizing I had taken a huge step in my career. We are still doing a lot of work with BigCo, and they are a happy client. I no longer fear change, and am still continuously improving.
Well, I didn’t mention DDD, because I haven’t gotten to it yet (it’s on the list, which seems to get longer all the time) but I hope you’ll consider my contribution. Either way, I had a lot of fun writing this.
