On the extremes of radical new management (part 1)

The early days of my career were spent with a small struggling software company competing in a challenging market mostly dominated by much larger players.  Our company had a different vision, some very talented people and culture of taking raw talent and honing it through collaboration and mentoring.

We had a development lead - let's call him Dave to protect his true identity as everyone knows 3 or 4 Daves.  Dave was an unassuming genius who loved what he did and always had time for others. Within a couple of years of professional development, I had seen Dave perform some extraordinary feats of technical mastery and I aspired to be just like him.  I thought I was getting pretty good at what I did, but Dave was the guy that all the devs looked up to and relied on when things broke in ways that no one else could fix.

Then a strange thing happened...

...and just enough refactoring to not screw it all up

From my previous post, you might have learned that I'm working with a small company that have yet to reach the level of maturity where a more rigorous development process would not be viewed as over-egging. Disturbingly, we already have a legacy codebase since the original concepts had been kicked around for a while in prototype form before morphing into the real application. Regardless of my personal opinions, anytime I want to embark on a radical phase of improvement, I find it useful to ask myself whether I would want that right now if I was paying the bill, or whether there are still bigger fish to fry.

On the art of gradual improvement...

Like most people, I've worked with some pretty ropey codebases over the years - in fact I'm big enough to admit that I've created or contributed to some too. However, I'm no longer phased by it in the way that I might have been 10 years ago. 'Legacy code' is merely a fact of life that as professionals, we have to accept - and dare I say it - embrace.  It's not that I enjoy working with legacy code any more than the next guy, it's just that I have a good appreciation of how 'less than perfect' code is generated and a trusted bag of techniques for making it better.