Programmer Tip: Get Rid Of Those Systems First.

As programmers we love the idea jumping up to build a new system at every given opportunity.

At Multiplitaxion Inc; I see a few young and budding managers attend a conference for a project management tool by a software development giant. They come back hugely serious; excited and amazed; much like babies who have found something new to explore and play with.

When I see them bubbling with excitement --- I cringe.

As programmers we have a tendency to get hugely excited about building something or putting a completely new system in place. Walk up to a programmer and tell him that you are having problems with people not applying for leaves in advance and chances are; he will tell you; you need a leave tracking system in place.

Tell a developer that you are trying to start a small library to encourage people to read books and chances are that he will tell you how badly you need a library tracking system.

To be honest; it is not just the excitement of building something new that gets the programmer within us excited. As geeks we love to also connect using familiar systems. The problem with having a whole lot of systems in your organization however; is that if you get make too many systems available to your builders and geeks; chances are that they will never connect and communicate at a human level.

Folks at 37Signals have interesting advice to give to people who are looking for a 'system' to track the feature requests. In their classic book; getting real; they explain why you should just forget your feature requests instead of trying to log them in a formal system:

Of course we don't fault people for making requests. We encourage it and we want to hear what they have to say. Most everything we add to our products starts out as a customer request. But, as we mentioned before, your first response should be a no. So what do you do with all these requests that pour in? Where do you store them? How do you manage them? You don't. Just read them and then throw them away.

Yup, read them, throw them away, and forget them. It sounds blasphemous but the ones that are important will keep bubbling up anyway. Those are the only ones you need to remember. Those are the truly essential ones.

Don't worry about tracking and saving each request that comes in. Let your customers be your memory. If it's really worth remembering, they'll remind you until you can't forget.

James Shore and Shane Warden come heavily on the simple idea of a bug tracking system in their book - the art of agile development. They explain:

Unless you're writing software by and for yourself, you will have to deal with at least one other person somewhere during the process. A grudging détente is not enough; you need to work together effectively. This means forming solid working relationships that are built on honesty, trust, cooperation, openness, and mutual respect.

You can’t force people to do this. The best your agile method can do is support these sorts of relationships. For example, one way to engender healthy interaction is to have people sit together and collaborate in pursuit of common goals.

It’s far easier, unfortunately, to craft your method in a way that discourages healthy relationships. An extreme example (sadly, one that actually happens) is forcing all developer communication with stakeholders to go through business analysts. As another example, a sure way to damage programmer / tester relationships is to require them to communicate solely through the bug-tracking system.

Ideally, your team will fix bugs as soon as they find them, before declaring a story "done done." Nobody’s perfect, though, and you will miss some bugs. Schedule these bugs with story cards, such as "Fix multiple-user editing bug." Schedule them as soon as possible to keep your code clean and reduce your need for bug-tracking software.

The point here; dear reader; is not to throw away all your systems of organization and turn into wild programmers who write random code. The point in fact; is all about is about letting go of access baggage and getting your basics facts right.

If you genuinely want your programmers to connect and communicate; first get rid of any excess 'systems' that you can possibly get rid of. Of course there will be some - like a version control system or the IDE in which you develop - that you cannot and should not get rid of; but reflect on and question the existence of every other system that you can see running in your organization.

Once you have done that; give your programmers opportunities to genuinely connected to each other verbally; their programming skills and their communication skills being the only two options left open to them and chances are; that they will use them both to the best of their abilities.

With no CYA systems in place and with free flow of information you will feel every ripple in your organizational pond and believe me dear reader; you will not need a fancy project management tool or an expensive bug tracker to find out what is going on. Honest.