nerd1951.com

In a previous post, Back to the Future,  I was bemoaning the state of software design in industry today.  I received a very thorough and thoughtful reply by a colleague who I respect greatly but did not feel comfortable posting to a public forum.

One of my complaints was that even when we use object oriented design, realtime software is rarely written using an object oriented programming language such as C++ or Java.  Nearly all realtime and embedded systems software is written in C.  My colleague pointed out:

“Tools vs. concepts” :: (DISCLAIMER) A FAVORITE RAILING CONCEPT OF MINE…  Just because one is using C++, Java or one of the more esoteric languages to IMPLEMENT a system, doesn’t mean that one has used “Object Oriented” concepts in designing the system, perhaps that is an echo back of what you are saying… similarly, just because one is using C &/+ assembler to implement a system doesn’t mean that one DID NOT use object oriented concepts/design/etc. IN IMPLEMENTING THE SYSTEM!!! Having hailed from roots writing code for missiles in the late seventies/early-eighties and graduating to game programming in the mid-eighties, I can tell you first-hand that some of the best designers I’ve ever worked with wrote their code STRICTLY/ENTIRELY in assembler… regardless of the manner in which they arrived at how things should work/behave.  And some of those folks were damn’d prescient with regard to what really made sense… polymorphism wasn’t lost on the really good game designers.

My software roots go back to writing Z80 and PDP11 assembly for networking equipment and I realize that we were using virtual functions and polymorphism in our state machines but just didn’t have that vocabulary.  Good design concepts are just good design concepts.

You can see it in the Linux Networking code.  The Network Device interface uses function pointers in a way that is much like using virtual functions in C++.  Likewise the device interface implements an event notification function that is amazingly similar to the Observer Pattern in Design Patterns: Elements of Reusable Object-Oriented Software by Gamma et. al.

So, using a procedural language like C is not a good excuse for not doing design, even though all the software design books in the library are about object oriented design.

I mentioned in a previous post that living car-free for a year is my own special form of insanity or at least on of them. Well it turns out that I’m not the only crazy who is doing this. NPR recently had a report Los Angeles Living, Without a Car. They interviewed Chris Balish who not only lives car-free in Los Angeles but also wrote a book about living without a car: How to Live Well Without Owning a Car: Save Money, Breathe Easier, and Get More Mileage Out of Life.

“Let someone else do the hard part.”  Software Tools (1976)

One of my pet peeves is that otherwise smart engineers in telecommunications don’t know how to write a specification for a piece of networking equipment.  As a software engineer developing network elements, fleshing out the specifications is sometimes the most important part of the job.  The hardest parts, the most important parts and the parts that we always seem to mess up are the configuration options and the performance statistics.

What I find so frustrating about this is that the hard part’s been done already.  Unless you are working on something radically new like faster-than-light transmission technology, a group of very experienced very bright people have already worked for months writing specifications for this stuff.  Most of the time the specifications are even free.  They are called RFCs and usually have a title like “Specification of a Management Information Base for …..”

I know that these specifications often seem like overkill.  Sometimes they are overkill but if you build your product to support the options specified in a standard MIB you have a very good chance of getting it right.  Even better is that you only need to put one line in your specification document: “The product shall support the configuration options and performance statistics as specified in RFCxxxx.”

The MIB might be a little more formal than you would like or gather more statistics than you feel is necessary.  On the other hand you’ll be a lot less likely to find yourself adding a configuration option to your product at three o’clock in the morning so you can ship a prototype to a carrier’s conformance lab.  As Brian Kernighan noted: “Let someone else do the hard part.”

I have three new books sitting on my desk and it’s killing me that I don’t have the time to just sit down and read them.  I usually catch up on my reading on the bus but lately I’ve been alternating between the bus and riding my bicycle to work which cuts into my reading time.  I’m experimenting with living car-free for a year - don’t ask, it’s my own special form of insanity.

But back to the books.  First in the queue is Modern C++ Design: Generic Programming and Design Patterns Applied.  I originally picked up this book because I liked the Small-Object Allocator in Chapter 4.  Upon skimming the rest of the book, I was impressed that the book included an Appendix on multi-threading.  Modern C++ Design looks like an excellent source of ideas for implementing design patterns in C++.

The second book I picked up is Linux Network Architecture.  So much has changed since Stevens gave us a tour of the BSD protocol stack in The Implementation (TCP/IP Illustrated, Volume 2).  The Linux Networking Architecture is a good follow up to Stevens, describing the architecture at a useful level and not just regurgitating the source code.

Some reviewers have complained that the translation of this book from German was poorly done and made the book difficult to follow.  I did find some of the wording awkward at first but as I read the book either I got use to the phrasing or the translation got better.

Finally there is Network Algorithmics,: An Interdisciplinary Approach to Designing Fast Networked Devices (The Morgan Kaufmann Series in Networking).  This book is unique in its holistic approach to hardware and software optimization for fast networking.  Its other outstanding feature is that it discusses the differing requirements of routers and end nodes such as Web servers.

And, at some point I want to read some fiction!