Technology Webcasts

Recent availability of personal high-speed networking made available delivery of tech netcasts over the web. Two of my favorite regular broadcasts include 1) CommandN: available from youtube.com and 2) Tech Talks off of video.google.com.

Worth a view if you haven't seen them before.

Desires and Diversions

In college our computer science department had a series of videos, each with a computer science theme. One of the "Distinguished Lecutres" Series was given by Allen Newell entitled Desires and Diversions and is one of the most motivational lectures I've ever experienced. I recently located it on the web and figured I'd share.

I've recently uploaded to YouTube, links below:

Tinkering with Ruby

I've recently decided to expand on my OO arsenal by picking up Ruby and Python.

Not much to discuss yet as I am just beginning my journey into Ruby.

One thing perhaps worth noting is the reason that I chose Ruby, that Scott Meyer a notable authority of C++ has high opinions on Ruby and "Ruby on Rails" stating that he feels that it's the next generation object-oriented language.

The Dirty Little Secret of CMMI-Level 5

There are a-many things that I think are great concepts but tend to fall apart in the real world; for instance "always tell the truth", "turn the other cheek", "fat-free desserts"...sure, they are great ideas on paper, but when practically implemented they leave you with a black eye, two bruised cheeks, and a mouthful of what tastes like damp sawdust.

The first time I heard about the CMM-level assessment concept I thought what a great idea. Have an independent assessment of your companies strengths and weaknesses, identify an action plan to strengthen your weakness and strive for an even stronger level of capabilities by reaching for the next ladder rung and just work your way to the top. Hey, it was authored by a character from CMU, a notable university, it must be good.

I won't speculate on what might have been, but this concept took a downward spin the day that the Department of Defense decided that all defense contractors have a deadline to achieve level-5 or risk loss of program funding (sigh). Since that wise and ever-so-informed decision (wink) it's been every defense contractor's ambition to make it up to the last rung as quickly as possible. I've witnessed some of the most unethical behaviors in pursuit of this highly acclaimed prize that I only wish I never again see. Contracted independent assessor findings bought and paid for, the hand-selecting of individuals that will mindlessly tout from the Book of Process, and 9th inning e-mails identifying the expected questions assessors will be asking and the proper response (with emphasis on stating only the defined answer and directing to say no more). I ask you, in the pursuit of all contractors achieving level-5 how greatly has it reduced the cost of development programs? Not a dime, it has instead increased program costs.

Sorry for the short rant, the validity of CMMI assessments isn't the subject I wanted to write about, but is directly related. See, now that most defense contractors have fully embraced CMM there is an underlying tone that comes with the price of admission. Assets are all interchangeable; this is the basis of CMM, take a development process and define enough paperwork and instructions such that any monkey that can read can follow it to success (hearty laugh). In recent history employees somehow lost loyalty to their employers and as a result the employers suffer high turn-over. How do you fix this you ask.....well let me tell you.......CMMI level-5(tah da). This magic elixir will allow you to lose an employee, snag an innocent pedestrian off the street, strap a cubical 'round them, hand 'em your defined process and procedures and not miss a beat. Employees are one-size-fits-all and are replaceable at a moments notice.

While I've always speculated that this is how the Mahogany Row muckety mucks looked at their underlings it became obviously apparent as I spent 4 1/2 hours in process training this morning. When asked how the company selects teams for a newly defined program he all but said pick who is available. "How do you find candidates with the proper tool, development methodology, domain experience and such" I asked. "I don't know" he replied. So what you're saying is that there is no way to establish my skill sets nor career interests in hopes to be recognized as a candidate for a new exciting program. What you are saying is that their is no way to align my career aspirations, nor technical experiences, or interests with the companies goals? So even though I accepted a position at company X because they were working in an interesting domain Y and I have expertise in Y when that program is completed there is no way for me to be selected for a new project in Y? Are you kidding?

