Thursday, January 22, 2009

Communicate and Debate with Code

Frequently while building a software product the stakeholders will disagree on a proposed feature and a seemingly endless and tedious debate ensues. Occasionally some will use intellectual dishonesty to "win" the debate. I have seen for example dishonest programmers artificially inflate time estimates (to implement the code) in order to tip the scales of the argument against a feature they don't like.

This morning I read Paul Buchheit's great article called communicating with code. This passage stood out:

The point of this story, I think, is that you should consider spending less time talking, and more time prototyping, especially if you're not very good at talking or powerpoint. Your code can be a very persuasive argument.

The other point is that it's important to make prototyping new ideas, especially bad ideas, as fast and easy as possible.
If you are an honest programmer who really cares about your product you won't turn to intellectual dishonesty. Be open to ideas from all stakeholders. Make your software design flexible so that new features can be quickly prototyped and experimented with. The faster you can implement features (good and bad ones) the faster your software can evolve and improve. Working code has a way of clarifying arguments. I have certainly implemented stuff I thought was bad on paper but worked great in practice (and vice versa).


Citizen of the world said...

While implementing a feature required by Sales or other team, you might learn that there is a real value in their idea.

Anonymous said...

you might learn that there is a real value in their idea.

Not that an engineer should ever admit that. :-)