Minnesota Bound

I am currently en route from Orlando, FL on my way back from an SPIE conference where a colleague authored and presented a paper. I tagged along as a result of my co-author status.....senor' coat-tails has been the title that comes to mind.

A number of interesting topics were presented, primarily concerned with wireless communications and fields of study concerning sensors. An observation worth noting was the evident differences in the disciplines of the presenters and how it affected the detail of the topic and the presentation style.

As I've said in the past, I am a software engineer by trade, having a BS and MS degree in Computer Science. Both school and industry alike, I've been surrounded by individuals both in Comp Sci as well as other engineering disciplines such as physics, electrical as well as mechanical engineering and the differences in the disciplines are very evident.

As much as a person wishes not to admit it....computer science is still a 'soft' science. Sure, it is far more disciplined than the likes of some other engineering persuasions, but is still far less structured as the likes of pure mathematics, physics, optics, electrical or mechanical engineering. The majority of the presentations were conducted by doctorates of physics, electrical or optical engineering, but every once in a while you'd get a computer science major up there and the presentation took a different tone. The best way I can say it is that the logic was softer or more fuzzy. Most presentations from more formal disciplines would be followed with mathematical description of the technology. Computer science presentations rarely had such formality, with the occasional exception to a presenter that had an undergrad degree in a more disciplined major and a PhD in computer science.

Am I knocking Comp Sci...to a degree I am doing just that. With the minor exception to those that pursue theoretical computer science focuses which are more in line with formal mathematics the majority of us still groan in the presence of a formal proof, a detailed description of the fundamental technology in the only pure language...mathematics. As a result, I think we give up the things that could make our discipline more successful. I can, for one, say that if we took a more structured look at proving techniques on paper rather than jump in and start coding we may have less error-prone technologies.

I'm not touting that we should all begin doing formal proofs on the effectiveness and efficiency of our authored algorithms. Instead, I'm saying that perhaps it's worth a 1/2 a day investigation on paper before firing up your trusty editor out of the gate.

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.

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.

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

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.