The Un-Methodology

The following is a response to various methodology based "name-your-metal bullets" that (IMO) have been excessively hyped in the industry press by their advocates. For a reaction, see the satire here titled: "Agile Bridge Building".

All declarations in this list should be thought of as suggestions. They should be used when, --in the judgment of competent developers-- it makes sense to apply them to the design and development tasks at hand. They may be applied in part or in full, depending on the customer's requirements, as they are interpreted and understood by those designing the solution.

Developers must act with nonfictional integrity when dealing with customers. The contract between the customer and the developer should embrace accountability and be trustworthy. It should allow the customer to produce plans, analysis, and resource allocation decisions based on promised results by promised deadlines, and then deliver on those promises. To this end, designers should provide written, unambiguous, and understandable descriptions of what is being provided to the purchaser with realistic, guaranteed estimates of the amount of the consumer's time and resources required to achieve the finished result. In the case of a large task-oriented project, precise details of the current phase should be provided along with contingent details of the containing project (at least).

In the context of this list of suggestions, an "expert" is someone who works directly in the problem domain regularly and who may be expected to use portions of the solution being developed regularly at its roll-out. For example, a developer designing an IT asset tracking system for a company should consult people in the company's accounting department who are responsible for handling the accounting of such assets. He or she should also consult with those in the IT support department who must maintain and install IT assets, among others. A diversity of views about user-priorities, tempered by judgement, can lead to useful perspectives on your design. While such empathy has a place, judgement and experience will also dictate that design by committee be avoided.

The most valuable people to the success of a project are the company's experts as defined above. These people are also valuable to the company's day-to-day operations. While experts should be consulted regularly during design phases; plans and specifications should be defined in a way that is most convenient and understandable for those experts to interpret, authorize, and use. Plans should be developed and distributed in a way that is most respectful of the value of the experts' time. This generally means written plans that can be read at the experts' convenience --OUTSIDE of real-time[1]--. Designers, on the other hand, should be available --IN real time-- to answer questions and make changes to their specifications for some period after each distribution of plans to experts. Developers should track all feedback given by domain experts.

When doing exploratory work to understand underlying or structural limitations; When doing work to learn, or better understand new tools or constructs; When performing experimentation to determine the best way to attack a problem domain; When determining feasibility and performance limitations; When helping domain experts and consumers understand and/or visualize a particular design decision or algorithm, hacking --i.e. coding without a written plan-- can be very useful and even indispensable. The term "hacking" as it is being used here, is sometimes referred to as "prototyping".

People who have not taken the time to master the most basic skills required by their programming craft, such as: proper pointer hygiene, stack interactions with recursion[2], threading resource usage and sequence issues, atomicity and database transaction issues, etc. should not be permitted to work on production code or designs. There is a school of thought that says to simply avoid "problem" constructs, such as pointers. While this might reduce some problems, a "programmer" who has not bothered to master even the most basic skills of programming is likely to introduce many other vulnerabilities and defects into design and code, regardless of whether you limit him or her to a safer sub-set of skills. We all make mistakes, but we should recognize a difference between mistakes caused by temporary human lapses in judgment, and mistakes --made repeatedly-- due to a lack of understanding about the use of a given basic programming concept.

It is good and prudent to erect a safety net under the high-wire. Trouble ensues though, when we begin to believe our safety net negates the importance of hiring programmers who can work safely without one.

New programmers, and experienced programmers who are new to a project can be helped by matching them up with another programmer for a time. The mentor in this case, should be selected with great care to be someone with attributes you judge to be important to impart to new people. Some examples might include a proven track record of low defects, high productivity, and/or creativity.

Those who have written small to medium sized projects or project chunks from conception have all indicated that large contiguous periods of private, closed-door time can be very helpful and conducive to varying levels of "flow". Developers should be given control over long time periods where they are permitted to limit interruptions and work in flow.

Just as helpful as alone-time, is the ability to bounce questions and problems off of other developers to get a fresh perspective or a new set of eyes on the problem. The alone-time recommended in point 8 should be tempered with specific mechanisms[3] to allow developers time to freely share advice and chit-chat with each other.

Avoid dogmatically following a specific set or sequence of these approaches. The approach or combination should be selected on a case by case basis, to be carried out with deliberate, planned, execution, based on contemplation by developers and programmers charged with the task of producing the project. In the case of large phased (or "task oriented" or "iterative") projects, specifications should be delivered in fairly detailed, but contingent terms for the entire project, and in precise detailed terms for (at least) the current deliverable phase.

This article is © Copyright, Creativyst, Inc. 2004-2011 ALL RIGHTS RESERVED.

Links to this article are always welcome.

However, you may not copy, modify, or distribute this work or any part of it without first obtaining express written permission from Creativyst, Inc. Production and distribution of derivative products, such as displaying this content along with directly related content in a common browser view are expressly forbidden!

Those wishing to obtain permission to distribute copies of this article or derivatives in any form should contact Creativyst.

Permissions printed over any code, DTD, or schema files are supported as our permission statement for those constructs.

Here are some links that may be helpful in the context of this article.

• Software Program Managers Network (SPMN)

1. Real-time - For the purposes of this discussion the difference between real-time and not real-time are almost exactly analogous to the difference between instant messaging and forum messaging. Instant messaging or verbal discussion are real- time, requiring participants to occupy the same point in time in order to exchange information. On the other hand, forum messaging or written plans are outside of real time, freeing all participants to read and comment on the information at whatever time is most convenient for them. [back]

2. Stack interactions with recursion - On some projects I've done, the same people who pepper the code with pointer bombs were also likely to make mistakes with recursion that blow up the stack. These have much the same effect on code stability as pointer mistakes in that the code will seem to run just fine for a couple of hours or even a couple of days before crashing (usually just long enough to do a demo for the executives). But the odds will "always" catch up and it will crash.

Unlike pointer bombs, these are difficult to find with a simple code review and don't lend themselves to using the debugger or other automation. They usually involve un-rewound recursion that is spread over three or more functions (sometimes dipping down into system calls). A weak indicator that this might be happening is if you see large stack size settings as part of the make. That is often called for, but it could also be an indicator that people are tweaking around the edges in order to get the project through meeting demonstrations without crashing. [back]

3. Specific mechanisms - If you're going to formally allow programmers to limit access, giving them time for which they have nearly complete control over interruptions, then it might also be wise to specifically set aside some times when they can be interrupted. Doing this will coordinate those times, mainly so that interruptible time occurs at the same time for everyone. Formally planning common, synchronized times when all are free to interrupt others may also help protect and strengthen their ability to limit interruptions during Do-Not-Disturb time. [back]