Writing It And Maintaining It

Let's talk about two periods in the ProgramLifeCycle?: Writing it, and Maintaining it.

Writing it. You have too much to do. You have too few resources. You have impatient users and funders breathing down your neck. If you don't get finished, no one will care about Maintaining it.

"They" want it done. But you know that as soon as it's done, they'll want it modified. You will be Maintaining it.

Maintaining it. You have too much to do. You have too few resources. You have impatient users and funders breathing down your neck. Sound familiar?

It always comes down to this: you have too much to do. You can learn to go faster; sometimes you can get some help. And still you have too much to do. When you have too much to do, there is only one way out: you have to do less. The customers and funders can ReduceRealScope. The only thing you can do is ReduceHiddenScope. --RonJeffries

Two thoughts in response to this:

First, common business humor aside, if you have too much to do, meaning you've committed to doing something you don't really have the time and resources to do, then you're in trouble, and something's got to give. It's a situation everyone gets into sometime (unexpected loss of resources or addition of required functionality), but it shouldn't be business as usual. See DeathMarch.

Yes. And many (most?) projects are in this state much (most?) of the time. Something's got to give. You can conscientiously report actual progress, so that people will not be surprised by the slippage; you can prevail on the customer to ReduceRealScope; you can prevail on the funder to increase resources. And you can look into your process for things you do that do not, and will not, pay their way. That is, you can ReduceHiddenScope. --RonJeffries

Second, Writing it and Maintaining it should be much more closely coupled than the above would indicate. For one thing, for most modern development cycles, you're maintaining it (modifying and extending existing code) very early in the process, even if on the whole you're producing a new program. Eventually, depending on the development environment, you may get to hand "it" off to another group, or you may wind up doing ongoing maintenance (ideally in deep background mode), but in any case, "it" had better be maintenance-ready.

Of course. But let's examine carefully our activities that are aimed at getting it maintenance-ready. If these are paying their way, let's do them. If they aren't, let's optimize them, perhaps even to zero. --RonJeffries

If what you deliver is not ready to hand off to another group for maintenance, you've delivered a prototype of "it", not "it". To really write it you must not only produce something that works (that's an important element, of course, but insufficient); you must also PrepareTheWay for those who will maintain it. Cutting corners on the latter in favor of delivering something sooner will eventually bite you, one way or another. --JimPerry

Straw man. No one is suggesting not doing things that really should be done. XP does suggest that we look very carefully at the things we do because we think they should be done, and reduce them to the minimum necessary. Design, documents, comments, code ... all should be done as simply as possible. And no simpler. --RonJeffries

Those who have a job where they don't often feel that they have too little time (the normal sensation that says you have too much to do), are in a very lucky position. Between the growing expectations of management, and the irrepressible optimism of most developers, a gap between what's "expected" and what can be done is quite common. That's why Yourdon wrote DeathMarch, and why we all bought it.

The purpose of this note (obviously not successfully communicated) is to point out that when we feel we have too little time, or too much to do, we must reduce scope. As developers, we have control over "hidden scope", the things we do just because we think they're necessary. Some of them may not be, and by reducing or getting rid of them, we can get more done by doing less of what isn't needed.--RonJeffries

One of the best little Aha's I ever had was the day I figured out that if there are an infinite number of things in my job I am supposed to do, then there are an infinite number of things in my job I won't be able to do... If there are an infinite number of things I won't do, then it doesn't matter how small I make the number I actually do, because I will ignore an equally infinite number. Once I realized that, I was able to shrink my job from the job of 10 people down to the job of one person. No one really noticed, because I was still not doing an equally infinite number of things. But I slept better at night.

I am applying the same thinking to written documentation nowadays... There are an infinite number of things my models and documents don't capture, so I can reduce my modeling and documenting to whatever I like and be comfortable in the knowledge I am still ignoring the same infinity. I sleep much better at night, and waste much less energy on the project. This all leads into a different discussion of modeling and documenting with "insufficient" models and documents (obviously I don't believe they are insufficient, they are just sufficient in surprising ways).

--AlistairCockburn

Interesting sidenote regarding documentation. In one of his books, GeraldWeinberg says that we ought to just make videotapes of the developers talking at a whiteboard about whatever they feel will be important about their system's maintenance. This cuts documentation overhead and better communicates the developers' intentions and sense of what is important.. things that are not easy to discern from the code.

This, unfortunately is not an option for me. I work in one of those FDA/ISO compliant, safety critical, high ceremony arenas. But, I do find that over the years I spend proportionately more time in my documentation describing intentions, possible extension points that I planned for, and key considerations for maintainers. In short, the documents actually communicate something more than the typical "what" of design documents. The first time I did this, many were up in arms that I actually wrote future plans and guidance blurbs in design documents. I won the day, but they were incredulous at the time. -- MichaelFeathers

I've started a new thread on TooMuchDocumentation .

JensColdewey