Programming is a misunderstood art. Unfortunately many commercial ventures treat programming like a science and managers treat programmers as engineers. Engineers build things based on repeatable technologies and designs. Programmers craft code, a process more akin to the unpredictable and unrepeatable production of art like writing. Companies get in trouble when they try to apply engineering best practises such as enforcing strict requirements, and tight predictable deadlines. A far better approach works by treating programming as an art, and applying artistic best practises.
The Problem of Creativity
One problem with creativity, is that is hard to predict and control. Creativity comes and goes, at a whim. Since artists work in a creative manner, they need a great degree of freedom in their work. Unfortunately the real world treats art in the same way as it does engineering. The real world expects predictable work schedules and techniques.
This becomes problematic when programmers work on a project as a team. The team needs to balance creativity with reliability. So artists and programmers need to build predictability into their projects. One way to create repeatable and scheduleable for creative work is to use a framework.
Team Frameworks
I am an extremely individualistic person. Yet, I will admit many projects simply take too long for a single person to do. Teams naturally alleviate this problem, by throwing more people at a task. But like Fred Brooks mentions in his The Mythical Man-Month, throwing more people at a team does not guarantee faster completion.
One of the reasons, I dislike teams is the problem of expectations. Before starting on a team project, I find it best to lay out “ground rules”. The rules include:
- Quality Expectations
- Communication
- Scheduling
- Individual Talents
- Work Synchronization
- Task and Job Division
It is important to work out these rules early on in a long term project. Without getting into specifics of each pint, I think everyone on the team needs to know what is expected of them. This saves the trouble of anguished team members when things go wrong, which in any project always does.
It is essential that these rules (not guidelines) be in place early on. Also every member of the team must follow these rules religiously. Sometimes the rules need changing, but if you did a good job on setting them up, the rules should not drastic changes.
Buffer Schedules
Programmers are notorious at underestimating the time required for work. The problem of “engineering” comes into play, and the result is delays in work. Instead when working on any creative project, you need to schedule in “thinking”, “wasted” and “oh crap, this is all going to heck” time.
The best of doing this is to schedule in a buffer. I usually work on a 1.5X buffer, (which probably is a very short buffer and 2X, even 3X are preferable). A 1.5X buffer basically adds an extra half “of time I think this will take me”. So if I think something takes 2 days to do, I try to schedule 3 days. This gives me room for error and I can finish ahead of time rather than “after-time”. Many successful programming groups also use buffers in scheduling.