Talking to programmers

Becky and Evan got together to figure out ways to improve the communication between project managers (producers) and programmers. People trying to manage projects often feel frustrated at programmers going off on tangents and taking longer than they said they would to complete a task. How can we make these processes work better? Here are some ideas...

Scaling features
A good way of assessing the importance of features is to map the following on a graph;

• For the producer a scale of features from valuable to not valuable,
• for the programmer a scale of features from easy to hard.

Features creep
Get your programmer to submit a daily change log - using versioning software such as Subversion (http://subversion.tigris.org/) - this will tell you when the project is going off track.

Ensure that the project has a backup schedule - you need to know that the latest version is on the server.

Install an app. which gives you a view of the code status online - a very cool one is Trac which also has wiki functionality and provides an interface to Subversion. (http://www.edgewall.com/trac/)

Time estimates
Always multiply your programmers time estimates by 2.5 - dealing with bugs will take most of their time.

'Smelly code' and good code
Programmers much prefer to write new code rather than clean up other peoples old 'smelly' code.
Good code should be readable with short functions, each method should only do one thing. Deep nested if elses are bad!

'One click deploy'
You should be able to update your site with 'one click' by automating the release process as much as possible with one script.

Talk to coders in a language they can understand
No, this isn't Klingon, just a recommendation to use the appropriate tools such as Wikis and IM.

Speccing and collaborative working
Figure out the best way to describe the features you want - use screenshots or a set of case studies describing a range of typical users. This process will help you arrive at a consensus with the programmer.

Cross continental programming works best when the programmers are in the same time zone and are able to meet up in person at the very start of the project; it doesn't work well for very time sensitive projects. It's vital that the programmers are connected by VOIP.

Pair programming (where two people sit down at one computer) is useful for adding features and bringing people up to speed.

Recommended reading
Refactoring by Martin Fowler (http://www.refactoring.com/)
Headfirst design patterns (http://www.oreilly.com/catalog/hfdesignpat/)
Agile techniques (http://www.agilemanifesto.org/)
Producing Open Source Software by Karl Fogel (read FREE online at http://producingoss.com/)