Getting into someone else’s code ain’t easy. For some reason, the aesthetics of the code never quite feels like our preferences. The code seems dirty, naive, unstructured or plain ugly. One thing I have found over time is that, with enough exposure to it, it always ends up not being so bad. Even when you make the mistakes of rewriting it altogether, some details of your own implementation remind you how elegant minor pieces of the previous ones were.
It may be in the way an application was translated in multiple languages even if it was only ever to be used by half a dozen local users, or in the way the complete apparent lack of structure in a CMS allows different components to be really well integrated and provide a great experience to users. I find that beauty in the story of the code and its authors. In fact, I think that learning about the evolution of the piece of software, the experiences of the past authors and the overall context in which the development took place to be the only true way to appreciate working in code written by someone else.
No matter what, what we produce is only ever a reflection of what we are at that point in time. Our personal or collective stories brought us to that point. Unless you understand the motivations that drove the development, there is no way you can understand the basic qualities that were built into the system, there is just no way you can observe those qualities and esteem the code that lies before your eyes.
I tend to become really attached to the code I wrote. Seeing someone destroy my brain dumps without trying to understand them is simply irritating. As we evolve as programmers, we learn new tricks and tend to ditch our past accomplishments, but looking back, I can still respect qualities in my past work. During my first few months in the industry, my code was characterized by my own greenness. I had seen nothing of scale before, and therefore, my code was mostly original. It did not follow any common conventions, but would still bring ingenious solutions.
Later on, it moved to extremely object oriented to avoid the mess, then to astonishingly rigorous, procedural and simplistic for the extact same reasons. Data models went from simplistic and easy to understand, to extremely pure and normalized, and then back to some sort of elegant middleground. At any point in time, I could have justified my design decisions and defend them with pride, but only the story that led you there can explain those decisions. It may have been that the development project was completely exploratory and building new tools not knowing exactly where the road will end, or because we were trying to generalize the company’s processes after spending too much time maintaining code that did nearly the same thing. Each decision makes sense at the time.
These days, my priorities are focused around long term maintainability. They might be different in a few months. My current goals are driven by my current situation. In the past, my goals may have been to learn and experiment rather than serve clients not have to answer their calls forever. One thing for sure, if you try to maintain code that was built to be experimental, you will have a hard time, but you can still enjoy watching it’s evolution through revision control.
One thing for sure, all creations are only a reflection of their authors.
The same thing applies to organizations. Company cultures represent their founders and those who built it. Focus on quality and project control does not get created by itself. If a company is built by someone from the aerospace industry for whom failure is not an option, it will definitely be very rigorous. The company culture will then affect its residents until they will be ready to convince you it is the best thing to do. No one decides one morning to pick up a software estimation book and read it for fun. You get influenced to do so. Culture spreads and evolves. Creations are left all over as artifacts of time.
Books are such a great example. The software industry has so many trends. Some books are known as seminal, but if you read them today, they wouldn’t be so interesting. They would seem outdated, naive or plain bad. If you get back in the context of 1970 with information exchange technologies available, understanding of the computer science and just enough self-trained professionals, formal requirement and design processes make more sense than they do in today’s context. I never skip the preface and always take a quick look at the biography before reading a book. Otherwise, there is no way to understand the context in which it was written.
Time shows significant culture shifts, but market segments are almost more drastic. Agile methods are almost the norm today, yet some industries look at them and don’t quite understand how they fit in. Extreme Programming started on a payroll program as an internal development. No wonder customer relationship worked so great and just in time requirement elaboration worked so great: the client was next door and, seriously, can you think of a more understood program than a payroll? Would a software to control a multi-billion robotic arm controlled in free space around a hundred-billion space station make the same decisions?
When looking at traces left from the past, context is everything.
Even simple events like conferences are strongly influenced by their organizers. Between 2003 and 2005, PHP Quebec had a professional track with use cases from a business perspective. Later on, those were replaced with more process-centric sessions. These days, most of it is about security, scalability and performance. The changes are certainly not only due to market changes. If you look at CUSEC’s speaker line-ups over time, you will notice different trends.
Spend some time to look around and figure our the history of what you encounter, and think about it twice before destroying things. Find the value, then you will be able to judge if it’s worth keeping.