There's a few predictable ways people deal with unhappiness in life. They can dwell on it and make everyone around them miserable. They can suck it up and say "that's life." Or they can actually do something about it.
Me? I tend to go through a cycle of all three. One thing I realised from going on a few job interviews and looking at my list of complaints about my current work environment was that the problems I had were a veritable checklist of every working environment out there. Legacy code? Which established software company doesn't have that? A standard set of tools and practices for common problems? I'd hope so! Changing something that isn't broke?
There's nothing worse than reinventing the wheel for no reason.
Except when you're being asked to make major changes to a bunch of spaghetti procedural code full of inconsistent architectural decisions and quick-fix hacks for the numerous bugs that appeared since launch. Oh and could you improve performance whilst you're at it? And by the way we're already behind schedule. No manager wants to hear "complete rewrite" when they're adding something that took the guy before you two or three weeks to hack in there.
So I hacked it in just that one time. And the next. And again. And in no time at all that horrible legacy code I used to blame on the other guy is now 50% mine. Oops! And those archaic practices and standards now dominate my CV .
Not my managers CV. Or their managers CV. My CV.
To top it all off, there has been a steady rise in web development jobs looking for expert OOP programmers and experience with MVC frameworks. It's all Zend Framework this, Rails that and Django another thing. In my office we use Perl. And not even cool Perl like Catalyst or Template::Toolkit. We're talking HTML::Template Perl here. I'm not even relevant in modern Perl jobs (all 2 openings per year).
Guerilla Refactoring is a phrase I thought I had coined but was in fact soundly beaten. Essentially it's the act of covertly fighting the good fight agains the almighty resistance of middle management, developing your own skills and getting better at your profession while you're at it.
See, the biggest problem I had six months ago was that even if I could start from scratch and do a total rewrite of the code I was having to maintain, I didn't have the real world experience to put all the theory into practice. Sure I knew what the acronyms MVC and DRY meant, but it's not until you start trying to write truly reusable code that YAGNI and KISS suddenly become the acronyms of choice. The code behind a good API and simple interface can often be extremely complex, and it takes a lot of experience to get it right.
Things changed for me during the last major project I worked on. The existing codebase was so huge that no business case in the world could justify a complete rewrite of the existing code to achieve the stated goals of the project, on that issue I had admitted defeat. So there I was, hacking away on a OOP/Procedural mash-up with some hundreds of thousands of lines of legacy code when I found myself about a week ahead of the schedule with some time to burn. What I did next was something I did for the first time in my professional career - rather than alert my manager to my heroic ability to beat the schedule, I went back and improved the design of a piece of fully functional and tested code I had written. I believe they call it refactoring?
It was hardly a pioneering moment, refactoring is a fundamental concept to agile methodologies and OOP programming books across the land. But I work in an Enterprise environment and when a manager asks me what I've done and I show them a fully-functional solution, unfortunately their first thought isn't "that's great but I wonder if david could improve the code and incorporate some advanced techniques so he can outgrow us and get a better job". In an enterprise environment, to improve the maintainability or scalability of a piece of working code you generally have a fight on your hands. If they know you're doing it, anyway.
The refactoring I did was extremely successful, I turned 300 lines of procedural code into a completely reusable class. When the same problem inevitably came up a few days later at another part of the application, I trimmed yet more time off the schedule by plugging my class in there. The actual process of reusing the code raised some flaws in the initial design as well as some areas that needed improvement, so I went ahead and used the time saved to make those to my class. Coding at work actually started getting interesting again.
Soon I had the Guerilla Refactoring process down to an artform. I would solve whatever problem I was facing as fast as possible, then I would spend the rest of the budgeted time refactoring the design of my code and any surrounding code. My refactorings were subtle and isolated and I burnt my fingers on some misapplication of a lot of theory without having to commit to any major architectural decisions. Once a lot of those rookie mistakes were out of my system, I was having to do less and less refactoring because I was getting it right sooner. I became so confident in the long-term benefits of Guerilla Refactoring that it became less "guerilla" and more "public displays of affection for".
If you're lucky enough to be working in some small, dynamic and modern web development team with great seed engineers and all the latest and greatest agile practices then you probably scoff at the idea of having to go behind your managers back to do things right. But it's the reality for most people working in the Enterprise environment.
Guerilla Refactoring works because you don't break budget or blow a deadline by trying to rewrite an entire application when you were asked to solve a simple problem. Nor do you become responsible for an overblown and complex mess of an OOP architecture when you're still wet behind the ears. You simply work within the time you're allowed and go dark for a period of that time.
If the situation I was in is anything like yours, give it a try. It might just save your sanity. And your career.
This was an interesting read, thanks! I use some of those tactics myself -- I always give time estimates for well-written pieces of code, and don't give in to manager pressure to just hack up something that _seems_ to work.
I've been burned by giving in before, when I've had to add layers and layers of "quick hacks" on top of already kludgy code, when time would've been saved by just doing things right in the first place.