Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at
Beginning Continuous Improvement, A Case Study

by: Glenn Goodrich

This post is the winner of The Great 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 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.

Posted 06-27-2008 12:11 AM by sergiopereira



Jak Charlton wrote re: Beginning Continuous Improvement, A Case Study
on 06-27-2008 3:41 AM

Big congratulations to Glenn for winning, to the runners up who get prizes too, and to all those who sent in stories!

Beginning Continuous Improvement, A Case Study « Noocyte’s Weblog wrote Beginning Continuous Improvement, A Case Study « Noocyte’s Weblog
on 06-27-2008 4:54 AM

Pingback from  Beginning Continuous Improvement, A Case Study  « Noocyte’s Weblog

Glenn Goodrich wrote re: Beginning Continuous Improvement, A Case Study
on 06-27-2008 8:21 AM

Again, thanks to all the folks.  I truly am flattered!

Jonathan Hartley wrote re: Beginning Continuous Improvement, A Case Study
on 06-27-2008 10:44 AM

Awesome article Glenn. You remind me of Jeff 'Coding Horror' Atwood, who has transformed himself from some mediocre developer into a force for change in his industry, all through the diligent application of the underlying principles you talk about above.

Notably, the one thing you don't mention in the article above, is that you've also been writing your own blog, with some in-depth explorations of the issues you're excited about. I think this is huge, spending enough time to organise your thoughts enough to write a short essay about them - I think it makes all the difference in the world to anyone's personal development. I should do it more myself.

Way to go. Much kudos.

Big Ed wrote re: Beginning Continuous Improvement, A Case Study
on 06-30-2008 6:15 PM

Head First Design Patterns is O'Reilly, not Microsoft Press???

sergiopereira wrote re: Beginning Continuous Improvement, A Case Study
on 06-30-2008 6:24 PM

@Big Ed. O'Reilly, yes.

Beginning Continuous Improvement, A Case Study at A Ha wrote Beginning Continuous Improvement, A Case Study at A Ha
on 07-12-2008 7:41 AM

Pingback from  Beginning Continuous Improvement, A Case Study at  A Ha

About The CodeBetter.Com Blog Network
CodeBetter.Com FAQ

Our Mission

Advertisers should contact Brendan

Google Reader or Homepage Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl Latest Items
Subscribe in Rojo

Member Projects
DimeCasts.Net - Derik Whittaker

Friends of
Red-Gate Tools For SQL and .NET


SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
NHibernate Profiler
Balsamiq Mockups
JetBrains - ReSharper
Web Sequence Diagrams
Ducksboard<-- NEW Friend!


Site Copyright © 2007 CodeBetter.Com
Content Copyright Individual Bloggers


Community Server (Commercial Edition)