Pachelbel’s Canon

In the summer of 1986, I graduated from high school.

I got a nice sum of money for graduation and was able to buy myself a 300 baud modem for my Tandy Color Computer II with Microsoft’s Disk Extended Color Basic 1.1.

This was the kind of modem where you had to dial the phone number with a phone, wait for the carrier tone, press a button on the modem and then hang up the phone real quick while the modems shook hands.

I remember that summer with fondness.

I would call BBSs (Bulletin Board Systems), all over the United States–mostly Atlanta though. Calling out-of-state from Barnwell, SC then was actually cheaper than in-state long distance. I have no idea what it is now since all of my long distance is free.

I eventually figured out how to get it for free then too from an LD carrier that I won’t name. There were codes you could dial before making the call that would make the call not show up on your bill. I have no idea whose bill it showed up on.

Before I learned how to phreak though, I racked up a huge phone bill that I paid for my Dad for several months. I was working at a Greek restaurant making pizza’s. It was hard work but the pizza was awesome.

That summer, I would wake up around 10:00 am, go to work for a while during lunch, come home, sleep some more and then go back to work around dinner time until around 11:00. Then, that’s when the fun began. I’d connect to BBSs,  check my mail, download new files and try to hack into systems.

I managed to hack into a few weather stations, a large grocery chain, and the serial network front end to a large, super computer company by making the device crash and then playing around in the debugger.

I was pretty active on CompuServe as well and racked up a hefty monthly bill there too. My CIS id was 75457,2535. You can still find files that people have pulled from CIS with my name and number in it. Here’s one from years later with some neat Delphi code that I wrote. I haven’t looked at that in years. I eventually became a SysOp on several CompuServe Time Warner forums and hung out in the Zenith forum’s chat rooms.

This was all way before the Internet and AOL. I learned a lot that summer.

I didn’t have a lot of money back in those days. So, my CoCo was my only machine. I had written a new RAM disk that I hand assembled into machine code and then wrote a program to write the binary file so that I could execute it. At the time, I didn’t have the money to buy the EDTASM cartridge for that. I didn’t know that what I had written was called a RAM disk. I just knew that I had figured out how to access and put to use the extra 32k of memory that was in my second bank of RAM that the OS didn’t know how to reach.

One night, I downloaded this really neat program called Canon. I didn’t really know what it was and the description said that it played some really nice classical music with faked multiple voices. The CoCo could only generate one tone at a time but if you oscillated the tone fast enough you could fake it well enough that your ear couldn’t really distinguish the fact that it was changing so quickly. The end result was really impressive.

That’s the first time that I ever heard Pachelbel’s Canon. I must have listened to that song 100 times that night just staring at the screen and day dreaming about what I was going to do with the rest of my life. All I knew is that I wanted to figure out how to create software like this.

Now, as I sit here working on this new interface to iiX that I’m documenting, I’m listening to the Shoutcast Internet radio station DroneZone. There’s an ambient/techno version of Canon playing.

I can’t help but marvel at how much things have changed in the last 22 years. It seems that my life has become a canon upon itself. This time around though, my daughter and son are near their graduation in a few years.

I wonder what they’ll be doing after they graduate from high school. I can’t help but to be reminded of E. B. White’s "Once More to the Lake" and the sudden chill of death.

Why Write Software Requirements?

Does anyone ever read the bleeping requirements? Why do we even bother to write requirements if no one is going to read them?

I worked with a business analyst once who would get extremely frustrated when software developers would turn over code for testing and the software behaved, looked and flowed differently from what the requirements stated. The analyst’s favorite refrain was, “Did they even read the bleeping requirements?”

In truth, the developers almost always did read the requirements. Often, the developers had worked in the domain for many years. They had developed an intuition for the desires of the customer and had established a rapport with them. Changes were always made after the requirements were complete and simply not communicated back to the business analyst–the developers had become the analysts.

To these developers, the requirements were merely guidelines; starting points from which to build. Ultimately, the software created by these developers were accepted by the customers without complaint to the bafflement and frustration of the business analyst.

