Eyes up and to the front

In a post yesterday I used the term "eyes-down approach" in the context of developer behaviour, and today I thought that I might expand upon that a little. This is term that I use for times when there is so much activity and energy being used "implementing" that there is precious little focus given to planning and observing/testing the implementation. I'll demonstrate using an allegory... Imagine that you are given the task of sailing away to a Pacific Island in a sturdy boat. Once you set sail it might be easy to get highly motivated by the task of cleaning ropes, rigging up sails, preparing meals, etc that you forget to check some important things such as: what direction your compass indicates that you are travelling in, what direction your map tells you that you should be heading in, what the weather around you is doing, and the relative skillsets/strengths of your crew - you wouldn't want to entrust the meal preparation to the guy who is renowned for bringing upon bouts of food poisoning! Yet, armed with a good plan, the right tools and an understanding of the tasks which need to be done to get the job done safely, you might find yourself in for a pleasant time of viewing sunsets and quiet introspection.

Of the many courses and books that I've read which relate to producing "Quality" outputs a common theme seems that it is wise to adopt a "Plan-Do-Act" approach to developing the constituent parts of a solution. This approach acknowledges that "Quality" doesn't tend to happen by accident and that prudent planning, attentive implementation and dilligent appraisal of what the outcome is at the end of the first two activities can greatly assist in the pursuit of producing higher quality outputs.

One of the ways in which the "planning" part of the activity can be spent is by having open discussion with peers discussing the proposed solution - and not only from the positive side of the argument! Choose peers based upon the following attributes:

• Knowledge of the problem domain
• Liklehood of receiving an honest appraisal
• Team members who are likely to have a hand in building or maintaining the part

As an example, if I were to create a database schema for a new module in an existing application I would probably want to discuss my implementation plan - either jointly or severally - with:

• DBA : to discuss likely query paths, indexes, naming conventions, target environments, possible code-reuse opportunities, etc.
• System Architect : to discuss interoperability with other areas within the application, possible code-reuse opportunities, etc.
• Proposed Developer : run through the plan and ask them to mention any areas that they don't understand or that they feel could be improved.

Each of these parties will assist you with the task of evaluating the riskiness of the proposed solution and help to uncover weak links.

Once the planning phase is complete, you should have comfort in the knowledge that the problem-solution is "owned" by several people and that, because you have shared ownership of the design you will be less likely to be the cause of bottlenecks as the project progresses and time becomes more expensive ;-) For example, if, at the eleventh hour you need to have an extra query written and it will be done by somebody new to the project you have 2 - maybe 3 - potential candidates for assisting them with advice: You, the DBA and the System architect.

Now that you have a plan which has been tested you can enter the "implementing" phase safe in the knowledge that your risks are known and mitigation strategies are in place to cover any perceived points of failure. The highest priority of the "implementing" phase is now to get to a known point - and remain there! But that's a discussion for another day.