My point is, I'm still young, ambitious and still love working on 'interesting problems'. I hired into my current company because they have 'interesting problems' and a boat-load of dull ones. Looking at me as a cog and not taking into account my experiences and technical desires you risk losing me when you blindly move me to a position not in line with my individual goals. Treating me like a replaceable cog will increase the likelihood that I'll leave and only increases your turn-over which was the reason you adopted CMMI. The solution becomes the problem.

Code Generators

On our way to lunch a collegue of mine asked for my thoughts concerning MatLab-generated code. I repeat my thoughts on the subject here, just for fun.

Even in college, some 16 years or so, I can recall strong opinions on generated code and drag-n-drop programming languages. As a computer scienced major, I shared the same opinions as the majority of my peers; frankly, that drag-n-drop and auto-generated code is sloppy, unmaintainable and for people who can't handle programming in a real programming language.

I find over the past couple years or so, that my opinion on such subjects have changed a bit. My opinion has softened from the defensive stance of yester-years. Present-day however, some of my collegues share my past opinion with the same level of zest and fire as I once had.

My change of opinion started first by not getting emotional on the matter; which is easier said than done by individuals that make their livelihood developing software. Code generators and drag-n-drop utilities can be viewed as a replacement to the software developer of the day. The popularity of Visual Basic is a testimate of such an opinion; VB is marketed as a tool for MBA's to develop software without the presence of software developers. My opinion began to change after I quit taking that personally.

Auto-generated code still has challenges, two of which are maintainability and performance.

One of the first major criticisms of auto-generated code is that the code is unmaintainable. Code generators typically take a model representation, generate a language-specific representation of the model which is then presented to a compiler. It takes little time to form an opinion of the maintainability of this source code if you've ever glanced at the auto-generated C source from many code generators. While the syntax and semantics are valid, they can easily be a contendor for The International Obfuscated C Code Contest http://www.ioccc.org/. The variable naming conventions are cryptic enough to produce a slight migraine. The mere idea of modifying such source, even slightly readily produces a sense of panic. I began becoming less concerned about maintainability when I stopped focusing on the source code and more on the model. The source code is merely a bi-product of the model. Maintainability of the model is the issue, not maintainability of the source code. In actuality, the source code doesn't have to be understandable or maintainable for that matter. The model however has to be.

Performance is the strongest criticism of auto-gen'd code and brings out the strongest feelings in software developers. A quick examination of the generated source code can certainly prove that it can be more memory and cpu intensive than hand-tailored software. It would take little more than a second-year computer science major to produce more efficient code than most code generators. But to put it into perspective, I've witnessed some incredibly memory & cpu-intensive hand-tailored code by very experienced professionals. Wastefullness isn't unique to auto-generated code, or drag-n-drop programming; it is a product of rapid development. Given a relatively complex problem, and a desire to solve it quickly you tend to produce waste; period. Aggressive time constraints tend to lead you to the simplist and readily available solution. Generally speaking, the simplist solutions are typically greedy and therefore wasteful. Before you cry foul, remember what you gained...you gained a working solution in a short time period.

I've witnessed on two seperate occasions real-time, distributed, military systems prototyped in autogenerated code surpassing the re-engineered hand-tailored software developed by experienced, professional developers. The auto-generated code performed system missions faster consistently than the hand-tailored code and also performed more reliably as well. More importantly however is the fact that the auto-generated code was developed quicker and by a significantly smaller team (read that cheaper as well). To be fair however, this team was highly motivated, and were the recognized domain-experts.

Time to throw in the towel and use code generators exclusively? Hardly. I am not implying that code generators are the wave of the future. I'm only saying that you should look at it as another tool in your arsenal. Stop looking at software from a technologist's perspective and start looking at it from a business perspective. If your domain experts are fluent in code generators and less experienced in general-purpose programming languages, consider using the code generators. If your cpu/memory requirements can accomodate the overhead of autogenerated code and you believe that the development effort using code generators will be less than hand-tailoring at least give them a look.

Private Classes in C++

