Fort Awesome

Short title, becuase I am sick and tired at how the recent links look. All cluttered and all.

It’s been slow trying to slog through my Quixotic Quest, but I did read 23 Days in July: Inside Lance Armstrong’s Battle to Win a Record Sixth Tour de France. Good read. I could not put it down, and afterwards I wanted to ride. Yet, I am so lazy that I didn’t. There are no excuses, but I seem to find one any way.

I liked the book. I love the Tour de France. Even if Lance Armstrong wasn’t in it, I would still watch. I was a fan of bicycle racing since I was a little kid. And I have watched the Tour on TV even before there was a Lance Armstrong to root for. Actually, my favorite is Jan Ullrich. Always the perennial bridesmaid.

Anyway the book was pleasant. It gave me more insight into the team strategies involved in racing. I was only disappointed in the fact that the author did not focus on the French rider, Thomas Voekler, much. For me, he embodied the spirit of the 2004 Tour when he defended his yellow jersey in the 15th stage finishing at the top of the Plateau de Beille. He rode the race of his life and just maintained his lead over the unstoppable Lance Armstrong at 0:22 seconds. Incredible! What gusto! He would lose the yellow jersey the next day, but it was amazing.

B+.

“Jimmy, PLEASE don’t tell me how to run your business- which again is now mine.”

Homework Assignment 2-3 Notes.

What is the maximum recommended cyclomatic complexity?
10

What exceptions are there to the answer in “a” above?
Case or switch statements. Question: Does this include if()elsif()elsif()else statements where the condition is testing the same variable? Stupid. Isn’t that a case statement in disguise? Yes.

How would you use the information gained in the article if you were software manager for a major new program?
Cyclomatic complexity is a metric, a measurement of the code of the program. It can be used to describe the quality of the code, and it can be used to prescribe where to focus testing and changes.

  1. Use it to identify bad code: hard to understand, hard to test and hard to modify.
  2. Use it to stress the number tests per module which in turn helps delineate the testing schedule: time, man-hours, etc.
  3. Use it to determine what areas to concentrate on fixing or testing.
  4. If you have third party developed code, use to control it’s quality.

Cyclomatic complexity seems to drive testing from the developer’s viewpoint. How does it work for system tests? Configuration management? Quality? Safety? These are software departments at work.

I’m sorry I have been posting my homework. I have to so that I can read over what I did at work or in school or anyplace else. You see, I can cut and paste this stuff straight from the web. Unfortunately, it’s also clogging up my recent posts list with somewhat useless stuff, but hey, if you’re a software engineer or in school feel free to join in a post a comment.

“This is just a standard management technique that has been used by personnel supervisors since the days of.. Ho Lu, grand emperor of the Wu dynasty.”

This is assignment 1 due during week 2, and it is related to this post for school. Download it from here in order to print it out.

In the early 1990s, a piece of telephony software written by the DSC Communications Corp. caused some phone outages across the United States. The root cause of the problem was traced back to a typing mistake. The bug occurred in three lines of a million line program. At the time, Frank Perpiglia, Vice President for technology and poduct development at DSC had said that the intended change to the software was very minor, and that it had been determined that the usual rounds of testing of the software was not needed. In hindsight, that was a bad idea.

Yet, to put the blame on insufficient testing is to ignore the other factors which contributed to the software bug. In fact, I would say that the problem really resides in the policies and procedures that allowed the developers to release their software with less than adequate testing. A symptom of this lack of quality-focused policies can be found in the cavilier comment from Perpiglia, “We had a small modification to make a small change. We felt that the change itself did not require three to four months of testing.” It was sheer folly to accept the risk of not testing the change.

First, let’s focus on DSC’s software configuration management policy, if they had one. A change was going to take place on their software. Was there a need for the change? Was the fix to address a bug or was it relatively minor? From Perpiglia’s statement, it seems that DSC deemed the fix to be a minor, inoccuous change. It probably was also somewhat necessary. I can’t believe that a simple patch of less than several lines of code would be released at the whims of the company. From this viewpoint, did software configuration management accept the necessity to change the software and at whose discretion?

Secondly, let’s take a look at this issue from the software developers position in relation to their processes and procedures. To make the change requires at least a minimal set of informal tests. Was there a procedure for code/peer review? Even in an informal setting with several peers and domain experts maybe the flaw could’ve been spotted. It literally was a typo that was the problem. At the least, was there a procedure to conduct unit tests on the change? Perhaps a unit test could’ve caught the flaw early exposing the unit under testing as not performing correctly. A set of procedures for the developers would’ve been helpful in spotting the problem.

Finally, focus should fall on the system test group. Risk was taken to not test any of the software, because running a full set of qualification tests was time consuming. Still, could they have developed a reduced set of tests to ensure that the change would not produce any bugs? They knew the functional area affected, they could’ve run a smaller set of tests specifically focused on that small requirements which were affected. Did they have sufficient tests for that functional area or was the bug the type where the code changes in one part of the program and wholly unrelated piece fails? Sometimes the a small set of tests would not uncover the bug, and the full complement of qualification test is needed to discover it.

In summary, the problem with the DSC software could be traced back to problems with the policies and procedures that were in place. They were lacking, because it allowed them to assume the risk that an insignificant change to their software would not produce any anamolies. DSC neither planned for the change, reviewed the change, nor adequately tested the change. It was not just the lack of test time that did them in, but a lack of focus on policies and procedures that would’ve helped them focus on delivering a quality product.