31 January, 2007

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.

15 January, 2007

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.

14 January, 2007

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.

09 January, 2007

4 Books Every C++ Developer Should Have On His/Her Shelf

Over the years development languages change from project-to-project. A challenge for learning a language involves selection of what references are worthwhile. Far too often I've made poor selections in textbooks and selecting C++ references some years back was no exception.

I'd like to list the top 4 books that I've selected for my arsenal that I feel are essential to doing proper C++ (in no particular order):
1) The C++ Programming Language - Stroustrup
To understand C++, or any other language, you've gotta understand the language syntax and semantics. The rules...what's allowed and what is not. Who better to inform you of such things than the father of the programming language; nuff said.
2) C++ FAQs 2nd Edition - Marshall Cline
After you know the language syntax and semantics, the next thing you should be educated in is what should you do and what shouldn't you do. Marshall Cline identifies many of the pitfalls of common practices in an educational and surprisingly entertaining manner. I've attended a series of training sessions with the man himself and I highly recommend both the book and the courses if you can get someone else to pay for it :)
3) Effective C++ 3rd Edition - Scott Meyer
I'd consider this book to be the Bible with respect to best C++ programming practices. I cannot say enough good things about this book, but be forwarned...it expects you to understand the language to a fair degree. Don't buy this as your introduction to C++, buy this as a moderately experienced developer.
4) Effective STL - Scott Meyer
What is C++ without the STL.....the equivalent of a three-legged dog; never living up to the potential of a 4-legged dog. Come on, most interesting problem domains are complex enough to benefit from utilizing the STL including a great deal of embedded software products.

These are the books that I'd recommend to anyone developing in C++. I have a set of Sutter and Koenig books available to me and I've heard great things but since I haven't read them personally yet I cannot recommend them yet.

06 January, 2007

I am the Victim of a Drive-By Coding

I've been a software developer for the past 9 years for various defense organizations.

A common practice, in times of need, is to employ temporary assets in the form of contractor engineers. This practice has time and time again proven to aid in the development of programs that have an aggressive schedule and a budget to accomodate the extensive salaries for contractors.

The typical role of a contractor is that of being brought in at a time of need and after that need has been eliminated the contractor(s) are shortly let go. The loftly salaries of these contractors is justifyable when you consider that they are brought in and placed immediately on 'critical path', and the understanding that they will be eliminated shortly after they are no longer needed. I've worked with dozens of contractors over the years and my opinion of the majority of them is quite positive. Most of them are not what I'd consider to be extraordinarily talented; the majority of contractors are pretty average. This coming from a software engineer that rates himself...average. Besides, on average....people are average. The reason I even mention this is to disolve any delusion that contractors are extraordinarily efficient, knowledgeable or brilliant. No, most are just like you or I.