Keep in mind that we are talking about business applications in a custom development shop. This group of applications is much different than say an operating system or device driver. There is wiggle room here. Maybe not so in the other groups of applications.

Often, this same business analyst would spend a month or two creating a 50-100 page document fretting over every word and field placement and every screen title, menu option and work flow. The final document was impressive. When the business analyst finally let go of the document–notice I didn’t say finished–you’d think that the application was all but done and that there was no more requirements gathering to be done. However, something very important was forgotten . . .

One of my favorite comedians, Steven Wright, has a great joke that illustrates this. Here’s the joke:

I have a map of the United States…actual size. It says, “Scale: 1 mile = 1 mile.” I spent last summer folding it.
I also have a full-size map of the world. I hardly ever unroll it.

Now, we all know that Mr. Wright doesn’t really have a full size map of the United States. It’s simply impractical. Likewise, requirements can’t contain everything about the application before it is written. In an application of any complexity, there are always things that come up that no one could have anticipated.

In one of the best books on the requirements gathering process– “Exploring Requirements”, by Donald C. Gause and Gerald M. Weinberg–one of the very first points made is about the distinction between a map and the territory. Basically, the map is not the territory and, when in doubt, trust the territory.

That’s all these developers were doing. They were trusting the business domain territory. Of course, not every developer can be a domain expert; most aren’t. But just because a finished product doesn’t look exactly like the requirements doesn’t mean that the developers didn’t read the requirements. So, yes, they will read it. But no, they may not follow it to the letter.

So, do people really care about the requirements gathering process at all? Of course they do. The value of writing requirements is not in the end result though. People don’t sit back and look at the requirements and feel content that they’ve accomplished something that is going to be useful to the business. You’ve just finished starting. In terms of maps, you just plotted a course. The real work follows. Don’t be surprised when there are detours along the way. You should expect them.

The value of requirements then is in the doing; the gathering of information and exploring of the problem domain. This process can be daunting or easy depending upon the domain and the expertise of the people gathering the requirements. You must be careful not to get too caught up in the creative process of this though; you can easily waste valuable time.

Sometimes the gathering process can take months. A lot of knowledge is gathered in the processes that never makes it into the requirements but are crucial for the success of the project. These are the artifacts that still, in spite of being left out of the official requirements, somehow make it into the system anyway. These are the things that customers remember in conversations that make them happy when they see them.

I once worked on a project where analysts had been using UML Use Cases alone to capture requirements. It was very evident that they had never really built a large system before. The use cases, when printed out, fill three 5 inch binders. The diagrams looked like one-to-one connectivity matrices for a 1000 node network. I instantly nicknamed the tome “The Useless Cases”. That’s what they were. Almost 2 years had been spent on the effort and no one had a grasp on really what should be built–and nothing was.

I spent a few weeks with the domain experts (nurses) and created about 10 high-level DFD diagrams along with supporting English; something everyone could understand. The project took on a new life and when the investors came calling they were elated by what had been accomplished. As a result, we received new funding for the project. They weren’t impressed with the “The Useless Cases”.

That is one extreme of writing requirements. The other end of the spectrum is the paper napkin. This is what you’ll hear touted as Agile (I call it Fragile) and eXtreme programming (eXtremely NO requirements). The very few attempts that I have seen to adopt these new fads for requirements gathering yielded no better results. In the end, requirements were gathered, but, in a haphazard way that yielded functional results on a few occasions but with little gain over other methods I have employed.

Be sure, I’m not bashing RUP or Agile or eXtreme. There are elements to all of these approaches that are appealing when describing a problem to be solved. The key is to make sure that you don’t loose sight of why you are writing the requirements in the first place. So, let’s answer the question already . . .

We write requirements so that we are forced to think about the problem a little and map out a plan before actually creating the solution to the problem. Maps, like use case diagrams, stories, state diagrams, DFDs, IDEFs, class diagrams, ER diagrams and flow charts are only a part of the mapping. No single map is enough in itself for creating the solution. In the end you’ll need a collection of maps tied together with something I like to call English.

The solution to the problem . . . well, that’s in the writing of software–the territory. But that’s another blog . . .