Don't Hide Your Designs!

I just got back from teaching a design patterns course at Microsoft in Mountain View. This was my first trip down there and I really enjoyed the class and the students.

This was a very serious group of students. I teach a lot at Microsoft and for the most part the students are serious about their jobs and learning, but this group of 19 developers, architects, testers and managers were very serious.

I'm trying to say that this is a good thing. They listened to me, followed along in their manuals and asked great questions.

We have a design exercise on the second day around lunch time. I got them started on the exercise well before noon and I would normally expect some of the designs to be started when I go to lunch and most, if not all, to be complete when I get back from lunch. After lunch, I could see the outline of a design that had been erased on the whiteboard area for one team and the other areas were clean.

I asked them if they were having a disagreement and they said, "No, we just don't want the other teams to copy our design!".

An attitude that protects a proposed design from others in a classroom setting is one thing, but I know that this kind of reluctance to show and discuss a propose design happens all too often on real projects.

There are several possible causes for the choice to not “go public” with our deigns. Sometimes designers and architects want to wait until the design is complete before opening it up for comment. Others are worried about the public criticism or even just the time it would take to respond to comments and questions. Worst of all are the cases where the delay in comment is a calculated effort to force a design for the project by not giving sufficient time for comment.

I believe that all of these scenarios have the same basic flaw. These are all based on the assumptions that we can figure it all out up front and that a small number of smart people can figure out even the most complex design problems. Apart from just being plain wrong, these assumptions break a fundamental rule for success in an agile project. In these cases it is the people that are leading. For our projects to be successful they must be agile. Being agile means that we embrace change because we know that most of the problems in a traditional software development project surround how we deal with change. If change is the enemy and resisted we will probably not be open to requirements changes that can be the difference between success and failure for our products.

We must let the product lead. What does it need? How well do we understand what the product needs? How can we provide those features? Letting the product lead means that the team is more concerned with the success of the product than their own individual agendas. When people lead the project, what they want is more important than the product needs.

Put the product in charge and let the entire team help move the product along. Scott Bain likes to tell the story of the MIT project to develop the software for the guidance computer on the first Apollo missions. I’ll let him tell you if you have not heard it, but the breakthrough came when a junior engineer thought outside the normal boundaries and proposed a solution that worked. Getting someone to listen to his solution was the bigger problem than the actual solution! If the product is leading we will be more open to input from all team members and to solutions from outside the box.

Let your product lead. Clear off the old stuff from you whiteboards, move them into a public space and get your designs out there for comment. Your team and your products will be better for it.

BTW, the team that hid their solution would have benefited from some input!