|
Managing IT:
The Un-MethodologyDevelopment practices for programmers, sans hype.
Contents
Overview
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".
1. Developer judgement is required.
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.
2. Consumer rights should be respected.
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).
3. Seek advice from many local experts during
requirements-acquisition and design phases.
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.
4. The value of customers' time should be respected.
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.
5. Hacking has a place.
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".
6. Programmers: Know Your Craft
(Consider requiring tested programmers in place of weakest-link limitations.) 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.
7. The buddy system can be helpful
(A mentoring program can be helpful but should be used with care.)
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.
8. Privacy can be helpful.
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.
9. Collaboration can be helpful.
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.
10. Some combination of top-down, bottom-up, and phased releases are usually
indicated on medium to large projects.
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.
Permissions
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.
Other Resources
Here are some links that may be helpful in the context of this article.
Notes
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] |