The Cube – Resistance Is Futile

One of my relatives gave my 15 year old son a Rubik’s cube as a Christmas gift. It came with some instructions that taught you a few things about the cube; strategies for solving it, etc. He played with it a few seconds, giving it a turn or two and then put it down to move on to the next gift. That was the last I had seen of it since Christmas Eve.

So, I’m sitting here on New Year’s Eve, researching IRA rollover options, investment strategies and looking at the list of online streams of Echoes. I like to occupy that side of my mind with space/ambient  music when surfing the web–kind of like a soundtrack to my life. In the middle of this, my son walks up and says, "I’ve got it". With a big grin on his face he hands me the cube–solved.

I had forgotten what that feels like.

Of course, being the good father that I am, I had to pick it up and act like I was going to scramble it again to teach him the futility of solving it. His eyes widened with fear until he realized I was teasing. "Daaauuud" he says, dragging out my one syllable name.

It was fun to notice in him that air of satisfaction that comes with solving a hard and complex problem after working at it for days. I’ve been trying to get him to experience that with computers for a while. But, he really hasn’t showed much of an interest. He has VS 2005 on his box–doesn’t touch it. I think it is because he was introduced to computers at school as tools for writing papers, researching the web and playing games. He still hasn’t seen it as the "big cube"–but that doesn’t stop me from trying.

So, I said to him, "You know, that’s what I do every day; solve really neat problems like this only it’s a lot more fun and satisfying–especially when I get to create new things." Then I had to ask him if he had done his chores and how far he had gotten on his math packet he’s supposed to be working on over the break. He just looked at me and I could tell he didn’t want to hear another speech.

I decided instead to Google Rubik’s cube and found this nifty site that lets you play with the cube online. Oh, did I mention that it will solve a random cube for you? Huh. Man have times changed. We played with the cube online for a while and when the "wow" factor had worn off I said, "You know, there’s a lot of math behind this." I am a math major after all. Double whammy. Math major and Dad. Poor kid. I was surprised when he said, "Math? How’s there math in this?" The math had gotten his attention. 

So, we quickly Googled "Rubik’s Cube Math" and started surfing and found a site called "Mathematics of the Rubik’s Cube". The first document on the page is a 45 page layman’s attempt at the math without talking about math. Unfortunately, I think they failed at it. How did they fail? Well, when you say, "We do not assume any knowledge of group theory" and then your proof for Proposition 4 is "This proposition is really obvious if one understands what it means" I think you’ve failed. I mean, really, is that a proof? I think not.

However, the document served the general purpose of my pursuit to illustrate how math is being used to describe and solve the cube. I never studied the cube in detail in college (so many years ago . . . ) but it was fun to see the college level math language for the first time in many years. Man I have forgotten a lot.

That was enough math for Curtis and he quickly slipped away with his cube contemplating the math of mappings, homomorphisms, sets, projections. And, as he left my room I heard him softly say, "How did they make it solve the cube? That was so cool!"

I smiled. Maybe there’s hope just yet.

Update All Fields in Word Documents

Automatically update every field element (e.G., Table of Contents, Document Fields, Computed fields, etc.) in a Microsoft Word Document in one motion.

In the business analysis, tech-lead part of my job, I tend to create Word documents that can be used in a "template" way. For example, if I have revision numbers, dates, company names, document titles, etc., I’ll create document fields and place them in the document instead of the actual value. This way, if I want to recycle the document for a different situation, I only need to modify a few key fields and update the document.

However, Word doesn’t give you a way to update all the fields at once. You have to highlight the entire document and then update the various components separately. This includes visiting each set of headers and footers if you happened to use a field like a document title in them.

So, to make life easier for me, I created this little macro that will visit everything in the document and update it. Here’s the source code:

Sub UpdateAllFields()
Dim oStory As Range
Dim oField As Field
  For Each oStory In ActiveDocument.StoryRanges
    For Each oField In oStory.Fields
    Next oField
  Next oStory
End Sub

Just copy this snippet into your base, Then, tie the macro to a button on a command bar and you have a one click "Update All" widget!

The next time you want to change something about a document, all you have to do is choose "File Properties", change the field on the custom tab, return to the document and click your snazzy "Update All" button. Presto, new document with different titles, customer names and numbers! With this macro, you’ll be cranking out documents faster than anyone . . .

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 . . .