Being a computer scientist by background, one of the things which I’ve always been keenly aware of is issues of scale, not only of computer systems but also of human systems. As organisations grow larger, layers of beaurocracy and organisation are needed just to keep things on track and get the job done. When done well, each of these things has a clear task and purpose but they also involve an inevitable tradeoff of time taken away from actual production.

One of the challenges I’ve been facing establishing policy at this early stage is what formal procedures and mechanisms should we put in place to safely navigate between the twin pillars of informal cowboy style development and rigid, stifling control freak management. At the moment, my inclination is to lean towards slightly too much procedure over slightly too little because I’m also treating this phase as a learning experience.Part of the reason to implement these systems is so that we can learn to use them and be familiar with them and understand the individual nuances (aka: frustrations) of each one.

But as I was entering items into the ticket tracking system for the first time today, I felt that same visceral sense of frustration that seems inevitable when you’re forced into an alien workflow. Why should I have to write down every thing I’m doing? Surely I can just keep this info in my head or in notepad. Why should I be keeping things in source control? I can remember all the source changes I’ve made.

Of course, intellectually, I know all the good reasons why such things should be in place, especially as we plan to scale such systems up in both time and resources. But one thing I haven’t heard many people talk about is the sheer emotional drama that comes along with implementing such systems. Without that awareness, I’ve seen far too many seemingly good systems fail simply because there wasn’t the appropriate buy-in from everyone in the team.

For the curious, here’s some of the systems that are currently in place or are planned to be in place:

  • Source control over all code and creative assets
  • Internal Wiki for documenting procedures and notes
  • Ticket tracking system to keep track of all development tasks and bugs
  • Test Driven Development policy for all code changes
  • Open development policy which requires significant amounts of documentation and reflection for the work that we’re doing
  • Social bookmarking system to allow us to share and record relevant links

We’ll so how this all goes as more and more of these systems start coming online…