...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.

On lessons in learning from a 6 year old...

I've been developing software for what sometimes feels like a lifetime. I mean, it's almost a quarter of a century, so for some, it is indeed a lifetime. To the hip youngsters who have only ever known the internet world, mobile devices and touch interfaces, I'm a dinosaur. However, as someone once said somewhere: "what other people think about you is none of your business". The thing that has been occupying my thoughts more recently, is what I think about myself.