Why make life hard for others without good reason? It’s just plain old negligence!

Consider the metaphor used by Brooks regarding essential and accidental activities from the point of view of an employees day-to-day tasks.

The essential tasks are those that are an employees primary concern. For a developer this is as simple as correctly expressing requirements in code in an organized fashion. Any tasks that are a consequence of the essential are accidental. For a developer fixing technical bugs would be accidental. Consider it wheel spinning.

The more time consumed on accidental tasks, the more ineffective the employee. It’s a sure sign that something is wrong either in process or personnel.

If an employee is aware that a decision will generate accidental activities then there better be a damn fine reason for it, otherwise cry negligence! Sometimes being unawares of this is bad enough as some accidental activities are simply unacceptable, for instance fixing transaction ACIDity post-production. In such cases if you are aware of these problems and your position suggests you must act on it, doing otherwise is the grossly negligent and your neck should be at risk.

I once believed that a live application is a successful application. I hear and read plenty of stories about unsuccessful projects concluding long before being able to bare an application.
I’ve since learned that this judgment is not so simple. Project engagements usually see me leave shortly after applications go live, but I’ve now had a few occasions were I’ve worked on a living application. I now believe that the success of an application is measured by it’s usefulness as measured through the eye of the user.

So why would an application be, in a relative sense, useless? Here’s a couple of simple theories:

• There’s no adequate voice representing the needs of the users (In XP terms, the ‘voice of the business’).
• UAT without the U.
• The application is too difficult to morph to business needs, or other natural end of life scenario’s.
• The application features are no longer needed by the business.

Ideally we’d all like our applications to experience the last scenario. But what can you about the first two scenarios? From my point of view, the best course of action would be:

1. Judge whether the application is more of a hindrance than a help. If it is a hindrance, bring down production.
2. Bring in a real user to work with the development team. Justify the cost of that persons relocation against the cost of having a useless system.
3. Consult this user when marking up stories.
4. Make that user a significant body in the testing group, ideally checking functionality as soon as possible i.e. when the developer believes they are done.

Now this is all really XP voice of the customer stuff. For mind, it’s common sense, as most things the XP way tend to be.

Are there other criteria you can use to judge the success of an application? Absolutely. Here’s another I rate highly - success is measured by the technical support required to perform an applications day-to-day tasks.
Clearly if you’re in a situation where you’re having to perform things like:

• Munge data due to application transaction boundaries not being clearly defined.
• God forbid: Create external applications and tools as workarounds.

Then the ship is sinking fast and developers will be quickly wheel spinning just to keep the application running. Why is the wheel spinning? In the long-term these patch solutions are not evolving the application by making it more useful, in effect you gain no ground.
While some patch solutions can be commended for their creativity, if you think it’s ‘problem solved’, think again. In the bigger picture of things they are just temporary fixes to core of requirement, design and architectural flaws. Clearly the most responsible course of action involves stepping back and tackling these core issues.