I’ve recently run into a common programming problem. While turning a development project over to another development agency, we heard that worst of comments:
Why did you build it that way?
It seems like a simple question. But it belies it’s true meaning. What they’re really saying is:
We wouldn’t have done that. This design is bad.
It’s a completely valid point. And you know what? I probably already thought that same thing.
I’ve been in the interactive marketing industry over 10 years. Over a decade. That’s a long time to see a huge spectrum of problems and their solutions. And in those 10 years, I’ve never seen the same solution come up twice.
Yes, I said “solution” and not “problem”. The same problem will rear it’s head many times over. But the solution will likely always change, for reasons of education (namely what you learned from the last time the problem came up), technology (newer and better ways to create the solution), and skill (your developers will change and their skills will improve). And frankly, you won’t always be the architect of the solution — some else might take that role.
When that solution comes to fruition, it’s a natural behaviour to look back on what was done, and rip it to shreds again. This is the act of any responsible developer — to analyse the work for what was done right, and what could have been done better. Learn from the work that you’ve done and ensure that the next project benefits from that education.
And yes, ladies and gentlemen, you’ve read into my next point: There is no such thing as a perfect solution.
I’ve heard this before, many times. The idea of a “perfect solution” is purely textbook. It doesn’t exist in the real world. There are defined approaches to problems, but the mere moment that a human brain is involved with the analysis of a problem, you’ll immediately enter into a world of subjective opinion. It’s unavoidable. And it should be encouraged whenever possible.
It’s simple: Ask 20 different developers how to solve a problem, and you’ll probably get 40 different answers. (A good developer will often give you multiple options.) Now take those same 20 developer and show them a completed project. Mayhem may result.
Hindsight is always 20/20.
– Billy Wilder
Anyone can look back on a completed project and poke holes in it. But being able to see the project in its complete detail belittles the difficulties that had to be surpassed, the learnings that were acquired, the barriers that got in the way, and the decisions that were made for reasons you’re not even aware of.
It’s not just cheating (not unlike getting the answer grid to that nasty math exam in high school), it’s unprofessional. Any development team who is picking up a completed project from another team should never expect it to be perfect, or even consider demanding such. The expectation isn’t just unrealistic — it’s bordering on impossible.
I’ve lost count of the number of projects I’ve helped deliver over the last decade. (It’s been a lot.) And at the end of each and every single one of those projects, I’ve looked back and said exactly the same thing: We could have done it better. Especially the ones I’m most proud of. It’s for the very same reasons I mentioned above: education, technology, and skill.
So if you’re going to come to me, and critique my solution, then you’ve just given me the right to do it to yours as well. Consider that for a moment — is your solution bullet-proof? (And I’m specifically targetting those in interactive marketing, here.) It’s a tired adage, but it fits:
Judge not lest ye be judged.