I notable observation that I've made over these years is a typical side effect of contracted work. Note that typical contractors are involved with a project for a matter of months. Most often, they come in at the preliminary or detailed design phase and are responsible for designing and coding of some defined task(s). Keeping the short duration of involvement in mind, a common side-effect of contractor work is minimal or non-existant documentation in detailed design or the implementation phases of development. I don't necessarily fault contractors for failing to document their design or code. Over the years of playing revolving doors with companies they are never around long enough to see the pain and suffering resulting from updating a design or code that contains no documentation. One of my most recent sorrows entailed reviewing a design for a radio component from a contractor engineer. The majority of the minimal documentation was of the nature of 'do good things here'. I suffered through a code review of this product, and after a numbing 16 hours of reviewing I was near tears. One method in particular spanned approximately 3 pages (or ~120 lines since hardcopy is dead). It took better than an hour studying some of the most complicated code on the planet I finally realized that the method was responsible for scheduling message delivery with a priority scheme where messages intended for a single destination are given priority to those messages intended for multiple destinations. How was I suppose to know of this scheme.....well, not from the non-existent comments, nor from the radio interface control document (the priority scheme wasn't dictated by the hardware)...no, the only way to become enlightened to this design was to read the code.....the hundreds of lines of code....the code that rivals in complexity that of the Apollo space program. Days from now this contractor will be gone and some sap will be responsible for his product. This sap has become me on more than one occasion and I suspect it will once again be me. I look forward to the days of being bombarded with questions about this software component, followed by hours of diving into the code producing the answer and returning for a fresh set of questions. Better yet, fielding the software component will undoubtedly identify errors which will involve hours and hours of unpaid overtime.

I'll end this post with another plea. For God's sake, document your damn code!!

05 January, 2007

A Love-Hate Relationship

I love my job...I really do. The software field is by-far one of the most exciting fields of our time. With a $500 PC, expertise in some area, motivation and dedication you can accomplish some extraordinary feats. A couple college drop-outs in a garage create an operating system that one day dominates the PC market. A kid with an idea for a centralized video repository later sells it for billions. Ideas that can be accomplished with software are near endless, they are not directly bound by physics like that of electrical engineering and mechanical engineering. I really love this field.

At the same time there are days that I am one step away from my co-workers finding me hanging from the rafters, lifeless...with a smile on my face signifying an end to the madness.

One of the present-day aggravations that steers me toward a noose and a chair is a newly hired contractor. I have to say that most often bringing in a new body to the team is exciting. They often times come with fresh experiences, a newly defined sense of drive, and often times technical expertise that is of interest. I have to say that I was exceptionally excited to work with this new guy. I helped conduct a phone interview with him and of all the candidates he was by far the most qualified. His responses to each interview question was spot-on, textbook responses. I was really looking forward to working with him.

The usual new guy dance entails a couple days of 20 questions, an assignment of a well-defined task for them; they finish the task, they may get another of increasing complexity, otherwise they are on their way. Our new guy however has two-right feet; he doesn't know the steps and is stuck in the 20-question loop. Touting his 20+ years of experience he is under the delusion that he was hired as a consultant. I do believe that I've been asked every possible question with two exceptions....why our hardware casings are green, and why we are using C++. I expect them to be raised within a week.

While I have no experience as a consultant, nor as a contractor I have not yet to meet a contractor that would not rather be a consultant. The difference? A contractor is a temporary replacement to a senior engineer, a consultant a temporary replacement to a system architect. Consultants are typically hired to look at the big picture of the system, making recommendations to assist in bettering the product. Education of, and enforcement of best practices is an example of a typical role for a consultant. Consultants are typically an authority on a given subject or domain. Hiring the likes of Scott Meyer or Marshal Cline to teach proper C++ best practices would be an example of a consultant. Contractors on the other hand are typically a temporary resource with more average skill sets. The typical contractors that I have been involved with are software engineers. I think of them as a coder for hire. If you ever wonder if you're a contractor or a consultant just take a peak at your paycheck. If you are bringing in ~$500/hr then chances are you are a consultant, if you're in the ~$100/hr range then your a contractor.

So, what does this have to do with our new guy? Well, he's been hired as a contractor and is playing consultant. Rather than focus on accomplishing his tasks at hand, he instead snoops around our entire source tree asking questions about everything and then expressing his 'opinion' on why it should have been done differently (sigh). He is currently just finished week 3 of his self-proclaimed 2 day task, the other 13 days entail a good deal of 'why did you do it like this....why didn't you do it like that'. Worst yet, he's slowed down everyone else with his unproductive questions.

I'll finish my rant with a plea. For those of you that are contractors, hired as contractors but want to consult....either sit-down, shut-up and do your current job, or seek out a consulting opportunity elsewhere.

04 January, 2007

Who Is The Fat, Slow Kid

Why am I the Fat, Slow Kid?

Well, I'm shaped more like a Weeble than that of an Olympic swimmer. And while I am not exactly 'slow', I'm not necessarily the sharpest pencil in the pencil box.

As a profession, I am a software engineer having attained an undergrad and graduate degree in Computer Science and have been a software engineer going on 9 years now.

I anticipate the majority of my posts will entail various rantings and ravings concerning software development as a profession and technologies that I find of interest.