Geeks With Blogs
A Technical Debtor Toward continuous improvement

I’m in a bit of an odd position, in some ways. CCI brought me on as a “software architect” a little over two years ago. That role wasn’t really defined – in fact, I got to spend several months doing what I felt would be a good use of my time, and then I wrote my own job description. (Perhaps that’s not exactly what other people remember, but it’s sure how things felt to me.)

Like anything, this approach has benefits and drawbacks. On the plus side, I was empowered to go where the smoke was – to find the areas where I could have a great deal of impact, quickly. (One of my favorite comments of this time comes from Kathleen Dollard, who recommended I apply at CCI. She told me once that “you’ve had more impact at CCI in the last three months than I thought anyone could in three years – and they haven’t fired you yet!”)

This was the time-frame in which I was modifying XSLT code generation templates to put repetitious code into a base class, rather than repeating it over and over and over and over and… well, you get the point. They were the days where “minor” changes like this resulted in dropping nearly a million lines of compiled code through the use of inheritance rather than code generation. (I tease one of our team leads that my job is to remove code faster than his team can write it… and I’m winning.) While this seems like a cool number to quote, the real business value actually didn’t have all that much to do with our code. True, there was a lot less code generated on a nearly-daily frequency. However, what was really valuable to CCI was the fact that the background compiler stopped crashing!

It turned out that our application was big enough that it taxed the background compiler in the VB IDE just a little bit. Just enough to find a pesky memory fragmentation issue in the background compiler. Just enough to ensure that Visual Studio would die around once per hour for every developer in the company. (For those of you that noticed this problem went away in VS2008 SP1…. you’re welcome! The leadership team at CCI was kind enough to let me ship our code base to Microsoft, where they easily reproduced the problem, and fixed it.)

These were the good parts of the early days. There were also some pretty rough parts. I mentioned earlier that I’m in an odd position. There are several different roles a software architect can play. One of them is the “gunslinger” or “hit man.” This is the outside consultant who comes in, declares that the architecture is a massive failure, and that everything has to be started anew. Often, this means firing the person that created the old architecture, having the consultant lay out a new one, and then walking away. A bad day for everyone. Lots of resentment, and lots of work scrapped.

So, what does CCI do? I mean, this is a company that has a 95%+ retention rate, and whose more senior developers have been there a decade or more.

They hired me. Not as a consultant, but on salary. They kept their corporate knowledge intact, added an opinionated young upstart to the mix, and put me at the desk beside the most senior developer in the company. Then, to heap craziness upon craziness, they invested heavily in “refactoring” the architecture. By heavily, I mean dedicating the development teams to making deep architectural changes for a few weeks.

And, you know, what? It’s been a great learning experience for everyone… and it’s working. More about that later.

Posted on Monday, July 12, 2010 8:13 PM Software Development , Software Architects Group | Back to top

Comments on this post: Architectural “Refactoring” – Part 1 of N

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Jeff Certain | Powered by: