Perfection in Your Process

I have a serious character flaw. I’m a perfectionist. Nothing kills creativity like trying to get everything right the first time around. One of the most important skills I learned in professional writing: is create first, edit to perfection later. Give yourself leeway and freedom to make mistakes and to experiment.

There is a second part to the lesson though. You must treat and follow your process as closely one should practise religion. In writing, a process gives you the structure to write faster, better and with more freedom. In programming and developing applications, rigour in sticking with your process is essential for the project’s health and your sanity.

Processes like planning, documenting, testing, deploying and fixing bugs should be well worked out in the developer’s mind. Being drilled, the developer can control her environment better. In a controlled environment, there are no surprises or unexpected issues. Everything works with the precision, logic and accuracy of a Swiss watch. With a well documented and followed process, you can measure efficiency and progress.

In a controlled process, you can work out what you can expect to happen and how. Your developers can gauge how their work is progressing. Your designers can see how well the implementation follows the design. Your testers know where to spend time testing. And your business people, can figure out the cost in time, people and materials your project will take. Everyone know what is expected of them. Your team feels less stress, and works more effectively. That is why ideas like Sigma Six and best engineering practises exist. Japanese manufacturer stressed over their processes bring them to perfection. No wonder why Japanese manufacturers can corner the market.

Without a process, chaos ensues, stress builds and projects fail. So if you manage a team or a project, do your team a favour: figure out a process that works for everyone and stick to it. Your team will appreciate less stress and chaos. And your bosses will appreciate a project well done. Perfection belongs in your processes.

Harnessing Chaos: A Framework for Team Management

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:

  1. Quality Expectations
  2. Communication
  3. Scheduling
  4. Individual Talents
  5. Work Synchronization
  6. 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.