Something that’s been bugging me for a while now are developers who appear to be wearing blinders.
I don’t necessarily mean physically (although that is entirely possible), but mentally. They are confronted with a problem, and when a solution is suggested they are unable to see how to apply it, or come up with non-existent limitations on the solution, because they are unable to see how to apply it in a bigger view. Now, that doesn’t mean they are wearing blinders all the time, although I frequently find that they are, but it does suggest an endemic issue with developers being unable to focus on anything more than the problem at hand.
Architects have to be able to view the design from both a high vantage point and lower, more problem oriented vantage points. This duality is what makes architects so special. As such when they encounter a problem, the solution they will devise tends to fit both the problem at hand, and within the design as a whole. However, this ability should also be present within developers (who will hopefully become architects), as you should be able to look beyond your current problem and its limitations and see how a solution can fit as a whole.
A simple example, let’s take the instance of submitting high scores to a server for a single player game, assume the game is something like DDR. Submitting high scores then must be done in some manner,, such as a web-post to the server. So the question is, how can we deter cheating? Some ideas were thrown around, including storing the high score in multiple places in memory, using MD5 to ensure that it hadn’t changed, and a few other solutions. The problems with these various solutions should be fairly obvious, as an example the first one doesn’t stop me from using a packet analyzer to examine the sent data and determining a way of submitting my own scores, nor does the MD5 method, as I can just rehash my high score. A more complex method of submitting high scores was suggested; send the moves made to the server. Let the server run the moves through (it could do it quite fast for a DDR based game, since it would just need the exact key time indices, and then an error margin).
The solution was initially rejected because the author of said game couldn’t see how users might submit more than one high score. After it was pointed out that the same method that allows a person to submit multiple high scores would work anyways, he rejected it for other spurious reasons (such as “what happens if they quit the game part way through?”), all of which the entire solution would have suffered from. He was wearing blinders, and couldn’t see how the solution fit within the whole architecture.
Now, admittedly, the solution isn’t perfect, and it would take some work on the server side as well to properly recalculate the high score. It also doesn’t prevent cheating, just makes it quite a bit harder, since they would have to submit the key strokes with the proper timing, and assuming some sort of a random seed, that can be harder to automate.
So the next time you find yourself having issues with a solution, stop. Take a step back, and look at the solution from a few more angles. Perhaps it fits, just not how you expected it to.