For all you object-oriented software developers using C++ out there I hope this post will be of interest.

Without getting into specifics; there are numerous occasions when an abstraction spans a single class and to preserve encapsulation you may choose to define a private class (an alternative to defining a friend class). I generally have chosen to embed the private class declaration exhaustively in the public class'es private region. Recently however I've encountered on a couple other options that I thought would be interesting to share.

Option 1
Let's start with the most straightforward method; embedding the private class in the public classes private region.

// -- file: SomeClass.h --
#ifndef SOMECLASS_H
#define SOMECLASS_H

class SomeClass {
public:
  SomeClass();
  virtual ~SomeClass();
protected:
private: //-- methods and private classes --
  class SomePrivateClass {
    public:
      SomePrivateClass();
      ~SomePrivateClass();
      void doSomethingInteresting();
    protected:
    private:
  };
  private: //-- attributes --
    SomePrivateClass myPrivates_;
};

#endif

// -- file: SomeClass.cpp --
#include "SomeClass.h"
#include <stdio.h>

SomeClass::SomeClass():myPrivates_() {
  myPrivates_.doSomethingInteresting();
}

SomeClass::~SomeClass() {
}

SomeClass::SomePrivateClass::SomePrivateClass() {
}

SomeClass::SomePrivateClass::~SomePrivateClass() {
}

void SomeClass::SomePrivateClass::doSomethingInteresting() {
  printf("(%s:%d) doing something interesting\n",__FILE__,__LINE__);
}

One of the disadvantages of this approach is that the header file becomes quite large to accommodate the multiple class definitions. Additionally, fully declaring the private class smack dab in the middle of the private region of the public class can easily give the reviewer/maintainer a headache. Indentation is pretty much your only indicator of what class you are currently looking at. Imagine your current page shows 3 method declarations (w/ documentation) you can easily lose track of what class the methods are associated with.

Option 2
The second option is similar to option 1 in that both class declarations are defined in the header, but note that the public classes instance of the private class is no longer contained by value but instead contained by reference. Since the private class declaration is not complete prior to declaring an instance of the class the size of the private class is unknown, therefore an instance cannot be defined. A pointer to an object however is allowed because a pointer is of fixed size (oftentimes the size of an integer). As you are probably aware, pointers are evil and the definition of an unmanaged pointer is even more evil. If you don't know why pointers are evil I'd highly recommend reading Marshall Cline's FAQ. I've defined a dumb pointer solely for ease of demonstration, I'd certainly recommend a managed pointer to avoid resource leaks.

// -- file: SomeClass.h --
#ifndef SOMECLASS_H
#define SOMECLASS_H

class SomeClass {
  public:
    SomeClass();
    virtual ~SomeClass();
  protected:
  private: //-- methods and private classes --
    class SomePrivateClass;
  private: //-- attributes --
    SomePrivateClass* myPrivates_;
};

class SomeClass::SomePrivateClass {
  public:
    SomePrivateClass();
    ~SomePrivateClass();
    void doSomethingInteresting();
  protected:
  private:
};

#endif

// -- file: SomeClass.cpp --
#include "SomeClass.h"
#include <stdio.h>

SomeClass::SomeClass():myPrivates_(new SomePrivateClass()) {
  myPrivates_->doSomethingInteresting();
}

SomeClass::~SomeClass() {
}

SomeClass::SomePrivateClass::SomePrivateClass() {
}

SomeClass::SomePrivateClass::~SomePrivateClass() {
}

void SomeClass::SomePrivateClass::doSomethingInteresting() {
  printf("(%s:%d) doing something interesting\n",__FILE__,__LINE__);
}

While this option eases navigation of what class you are currently looking at it still suffers from a potentially large header file. Additionally, since the private class declarations are located in the header file, changes to the private class due to implemenation changes will result in header compile-time dependencies.

Option 3
This option is similar to option 2 except the private class is fully declared and defined in the cpp file; seperating the implementation from the public interface.
This is formally known as the Pimpl Principle.

