Categories
software development

The importance of open discussion in software development

I jsut finished reading an interview with Zed Shaw on O’Rielly called and I have to say it was very enlightening. It was interesting and encouraging to ‘hear’ him say: My motto here is “If I KMFU (Know My F*ing Users) they won’t have to RTFM.”

I think that this principle is so often overlooked in the programming world – and not just the Open Source world either. I can’t count the number of times that I’ve had a go at some program or other and just been lost without the docs. I do try to keep it simple for my stuff but sometimes you kinda get caught up in some idea (yours or someone else’s) and you end up implementing some crap that does the job, but that’s about it. It doesn’t ‘just work.’

This relates to something else I read today, called The Art of No. As professional coders on deadlines that usually ‘cannot move,’ there seems to be a strong inclination to say ‘no’ to any change request or feature enhancement. While this makes the deadline less distant, it makes the client/your superior/the user more distant and lowers your rapport with them all. After all, they’re paying you! So, the article above says “ask why,” so you open a dialogue into the problem and see the other side of the story.

I’ve found that telling them that “you’ll see what you can do” works wonders too. This has the following benefits:

  1. You can talk about why they want it done in a non-meeting format; the less structured the meeting the easier it is to get points across because you are less limited in time
  2. It gives you a chance to make sure that the feature they are asking for is not somehting that you were expected to build anyway
  3. You can discuss the impact on the timeline
  4. By not saying ‘no,’ you can get more work for yourself/company and thereby invoice more hours

This last point is important – none of us can work for free, but customers can sometimes forget that. Bring it back to the bottom line. Underlying this has to be a strong spec of some kind, or a time-and-materials (per hour) agreement though – otherwise there’s gonna be pain when you get to talking about what was supposed to be delivered at what tie for what cost. Get your ducks in a row at the start, and everything else is a lot simpler.