As much as I enjoy creating and designing new things, there is something special about returning to existing code to improve and make it better. It’s a delicate process, much slower, and it also requires that you more-or-less like the product. If not, you’ll grow sick of looking at it all the time and yearn for something new. But if it is still interesting, there is something special about refining and seeing it evolve over time. What was once perhaps a rickety old house or simply a decent working-class Cold Era built house, has slowly grown into a mansion.
That’s looking on the bright side. As a builder, though, I have a tendency to walk into that house and see only the poorly designed plumbing, how the electrical outlets were not placed usefully, or that fixing the ducts would require extensive gutting of the existing ventilation.
After spending about eight months or so working on another project, I was to return to radio and logging to finish up the additional features we had originally planned on. In the time since, the users had had plenty of time to test and get used to the new system. I wasn’t really gone for eight entire months, as I had had to return for various minor-to-major patches along the way, but this would be the first time focusing on it full-time again.
Despite having performed various patches along the way many times, actually sitting down to add new features and expand current ones left me feeling especially disgusted with the wasteland before me. What was once plausible (if convoluted) now seemed just impossibly ignorant and embarrassing. Did I actually write all this? What was I thinking? Boy do I need to rewrite all of this.
Of course, I couldn’t rewrite it. That would take nearly as long as it did to write it the first time, and for what benefit? The satisfaction of a marginally better structured program? A bit easier on maintenance? Not feeling so embarrassed to have my name all over the credits? Mmhmm.
Ugly code or not, the damn thing works. It works really well. It’s slick, it’s feature-rich, it’s impressive, even three years later. It has been tested so much, patched so many times, and has been used so much (24/7 by 1-3 people all year round for the last three years), that it is rock-solid. There are so many little things added to keep it running smoothly, such as redirectors in case the users (not the most computer literate folk) mess up their bookmarks or type things in directly. Did I mention it works really well and they love it? </boast>
I cannot shake the need to rewrite the thing and make it better. Use newer technologies and techniques — since it was done, ASP.NET AJAX became official and we have things like LINQ and MVC. The desire burns within me anew each time I happen to see its code. And yet I also cannot deny that it serves its purpose fully, that it is appreciated and liked.
How can that be? How can something so ugly on the inside in the end be something really good anyway?
I credit the project (both iterations, really) for providing me some of the most intense learning in my career. It was such a rush of new things (that invariably I got/used horribly wrong), but perhaps the most important thing I learned beyond all of the practical knowledge about architecture, design, and .NET/C#, is that best practices, techniques, and patterns and all those things, well… they do not a good application make!
Good software isn’t good because it uses proper n-tier design or employs the latest version of Entity Framework. It’s good because it works and it serves its purpose. Because it is useful.
I may never stop recoiling in fright whenever I have to open one of its .aspx files, but at least I know not to stress out so much over choosing frameworks and patterns and best practices. I’m not saying they aren’t important, but that they will not themselves make or break the product. And that’s learnin’ you cannot truly gain from reading.
No comments:
Post a Comment