What were they thinking
As of late I have been spending a lot of time working on a “legacy” system. The term legacy means different things for different groups, in the circle I’m working with these days it means a system that is no longer being actively developed. As has been stated by mean, software isn’t “dead” it’s “done”.
The catalyst for the work I’m doing is security requirements that need to be applied. While applying the updated security polices I’ve also been tasked with migrating the system from our data center to our cloud data center. As I move through the system I’m confronted with implementations that looking at now seem crazy; however, it’s these situations where it is important to apply two mindsets. One is giving others the benefit of the doubt. In a case like this, those that were working on this system used, for the time, the best options the technology stack could offer. For example, the extensive use of WCF seems silly now; however, at the time it was a recommended approach to hooking up independent systems. When reviewing the code in light of this you can really see how those that worked on it were making thoughtful and considerate choices.
The second mindset that is important to apply, and in my mind is more important to adhere to, is to assume good intent. This is important because even if someone did NOT follow the prevailing approach for the time, or use the best in class technology they had a good reason, or good intent for doing what they did. Consider those that came before as doing the best work they could. Perhaps they had constraints that prevented them from making, what would seem like, a better choice. Perhaps their was a time constraint as is so often the case. Perhaps, as we so often assume, they didn’t know any better, but even then, they were trying their best, which is worthy of acknowledgement.
Now how does this help, well often it allows you to see the system in the light of what it does well. It will provide a perspective that can outline what the system can offer and, as I’m finding, it will allow you to find an approach to extend/adjust the system to comply with the new constraints you are tackling.
So the next time you work on a legacy system and you are cursing the fool that came before, stop and think... give them the benefit of the doubt and assume they had good intentions. You will land in a better spot.
The catalyst for the work I’m doing is security requirements that need to be applied. While applying the updated security polices I’ve also been tasked with migrating the system from our data center to our cloud data center. As I move through the system I’m confronted with implementations that looking at now seem crazy; however, it’s these situations where it is important to apply two mindsets. One is giving others the benefit of the doubt. In a case like this, those that were working on this system used, for the time, the best options the technology stack could offer. For example, the extensive use of WCF seems silly now; however, at the time it was a recommended approach to hooking up independent systems. When reviewing the code in light of this you can really see how those that worked on it were making thoughtful and considerate choices.
The second mindset that is important to apply, and in my mind is more important to adhere to, is to assume good intent. This is important because even if someone did NOT follow the prevailing approach for the time, or use the best in class technology they had a good reason, or good intent for doing what they did. Consider those that came before as doing the best work they could. Perhaps they had constraints that prevented them from making, what would seem like, a better choice. Perhaps their was a time constraint as is so often the case. Perhaps, as we so often assume, they didn’t know any better, but even then, they were trying their best, which is worthy of acknowledgement.
Now how does this help, well often it allows you to see the system in the light of what it does well. It will provide a perspective that can outline what the system can offer and, as I’m finding, it will allow you to find an approach to extend/adjust the system to comply with the new constraints you are tackling.
So the next time you work on a legacy system and you are cursing the fool that came before, stop and think... give them the benefit of the doubt and assume they had good intentions. You will land in a better spot.