Recently we designed a change to a message queueing system. Our discussion surfaced several problems to overcome while modifying the existing system. At the time I felt somewhat disappointed. "Why was the system designed so seemingly poorly?" I asked myself.
Then I stopped pitying myself and started doing my job: figuring out how to make it work.
When the system was first built I had the opportunity to raise issues with potential problems. But I didn't because, given what we knew then, the system was designed properly. In fact, this particular system had performed adequately for several years. I was being ridiculous for doubting the system's design.
Our design discussion continued. Yes, there were problems to resolve including a tricky server migration. However, we discovered the problems weren't so big after all. We figured out a reasonable transition from the old system to the new system.
Like many people, I easily forget that systems are built with limited resources: time, people, information. We do what we can with our available resources. When requirements change, this means we have more information now than we had before. We shouldn't fault our former selves too harshly for failing to predict the future. We should acknowledge that we made design decisions with a given set of information and are redesigning the system with a new set of information.
Image © iStockphoto.com / Stéphane Bidouze
Great perspective, especially since you were a part of the process from the beginning. Often those that come after don't understand what the builders were thinking, and get frustrated over the original decisions made. I guess it's easy to fault the builders without appreciating the circumstances they were under. I'll definitely pass this along to Matt. :)
ReplyDeleteThat picture looks like me! I'm saying, "why on earth did I agree to make the drag-n-drop from photo album to email template IE6 compatible...?"
ReplyDeletehaha, is this the SQS stuff I did for the tracker?
ReplyDelete