In Hiring and Interviewing Engineers, a recent Hanselminutes podcast, Scott ran through a sample interview process where he presented an obscure scenario to Carl Franklin. This was not as a test of whether Carl could get the answer (it was obscure and intended that he wouldn’t have previously seen such an issue before), but intended to observe how he went about trying to resolve the issue. This lead to Matt Davis suggesting what I can only assume to be (remember, obscure, I have never seen this type of scenario either) a viable solution in the comments on Scott’s blog. I thought this was great. No pretentious, "Your solution was crap" argument. No, "My solution is the penultimate solution to the problem" response. Pure, level-table, colaboration to improve a solution. There’s a lesson to be learned here I think.
First, from a "Microsoft versus the world" perspective:
There has been a LOT of bashing of Microsoft (read the Rory Blyth‘s two posts [one, and two] defending Microsoft and its developers from bashing by Robert Scoble or David Starr‘s Open Letter to Scott Guthrie). Instead of having open collaboration to improve, both sides (Microsoft and it’s detractors) distance themselves from one another and, often, the mudslinging begins. It has been rumored that Microsoft has a "EEE" pattern of integration ("Encourage", "Enhance", "Extinguish") that extends to open source and even to some of its partners. Open sourcers (okay, not a word, but you get my point) have fear because of this history and some resort to bashing Microsoft rather than working with them to improve the products. It looks like both sides need to re-examine how they collaborate. To improve, that cold war has to be ended through unilateral disarmament from one side or the other.
Second, from a "My code versus yours/legacy" perspective:
I don’t think that those who wrote the application before me intended to make code that was un-maintainable. I don’t think anyone goes to work thinking, "I want to make something worse than it was yesterday" now or in the past. One day I will no longer with the application I am working on now. I certainly had the best intentions in the code I wrote. I am certain that those before me had the same best intentions as well. To resolve this, a distinction between the solution (with the problem) versus the people implementing the solution needs to be made. With collective code ownership (an admittedly difficult concept to embody), both the solution and the people can improve as the system is improved.
Stated like this, it all just seems so easy…. heh.