Geek Paperwork

May 9th, 2006
[ Software Development ]

When it comes to software development, I’m against documentation. At first read of that statement, most techies should assume me to be a caveman developer. It should outright scare most software management types as most processes are about providing management a means of controlling the development process. This relies on the development team documenting their work in a way management types can grasp. That’s obviously a real need but let’s put that aside and assume that your real goal isn’t to control the process from outside but instead from within.

PaperworkThe need for development documents is a symptom of communication issues within the dev team. They perform other tasks like force you to actually design what you’re going to build. If you had a team who did that without documenting it, would it matter that it wasn’t written down?

My ideal development team, a completely unattainable ideal, would have no need for documents and every character they type would be actual code. I’m not referring to requirements docs or functional specs from the business team. I’m referring to documentation within the dev team itself.

The ideal team would be a Stanley Cup winning hockey team. They wouldn’t have to talk, there’s no need for verbal communication, they just know what each other is thinking, what they’re about to do, where they’re going to skate next. When they started the season they made mistakes and passed to open ice where they thought their teammate would be. As a hack, they started yelling out “drop pass” or “go to the net”.

The point is that the documents should never be viewed as the end goal because they never were. The end goal is working software. Most teams will always need some overt communication, never able to completely abandon it but the best reach another level.

Instead of looking at a dev team’s documents as unavoidable paperwork, try looking at them as hacks. Think about what could be done, in terms of team structure and dynamics, to remove the need for them. It’s like the stop sign at the end of your street. Our goal should be to take that sign down as we all now have the common sense, compassion, etc to stop our cars at that point.

Ok, like I said, it’s an unrealistic ideal. Do I ever see myself being part of a development team with no dev docs? No, it’s not realistic nor is that my point. Can we learn how to improve our team and how we go about building software by analyzing these “signs”? I think so.