Friday, May 27, 2011

The Assumption of Fixed Requirements


Note 1: This post is extracted from Chapter 9 of my book, CHANGE: Planned and Unplanned.

Note 2: This book was written for project leaders in high-tech industries, but writers are also project leaders, and writing certainly requires great skill and precision. For writers, requirements may originate from publishers, agents, and for-hire customers—any of whom can cause unending grief by changing those requirements for a writer who has assumed they were fixed.

Until recently, the computing industry seems to have avoided the subject of requirements the way a debutante might avoid the subject of indigestion. We knew such things existed, but if we didn't think about them, perhaps they would simply take care of themselves.
Many of the classic early papers in software engineering were based on the position:
This is how we would design and build software (if we had unchanging requirements.)
[For writers: each of us has her/his own process for writing, but for many of us, that process is also based on having unchanging requirements. If someone changes our task, we may be thrown off our game, and into write-stopping turmoil.]

For instance, many of the early papers on structured programming were based on the Eight Queens Problem, a problem of fixed definition with no input whatsoever. Many papers on recursive programming were based on the Towers of Hanoi problem, another problem of fixed definition with no input whatsoever. The more recent Cleanroom methodology has the same basis: "The starting point for Cleanroom development is a document that states the user requirements." The following quotation from Parnas and Clemens shows how deeply this assumption runs, even in the most sophisticated process designers.


Usually, a requirements document is produced before coding starts and is never used again. However, that has not been the case for [the software requirements for the A-7E Aircraft]. The currently operational version of the software, which satisfies the requirements document, is still undergoing revision. The organization that has to test the software uses our document extensively to choose the tests that they do. When new changes are needed, the requirements document is used in describing what must be changed and what cannot be changed. Here we see that a document produced at the start of the ideal process is still in use many years after the software went into service. The clear message is that if documentation is produced with care, it will be useful for a long time. Conversely, if it is going to be extensively used, it is worth doing right.
Parnas and Clemens describe the benefits of returning after design to create a requirements document as if it had been present from the beginning.
In the light of all this literature, it's easy to understand why so many software engineering managers have made the mistake of believing they should have unchanging requirements before starting any project. This model or belief is what I call the Assumption of Fixed Requirements, an assumption that is a misreading of these classical works. These classics were not addressing the entire process of software engineering, but only selected parts of that process. What they are teaching us is how to translate requirements into code, once we have reliable requirements.
Translating requirements into code is an essential part of software engineering, and it is the part that has received the most research attention over the past decades. Because of that attention, however, it is no longer the most difficult part of the process. Many organizations know how to do this part quite well, but the quality of their products does not adequately reflect their coding prowess.
In recent internal studies of serious quality problems, three different clients of mine arrived at quite similar conclusions. They divided the sources of the most serious problems into a number of categories, including coding and gathering requirements. In all cases, coding contributed least of all categories to quality problems, and my clients would perhaps do better to work on the less glamorous job of improving their logistics processes. Perhaps these rather advanced organizations are not typical of all software engineering organizations. They still have a lot to learn about coding and especially design, but in each case, the majority of their serious problems stem from requirements.
Software engineers and their customers perceive quality differently, and this table accounts in large part for that discrepancy in perception. Over the past decades, engineers have seen coding faults drop dramatically as a result of their quality improvement efforts. The customers, however, have not seen a comparable decrease in the number of requirements problems, and so do not perceive the same increase in quality as the engineers, who are paying attention to their own priorities—which don't happen to coincide with their customers' priorities. The engineers need to learn that they will never become an Anticipating organization by getting better and better at coding—even though that was the improvement process that brought them as far as they've come.

Wednesday, May 11, 2011

Writers Are Losing the Fight Again

Dean Wesley Smith has written another scathing post about "agents" trying to scam writers in "the new world of publishing." Please read it: http://www.deanwesleysmith.com/?p=4096&cpage=2#comment-9194



It's a terrific post, which it has in common with all Dean's posts, but this time he made one little mistake, so I had to write a comment on his blog.

But there are so many comments (as there should be, and you should read them all), you might miss mine, so I'm repeating it here.


Dean,

I’ve been thinking about this whole scheme and decided it’s not a scam at all. It’s actually a terrific idea, with only one slight flaw.

All that it needs to make it a fair deal is to make it symmetrical. In particular, the agents have the right idea about expenses. This is a business, and it’s quite right that the partners in such a deal should be reimbursed for their expenses before any royalties are distributed.

So, I’m looking for an agent who will write a contract with me where s/he gets expenses and so do I. Let’s see, what are my expenses?

Well, there’s toner for my printer.

And several reams of paper.

And the printer itself.

And the computer.

And the software.

And my office, and its furnishings.

Let’s see. What have I forgotten. Oh yes, there’s about 20 years of schooling so I could learn how to write. Let’s figure conservatively about $50,000 per year. It’s probably a lot more, but we don’t want to take advantage of the poor agent, so we just have $50,000 times 20, which seems to come to $1,000,000 before I could write a word.

Now of course, my schooling was a long time ago, so if I hadn’t spent that money learning how to write, I could have put it into US Treasury bonds and easily earned, say, 6% on the average. And I finished my schooling roughly 50 years ago, which means the $1,000,000 would have doubled roughly 4 times since then, making $16,000,000 today.

Don’t you just love this calculating “expenses”? (That's an important part of the new agent scam contract.)

The way I figure is I’d happily sign with an agent who’d give me $16,000,000 up front to cover my expenses.

Or, since I’ve published roughly 100 books, I’d be willing to take $160,000 up front from any agent wanting to contract with me to handle a book of mine.

So, agents, if you’re reading this, better hurry and get your cash in hand and contact me before all those other agents beat you to the punch.

Yes, Dean, I’m sorry, but you’re just going to have to write a retraction saying what a good deal these new agent ideas are for writers. Agents, please insist on it.

Oh, and by the way, here are two of my most recent eBooks, which you can sample at http://www.smashwords.com/profile/view/JerryWeinberg?ref=JerryWeinberg and purchase them there, or at Amazon or Barnes and Noble.


Thursday, May 05, 2011

Project Mercury

I was one of the workers on Project Mercury. My job was to design and implement the space tracking network, and particularly the multiprogrammed operating system that ran the entire network. Many readers have asked me about Mercury, so here's a little something courtesy of SPACE.com:

See how the first American astronauts flew in space on NASA's Mercury space capsules in this SPACE.com infographic.
Source SPACE.com: All about our solar system, outer space and exploration