Month: April 2009

(I originally posted this on my MSDN blog.)

The Great Circle Of Life

I’m beginning a process of changing a whole lot of stuff in my project at work, so it’s probably a good idea to take a moment to ponder the hazards of that strategy.

I was with my previous group, Microsoft Game Studios, for nine years, and in that time we went through several reorgs that took us through an entire pendulum swing from many small, self-contained studios with lots of duplication and redundancies in resources, to a few large, consolidated studios where almost all resources were shared, and then back towards many self-contained studios.  Everything old is new again.

There was a thread on an internal alias recently where people were pondering Microsoft’s naming strategy for its OSes.  We’ve had numbers (3.0, 3.1, 3.11), mixed with letters (NT, ME, XP), mixed with years (95, 98, 2000, 2008), mixed with words (Vista), and now we’re going back to just plain old numbers again with Windows 7.  Around and around it goes.

There are many other examples from fashion, politics, you name it.  I think there are a couple of reasons for this phenomenon.

Greener Grass

The first reason is simple human nature.  It’s usually easier to see the flaws of whatever you’ve got at the moment and the strengths of whatever you haven’t got.  Mmmm, boy, the grass over there sure looks a lot greener, doesn’t it?  So we keep chasing “something better” and somehow we never quite catch it.

When there’s only a finite number of options to choose from, the chase inevitably leads you back around to where you started from.  Except that usually enough time has passed that the people doing the chasing don’t realize that they’ve just gone in circles.

Justifying My Existence

The second reason is perhaps more cynical; no one ever gets paid to leave things well enough alone.  If you’re a senior-level manager, or a marketing strategist, or a fashion designer, or any kind of professional evaluated on the strength of your ideas, then in order to perform well you have to generate and implement new ideas just to stay afloat.  Never mind how good the old ideas were.  They could have been darn near perfect, but it doesn’t matter.  What matters is that you change things around in order to demonstrate that you’re doing something.  You can’t march into your annual review meeting and tell your boss, “Well, things have been going great just the way they are, so I decided to leave everything alone and not muck around with it.  My major accomplishment this year is that I haven’t broken anything.  Can I have a raise?”

Of course, very few ideas are truly perfect just the way they are, and it’s always good to strive for improvement, but this need to justify our existence forces people to make changes whether they’re warranted or not.  The bigger the change, the better we look.  “Yesterday’s ideas are old and busted; my current plan is the new hotness!  And best of all, I won’t have to actually demonstrate the long-term value of my current plan, because next year it’ll be old and busted and we’ll be on to something else!”

Sanity Check

Software developers are just a susceptible to these tendencies as anyone else.  We just get away with it more often because rather than having a finite number of options that lead us around in circles (and thus expose our folly to those who have long memories), technological progress gives us an infinite supply of brand new ideas to jump on.  Though come to think of it, I’ve seen a few old Lisp and Smalltalk greybeards rolling their eyes at the newest whizz-bang features in modern languages, and muttering something that sounds suspiciously like, “Welcome to the 1970s!”

Obviously, there are plenty of times when the status quo really is miserable and change really is necessary.  Continuous improvement is a noble and worthwhile goal.  But it’s always useful to stop and ask ourselves, “Is this change I’m about to implement really an overall benefit, or am I just chasing myself in circles?”

 

(I originally posted this on my MSDN blog.)

I’ve had several discussions recently with coworkers about Agile project management processes, and one point I’ve found myself making repeatedly is that agility in your process tends to demand agility in your code base.  If you can’t rapidly evolve the design of your code base to respond to an ever-changing understanding of your goals, then you’re not going to be able to change your goals.  You just have to pick some and drive in that direction for better or worse.

Agile project management processes such as Scrum are careful to not require any particular software design methodology.  Scrum is supposed to be agnostic about your coding style.  That’s true to some extent, but if your project management style says you’re supposed to be able to take your code base in new directions at will, and you’re not able to do that effectively, then you’re just setting yourself up for a world of frustration.  It simply won’t work.  I suspect that a lot of the apparent failures of Scrum are actually due to an impedance mismatch between the project management methodology and the code base.

Practices such as continuous integration (CI), test driven development (TDD), pair programming, S.O.L.I.D. design principles, and other coding practices are probably not the only way to create an flexible code base, but they’re a well-known and proven way to do so.  If you’re an architect or manager thinking of adopting Scrum for the first time on your team, be sure to include your developers in that conversation, and make sure they understand that it will require changes not only in how they plan and track their work, but also in how they actually do their work.

 

(I originally posted this on my MSDN blog.)

The Elephant

My new project at work has had a relatively long and, um, colorful history, as I’ve alluded to in previous posts.  I think the code base is somewhere around eight to nine years old and has passed through the hands of a variety of internal and external developers, none of whom seem to have owned it for very long.  Most of the the engineering infrastructure was never updated to keep up with the times so I’m now the proud owner of an application with issues that include, but are not limited to, the following:

1. No automated build system
2. No continuous integration system
3. No branching strategy to separate ongoing dev work from hotfixes
4. No ability to run the application in isolation on my local dev machine
5. No proper test server environment (we have a non-production server environment but it’s locked down so only the Ops folks can access it, so it’s actually a staging environment)No automated checkin emails
6. No unit tests
7. No integration tests
8. No ORM

Oh, of course, there’s a long list of new feature work to deliver, too.  And naturally, it’s already well behind schedule.  I can’t just take the next three months off to build an ideal engineering environment in which to work.

It’s rather daunting.

I don’t know about anyone else, but in situations like this I feel a strong temptation to just throw up my hands and exclaim, “I don’t even know where to start!”.  It’s a classic catch-22; implementing new features is proceeding at a far slower pace than it ought to because of the poor engineering environment.  There’s all kinds of friction and pain.  However, the need to deliver new business value hamstrings my ability to clean up the engineering problems.

Chew, Chew, Chew

The answer, of course, lies in the old aphorism: “How do you eat an elephant?  One bite at a time.”  Trivially obvious, I suppose, but true nonetheless.  I don’t have to solve all my problems at once.  It’s ok to take small bites, as long as I keep making progress.  I don’t have to have a grand plan for solving everything.  I just have to have a plan for solving whatever’s causing me the worst pain right now.

My plan is to start interleaving engineering cleanup tasks with new feature work.  I’m going to order the list based on the perceived ROI of solving each problem then pick them off one by one as I have time.  I plan to blog about each of my engineering issues as I solve them.  For the most part it’s going to be a rehash of well-worn ideas, but it’s always good to revisit them for folks who might not be familiar with them yet.