// -- file: SomeClass.h --
#ifndef SOMECLASS_H
#define SOMECLASS_H

 class SomeClass {
      public:
          SomeClass();
          virtual ~SomeClass();
      protected:
      private: //-- methods and private classes --
          class SomePrivateClass;
      private: //-- attributes --
          SomePrivateClass* myPrivates_;
 };

#endif

// -- file: SomeClass.h --
#ifndef SOMECLASS_H
#define SOMECLASS_H

 class SomeClass {
  public:
          SomeClass();
          virtual ~SomeClass();
  protected:
  private: //-- methods and private classes --
          class SomePrivateClass;
  private: //-- attributes --
  SomePrivateClass* myPrivates_;
 };

#endif

// -- file: SomeClass.cpp --
#include "SomeClass.h"
#include <stdio.h>

 // note the definition of private class prior to declaration of
 //  instance of class
 class SomeClass::SomePrivateClass {
   public:
          SomePrivateClass();
          ~SomePrivateClass();
          void doSomethingInteresting();
      protected:
      private:
 };

SomeClass::SomeClass():myPrivates_(new SomePrivateClass()) {
  myPrivates_->doSomethingInteresting();
}

SomeClass::~SomeClass() {
}


// private class definitions
SomeClass::SomePrivateClass::SomePrivateClass() {
}

SomeClass::SomePrivateClass::~SomePrivateClass() {
}

void SomeClass::SomePrivateClass::doSomethingInteresting() {
    printf("(%s:%d) doing something interesting\n",__FILE__,__LINE__);
}

I don't know if I strongly recommend any of these methods as of yet. I've currently discovered the latter two options and am slowly forming opinions on them. Regardless of my preferences it's nice to have options.

Top 5 Technologies That Have Changed My Life

There are no shortages of technologies these days, few of them I could live without; these, I could not live without major inconveniences.

5) Internet
Perhaps a clique...but truth be told, the Internet has changed my life significantly. God bless Al Gore :) Whether at work investigating the proper usage of a STL container, researching competitor products specifics, or just general leisurely browsing for stupid humor tricks. Couple the WWW with a wireless 802.11 connection and an available laptop and you've got yourself a party.

4) Text Messaging
Sure, cell phones change may peoples lives. You can be reached at anytime, anyplace; which brings up all kinds of edicate issues. Sure, cellphones are nice...but what I really love is text messaging. Properly used, you never really have to speak to your wife, nor she to you. Besides, what else can you do during your hours of training or meetings.

3) Tivo
While the remote resembles a phallic symbol; once you get past that you'll learn to love your Tivo. What other product comes with a window sticker that you can proudly display on your car window? Once you've spent some time defining your wishlist and programs you'd like recorded as well as defined the priority of each recording, you're all set. My wife and I must have a couple dozen programs defined in our season pass manager and each night we come home we've got a selection of programs to watch....and can fastforward thorough those pesky commercials. I'd be willing to bet that we even watch less television since we've got our little cable-buddy. We no longer spend time watching shows just 'cause they are on, now we only watch those programs that are really worth watching. An hour program takes ~45 minutes to watch, a 1/2 hour take ~20 minutes; end result is more entertainment in less time.


2) Wikipedia
Rarely has a day gone by when a passing conversation or lunch topic does not result in a peaked curiosity. In the days of yourn, one would normally consider digging out the Brittanica for a full 7 seconds, shrug it off and just go about your day...never to know who "Aqua Lad" was. Fast forward to today and a similar question takes less than 7 seconds to retrieve the answer (or at least someones rendition of the answer) from this God-given website.


1) Google
Last but not least, you have to admit that Google has changed your life if you spend any time rattling on a keyboard. Few other products of our generation warrant it's name morphing into a formal verb. Sure, Yahoo was my search engine of choice during the college years (along with AltaVista), but today Google is first choice in the web searching realm.

That's it boys and girls. My top 5 technologies that have made a significant change to my life.