The User Manifesto

Many developers complain, Donna, that users change requirements late in the project.

But many requests are common sense and based less on whim and fancy and more on a changing business environment.

The user may have "known" that a telephone number contains seven digits and an area code. But then the business gets a customer in Hong Kong, where there is no area code and eight digits in the phone number.

Ai-yah, as we say here.

No GENERAL solution exists, but a STRATEGY does.

The problem is that MIS managers (as opposed to users) enforce just-in-time and minimal coding. In some shops, writing ANY code, any utility that cannot be audited as a traceable to a documented user requirement, is a termination offense.

This is thought to align with a broader strategy of just-in-time, lean manufacturing "as if" software artifacts were "just like" an industrial product...an overworked metaphor IMO.

Excess or anticipatory coding should be encouraged within reason.

In my phone number scenario, the developers should be encouraged to make, build, buy or legally copy an international phone number parser for input, allocate a sufficiently wide field for the number in the data base, allow for a null area code, allow for a country code, and so on.

Many cities in Asia have eight digits in their phone number because we're so dense here, population-wise. But there are also countless other considerations for coding in a truly international style. A good resource happens to be the Danish developer now resident in the USA, Bjarne Stroustrup, and his magisterial Introduction to C++.

Of course, for developers to do this, they will have to be the sort of REAL professional who reads a REAL newspaper such as the New York Times every day, who reads The Economist, and who reads outside his field.

Such resources give clues as to changes that affect mere data processsing including but not limited to currency revaluations, international Internet monkey shines (such as the recent bun-fight in Tunisia) and the growing power of China and of India which in some measure is based on the fact that today, bitmapped fonts and XML render yesterday's languages barriers less important.

Here's another small example of the sort of change one encounters as globalization pressures increase, and how Bush's idiotic policies have significantly diminished USA prestige: today, the generally accepted date format (month slash day slash year) is restricted to the USA and, perhaps, the Coalition of the Willing.

Most foreigners, I have found, prefer the date in a more natural order, usually day, month, and year.

I first noticed this in Passport Control where world-wide, one usually has to fill out a form and the date is in day, month and year format.

This means that if, on behalf of a user, the programmer using Crystal Reports thoughtlessly formats the date as mm/dd/yy, the user may in turn get chewed out by the Hong Kong subsidiary, and while this may appear as a "last minute change from a user who doesn't know what she wants" to the developers, it's actually part of Getting It Right in the first place.

The MIS language singularizes and feminizes the user, making her one single airhead. But as I have said, the user is Legion, multiple persons with differing goals.

The professional programmer, IMO, is able to do an end run over the provincial wants of multiple users. The fact that such an individual is rare does not change this.

Now, the limiting case of my "anticipatory coding" is itself a major waste of time. It is to write a general compiler and hand your compiler to the end user, saying, here, Joe, just write your specs in code.

This is like giving a bum who asks you for a cigarette tobacco, papers and a match.

PART of our job (I have long been convinced) is giving a language to the user in which she can manage change. This is trivia: it starts with command line parameters. The problem is knowing when to stop developing the language and start developing the solution.

I agree with you, of course. Yet in my realm, we struggle to have fully engaged users to provide us the sort of consistent input that makes it possible to discover the varying needs of the user (in all of its diverse and plural glory). In the defense of the user (the ultimate source of my bread and butter) they are busy people who can't quit doing what they do to play with the computer people. So we do what we can...we shadow, watching them interact with their clients...trying to pick up on the nuances of their work. Of course if business needs change, so should the system, but often it's that folks weren't interested enough early enough in the project to mention the details (in which the devil lurks). And....if we get it wrong, the onus is always on the developer (and maybe it should be). We should have asked the questions differently...we should have managed to secure upper management support more effectively. Honestly, it may be different other places, but the skills we use the most are psychology, sociology, marketing, communication... Learn how to be an effective interrogator (hopefully without torture) and not only might you have a future in the armed forces, but in software development.

An important skill for a developer is the ability to push back, to ask questions, to demand that the business people, requirements gatherers, and customers get extremly specific with requirements, and to make these people understand what is easy, what is hard, and what is impossible.

I'm pretty much the one heavy hitter developer in a small shop. I can push back like hell without fear of retribution because everyone knows I'm just trying to do my job, but this is not necessarily true for most developers who work in larger shops.

The phone number and currency examples Edward cites are interesting and these are defintely the sorts of things an intelligent development shop should either push back on to get specific requirements (is internationalization ever in the history of the universe going to become an issue or should we not spend any time worrying about this) or just do "right" as a matter of policy. But I find that often, users and even business anaysists don't realize just how specific requirements must be for a developer to do his or her job.

In a recent example, I was vetting a use case and saw a requirement to allow users to select whether to view all orders or only today's orders. I had to explain that "today" needed a definition--something that is not immediately obvious but should be to anyone who understood how this system was going to be used. My user might be sitting, reviewing orders in New Jersey. My server might be sitting in Ohio. One order might be fulfilled at an airport in California. Another in Hawaii. Whose "today" should we use? Further, do we mean today as far as the calendar is concerned so that the today view suddenly flips at midnight? Or do we mean 24 hours into the future? Or maybe 12 hours in the past and 12 hours in the future.

Deveopers wrestle with issues like this every day.

Donna raises an important issue because often users' ideas about what's hard and what's easy and how long it ought to take to develop something are way out of bounds. The job of the business people in a software shop is to make customers happy, so they'll write checks that my (developer's) ass must cash. But sometimes you simply have to say no. No I won't be able to develop an entire new application in 3 weeks plus fix this whole list of issues from the previous release plus rearchitect this other aspect of the system because that seems like a neat idea. You could ask me to fly to the moon on a winged unicorn and bring you back some cheese, and though I might really really want to do that for you, well, I'm just going to have to say that I can't.

Of couse, what I'm describing is what I'm in the middle of right now. Oh, joy.