.comment-link {margin-left:.6em;}

Tuesday, October 18, 2005

Dare to be Wrong

Some number of years ago, I had started a new software project and I was stuck. I didn't even know where to begin much less understand what design choices to make. I was talking to a former boss (and still good friend) of mine and he gave me some of the most important advice of my career: "dare to be wrong". It seems so obvious now. Start in a direction and see where it takes you. If you run into a roadblock, back up and start again. This one phrase also embodies some well-known concepts in software engineering: iterative design, refactoring, agility.

Unfortunately, this advice only works if the environment in which you work allows it. I found this out the hard way when I joined a very large project at a very large company. The bottom line was that there just wasn't the time to be wrong. Actually, there was lots of time to be wrong--just not enough time to make it right. Coming in one day to find out that 3 other teams you didn't even know existed have decided to call the initial version of the API you just checked in to source control doesn't allow you the time to be wrong. Refactoring in an extremely large, distributed environment is at best difficult and often impossible.

At one point in this project, even the lead architects had to admit that we had done a lot wrong. The entire architecture was a house of cards waiting to fall. So almost an entire release was devoted to "refactoring", a misuse of the term that would probably make Martin Fowler physically ill. What was even worse was that rather than present this to the team as a good and healthy thing, the leadership of this project reiterated (almost daily) that we had lost a lot of "points" with senior management and this would not be allowed to happen again. How misguided... This was a very young project and the fact that we hadn't gotten all of the design right should have been expected.

Software engineers and managers need to be honest with themselves and their management and embrace "dare to be wrong". It avoids "analysis paralysis" and is healthy for employees, the process, and the project/product itself.

Very well said, Brian - only with risk is there innovation!
If the project you worked on used a process such as RUP or IRUP, they are specifically geared toward not allowing individuals the freedom to explore ideas. The whole idea of them is to move the decision making away from the people doing the work and into a the hands of a select few. The funny thing is the forces in play in such a restricted environment bring about a whole set of unintended consequences like low morale, stagnent inovation and high cost
Post a Comment

Links to this post:

Create a Link

<< Home

This page is powered by Blogger. Isn't yours?