Doing a 180 in a matter of months

by: Darrell Mozingo

December 2006 was a low point. The company had lost some good developers, projects were stalling, morale was low, and the outlook simply wasn't good. It was the usual story, probably heard thousands of times before and still lived by thousands more: cowboy coding in continuous crunch mode. Page behind line counts were climbing into the mid four digits and the simplest changes had huge rippling effects across not only the current project, but other systems that were so tightly coupled together they were all fused at the hip. I was in the process of flirting with a few other companies at the time too, but after realizing I didn't want an almost hour drive each way every day, I decided to stay and try to help turn things around.

Coincidentally, something also changed in management around this time – perhaps they saw the sharp morale decline in recent months, or read an article that got them thinking, or who knows – and they too decided things had to change. So, the first step was talking them into getting us some quality training, and not just the ‘ol Advanced ASP.NET training, but some more basic and helpful training, like Object-Oriented Design & Analysis. They agreed, and everyone was thrilled afterwards. We saw all of our current pain points laid out with corresponding ways to counter them using solid OO designs and techniques over the week long course. Sure we all had our OO classes in college, but we'd never really seen how to properly apply them to business applications. First thing after the training, both management and all the developers sat down to lay some new ground work for our future course.

Books were ordered to rebuild our then defunct library, including plenty of juicy OOD books and some old McConnell classics. Online articles started getting sent around between developers for more reading. We started pushing back on clients (who were, in a way, internal clients) to give us time for development. Management loosened the budget for new hardware and software. Things started looking great, and it all happened in only a few months time. It was amazing. Sure, there were still things that needed to change, but we were definitely heading in the right direction.

Before "the transformation" had even began, several of our internal clients had been wanting complete new systems (some were still running classic ASP, some had completely changed their business model, etc), but they weren't quite ready yet. So we kept chewing on existing work that needed done. For almost a year afterwards we tried the various techniques we learned, along with some new ones, on existing projects and several smaller new ones. OR/M's, small scale unit testing, decoupling, CI, and more were all being tried and accepted within the teams. With these large, green field, development projects looming ever closer, though, we were still hitting pain points using these new techniques. Clients weren't completely happy, and there was still something just not sitting right with us developers.

One of the newer developers – not junior, just new- had been looking into adopting RUP at his old company. IBM agreed to come in for a quick one day assessment of our current lifecycle process, where they'd sit down and talk with our clients too, and give us suggestions for improvement (sales pitch, anyone?). When they gave their review, though, it hit me like a ton of bricks. We were using good development techniques, sure, but inside an almost pure waterfall structure. We all knew waterfall wasn't the way to go, but we were totally wearing blinders to the fact that we were even doing it. Whoops! Oddly enough, IBM pushed a very agile form of RUP on us afterwards, so we took a look.

Since then, some teams have adopted a more formal RUP framework, while others, like mine, have gone with styles leaning heavily towards agile. I'd done tons of reading for quite awhile, and a bit of playing in my off time, with test driven development, so I pitched it along with the new ASP.NET MVC framework, and they took it. The team I'm on is small, with only two other developers working on a large, green field payroll application, so acceptance is usually easier to get.

We're now on iteration 3, developing in a completely test-driven way (though we still catch ourselves doing some test-after-development, but we're working on it!), delivering functioning software to the users a little bit at a time using as "many practices" from the ALT.NET community as we can. We're not completely agile – we're not really doing user stories and planning as, say, an XP team would, but I'm sure we'll fall into that eventually. One piece at a time we're converting over. We're also very interested in BDD and DDD, too, and are looking into it while adopting some of those practice's lower hanging fruit.

So far our users are thrilled with the software, we're very happy with the design and testing being built around it, and I'm absolutely loving my job again. We've come a long way in a relatively short amount of time, and things continue to get better every day. To think, I almost quit.