Michael Riddle’s Thoughts

One of my favorite science-fiction authors, Robert Heinlein, wrote a book, The Moon is a Harsh Mistress, that concerns an artificial intelligence assisting in a revolution. In the book, characters use the acronym TANSTAAFL for “There ain’t no such thing as a free lunch”. The point being made was that you always pay for what you get, regardless of how it is buried in the presentation.

I grew up with constant reminders to beware double-edged swords: Tools that help us often turn and bite us if we are not careful how we use them.

Before I get back on my messaging hobby-horse, I’d like to consider some thoughts about our tools. I’ve already mentioned that I’m not too fond of interpreters or the thinking that “better hardware will make code cleanliness or efficiency unimportant” - I’d like to be the one to decide where I spend the power newer machines bring: new applications, better dynamic interactions, or the possibilities I’ve not yet thought of, and I do not want to be protected from myself.

One of my pet peeves is how poorly people understand floating point. Machines have become fast enough that there is no need to avoid its use, and we give lip service to dealing with rounding errors and the dislike of 2.00000000016 displays, but how many of us take the time to really understand it? In the dim dark prehistory before graphics, I tried my hand at compiler writing, which was not hard, but writing the run-time libraries was. I had to write an efficient software floating-point library, and later, when the 8087 introduced hardware floating-point to my world, make the compiler seamlessly use either. I’d recommend that anyone who writes code using floating-point read What Every Computer Scientist Should Know About Floating-Point Arithmetic.

Another pet peeve is making measurements with tools we do not take the time to understand. A common profiling technique is to take a statistical sample - what part of my code is being executed every so many msec? This is not a surgical tool - it tells you in which direction you should be looking. Times obtained this way do not include operating system functions, so a graphical function implemented outside WIN32 may take 4x as long as one using WIN32, but when you actually check, including time inside the WIN32 call, it might take half the total time. Moral: Be sure of what you are actually measuring.

Using a high-resolution timer is better, but you’d better average a few thousand tests, because Windows is a preemptive system. Michael Abrash’s book, Graphics Programming Black Book gives a lot of practical examples of measurement-driven design, although the hardware he discusses is now out of date. You also might want to download his Ramblings in Realtime. He has consistently shared his insights on thinking clearly about design.

The other tool that needs understanding is just what our compilers do with our code, and that means understanding assembler. I wrote our company’s FastCAD product entirely in x86 assembler. I actually started with the old Selector:offset horror, which I recommend everyone ignore as an historical bubonic plague. Once the 80386 and WIN32 supported the “flat memory model”, assembler became an order of magnitude (or more) easier.

I don’t recommend that you write programs in assembler. Modern compilers are efficient enough to please even me, and I no longer create in assembler. But the insight it gives me helps almost every day. It lets me judge the cost of various techniques used in C++. I learned that switch statements are no longer awful, since they are now implemented in optimized release code as a very efficient binary search. In fact, the more different cases, the more efficient such a test is. I learned that multiple inheritance is a real horror and can kill efficiency, and also lead to issues of functional duplication that can hide bugs.

I’d like to recommend the book, Write Great Code, Volume 2, by Randall Hyde. It gives a gentle introduction and walks you through both PPC and x86 compiler code generation. It may well surprise you and help you get better performance from your code, not because you will make minor changes for efficiency’s sake, but because being able to “think small” while “designing big” will improve the design approach you take.

Another book I like, out of the thousands on C++ programming, is C++ for Game Programmers. This is a very pragmatic book, and its not about learning C++, it’s about using it. There is a 2nd edition by a different author, Michael DickHeiser, and they are different enough that I like having both of them. I have never programmed a game, but I read most game programming books, and subscribe to gamedeveloper magazine. These are the people who are really pushing the envelope, and there is a lot we can learn from them that will help us write any kind of interactive program.

Still another book I’d recommend is Raymond Chen’s The Old New Thing. I’ve just finished this, and found it very entertaining in the sense of “So thats why it had to suck!”. But on a much more useful level, understanding the reasons for so many of the WIN32 annoyances helped me understand the problems Window’s authors, and I, face in a deeper way, and occasionally, he gives some good code tips, such as the quick and dirty way to use Uniscribe to get rid of the “not in this font, you don’t” ugly boxes. I always thought there was no quick and simple way to use Uniscribe. This won’t take a lot of your time, and if even one of his points helps, it will be worth the money.

While I’m working on this week’s post, I thought I’d pass on a useful tip that I’ve not noticed used by other programmers I know. On my development machines I have two hard drives in the removable drive sleds - costs about $26 at Fry’s for the first one, and $13 or so for each drive-only sled.

Since smaller drives have gotten so cheap, I use one for each OS variant I have to test (about a dozen Windows and 6 or so Linux installs, as well as a DOS system (I still have customers using the DOS versions of our products). Much cheaper than having a lab full of machines. And the lab doesn’t get so hot. I’m able to use multiple machines for network development rather than tie them up on specific systems. The only exception is MAC OS-X development, but they’re such nice machines I don’t really mind - although I wish I could do the same for Leopard testing.

By using Acronis True Image, I can easily clone a drive in a few minutes - the fastest and easiest backup scheme I’ve tried. Gets around Outlook PST issues, and I can easily change states or try “forked” changes, without the Subversion overhead issues.

I have many programs that use various locking schemes, and I just put these and nothing else on a “quarantine” drive, so I’m not always having to plead with a vendor to refresh my license (think AutoCAD, SoftImage, etc.). Then my development machine images can change often, and when gunk piles up, its a simple matter to restore from a clean image, and just download the project code from Subversion, and I have a clean system much more quickly than doing things the hard way.

This scheme works best with SATA drives, which do not have master/slave jumpers to configure, so you can switch and duplicate to your hearts content - just be sure to physically label the drives to assist in their proper selection for use.

The closest thing I have encountered to Brook’s silver bullet is programming with asynchronous message-based design. I’m not the man to know who invented anything in terms of who should get the credit, but Alan Kay is the man who has most influenced me with his work in this area. Among many other things, he coined the term, “Object-Oriented Programming” and worked with the team that developed SmallTalk, a from-the-ground-up message-based system, and a modern implementation of it, Squeak. My favorite quote of his is this:

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them.”[reference]. An interesting article that explores his thinking is at Phil Windley’s Technometria.

The reason I chose to point out the above is that C++ does not really fit the bill by that definition. It is good and useful, and I use it as my basic tool. But it not only enforces early binding, it actually (due to the fragile base class problem) leads to prehistoric binding – binding to last year’s code. Note that he does not include inheritance in his definition.

What leads me to point this out is that the problems I tackle include the need to allow after-release integration of new plug-in modules. I have products that need to support many such extensions. This has become common in today’s world. The gotcha is that when I change my code and release a new version, and if I have made any changes to a class from which 3rd parties have derived their own classes, all of those plug-ins also need to be upgraded. That is a real headache for many people.

Another problem with the C++ implementation of OOP is that we tend to use it to build a rigid hierarchy of objects. If we have vehicles, and then cars, and then a Lexus, and we have code to turn a heater on or off, we’re good to go. Until we decide we need to heat the garage. Then it’s back to duplicating function. (See OOP Component-structure fragility).

Consider an alternative: modules that link up and can dynamically be brought into play during the execution, and changed around or replaced during execution. Delegation, callbacks, agents: all of those complications completely disappear. The goal is the elimination of glue code. In our unobtainable nirvana, we would be writing 100% application-specific code.

I’ve been doing object-oriented programming in assembler for 20 years now. I don’t need a specific language to be able to use a specific design approach. I do need discipline. I liked assembler because it was definitely an “enough rope” approach. I stopped using assembler because compilers finally got good enough to suit me. It was never a religion. The important point is this: It is more how we think about our design than about the choice of language we use to implement it.

What I find in using a message-based design is that I can have near-perfect data encapsulation and implementation hiding, fluid structure, and very late binding (linking). I also find that it greatly simplifies multi-threading and network coding. I implemented my message-based approach in C++ because I don’t like interpretive environments – I want my CPU cycles, thank you very much.

The other part of my lead-in was the word asynchronous. It’s what frees us of user-interface modal locks, like blocking dialog boxes. Here is an example: We have a file-name picking dialog box. We start it with a message, and we tell the dialog object the object with which it should communicate. When a file name is picked, or the dialog is canceled, a message is sent to that notification target object. Nothing really needs to be suspended, because the resulting message is what triggers the next step. If we use it to load images into an image cache object, implementing multiple selection does not require extra callbacks or other weirdness - the file name dialog simply sends several file name picked messages.

This seems simple, and it is, but it has enabling results. If we have a worker thread process, we use a thread control object, which queues work for the thread, starting it when there is a message in the queue, and stopping it when there are none. We write one of these classes. If we want to make some function run in a threaded mode, we only need to communicate with it via this threading queue object, and ensure data locking (only one thread can be changing data at a time). Not easy, but much better organized. If we don’t create such a queue object, but communicate directly, then we are working synchronously. Dynamic run time choice.

We want to distribute some of a heavy work load - send the message over a network. Our code already knows how to wait on the results due the the asynchronous messaging design. We don’t need to rework our code to network-enable it. A network is just a slower message pipe.

The kicker is that these techniques have been around for something like 30 years or more. The only reason I can think of to explain why they are not current accepted best practice is that you lose most of the benefit if you graft the approach on to an existing system. It needs to be designed in at the core foundation level.

A good way to understand messaging is to play with Squeak. You will likely not use it to do your “real” applications, but it will change how you think. Also, Apple’s OS-X preferred language is objective-C, a messaging-based system. The GCC suite supports objective C and is available for all platforms.

I consider a pencil and paper to be the strongest competitor I have. Why? Because it has incredible tool transparency. When I use it, I do not have to think about the tool. My mind remains on my thoughts. If I’m taking notes, I’m not thinking about dialog boxes, the “right” order to do things, icons, etc. I can write without looking. When I need to represent relationships, I can draw them. Free-form. When I talk about tool transparency, it is this ability to keep my thoughts on what I’m doing, rather than what I am using to do it, that I call tool transparency.

A pencil disappears. Of course, we tend to forget the steep learning curve: It took us a few years to go from crayons that would not stay inside the outlines to (hopefully) readable penmanship and clear sketching.

Apple is famous for it’s systems being usable. Now there are things that I find really mysterious. I almost took my first G5 back to the store because, as a Windows geek, I didn’t realize that you opened the CD-ROM drive with a keyboard key that suggests “up” to me. Clarity, like beauty, is in the eye of the beholder. What is obvious to one person is mud to another.

As an example, my wife uses a Mac for email. She is a sharp lady, and the other agents in her office looked to her for help with computers. But when there is a problem sending an email, it automatically sends her work to another folder. ie: one of the lines of text on the left side. She does not see these as folders, and since she did not put it there, she worries that it disappeared.

Now we can say the tri-pane presentation of most email clients is “obvious”, but its like that pencil - we forget the time we put in until such things became obvious. We can no longer remember what our technical world looks like to someone who does not love it for its own sake, but just wants to get a job done. Putting our clients first means making things work the way they think, not the way we’d like them to think.

One of the joys of working on software, as opposed to hardware, is that we can accommodate different viewpoints. But too often, we pick the easy way out, and accommodate viewpoints that closely match our own. In doing so, we take off the table the possibility of making good tools for a very large number of people.

Several years ago, Microsoft came under strong criticism and some ridicule for a program called “Bob”. This was like the office paper clip on steroids, and it did look pretty annoying. But at least they were trying to approach things from a different perspective, and make something that non-computer types might find usable. It might have been a success if they’d gotten some of the better game design and graphics-artists involved.

The point I’d like you to consider is: What can we do to make our products transparent to our clients? Lets not try to impress them with a 200-command, 100-icon, dialog based monster that will take them weeks to master. Lets make it looks so simple that its seems that there is nothing there - “Where’s the beef?”.

Reality wins. Every time. Theory is our name for how we hope it works. I used to keep a sign over my desk that read “When theory and reality collide, reality wins”. I used it to keep my focus on the reality that we create tools for other people to use.

We all like to think we’re open-minded. The problem is, we each see a lack of it in others, but seldom in ourselves. Now I think there are many reasons besides ignorance for this. One observation I have about myself, and many other experienced programmers, is that we consider ourselves more likely to be correct about technical issues that most everyone else to whom we talk. We don’t consider it ego – it’s our actual experience. The problem is: it’s only true for a very limited problem domain.

What we need is a way to suppress our conceptual immune system – our automatic reaction to defend any point of view to which we have “bought in”. This is especially likely to occur when we deal with others who have their defenses set at DefCon1. If we are talking to a non-technical manager who feels the need to maintain his authority, our objectivity becomes toast.

One reality we have all dealt with is that at the end of the day, we are the ones who have to make it work. In this sense, we are engineers. Reality matters. We’ve each learned the hard way that when presented with a bad design, we will be the ones to take the fall. So if, as Alan Cooper says, the “Inmates are Running the Asylum”, it’s because someone has to.

Now this book is probably the least pleasant book I have ever read, because Mr. Cooper’s persona for a programmer is a caricature of an antisocial nerd. But I read it, and I recommend it. Sometimes we need a dose of unpleasant medicine. That’s not to say that I agree with all, (or even most), of what he says, but that I think he has many points worth thinking about. Just ignore his return to the “waterfall” model, and imagine what happens if you put interaction design people inside the product design feedback loop.

The most essential part of making a negative-feedback system (in the engineering sense of the term) work, is the ability to accurately measure difference between the present and the desired state. If our programs are going to evolve in an organic sense, we must suppress our certainty, based on years of experience, with a willingness to listen to those who will use our programs on a daily basis.

Notice I mention the users – not the managers, sales people, marketing people, or others. They all have valuable contributions, if we will listen without judgment. But nothing can make a program succeed if the people using it don’t actually like it. These are the people who most often get left out of the design process.

I have two suggestions: Get some of your toughest clients and some of the least experienced ones, and discuss the design issues with them. I use a BBS for this, And I’ve found that customers willingly give their time if they feel you are actually listening. Then, get these people in an alpha-test loop (don’t wait for beta).

The second is to attend conferences that are not “new-product” or “new toys” in nature. Now I’ve been to a lot of these things, and eaten an awful lot of awful meals. But the one I keep returning to, year after year, is COFES – The Congress On The Future of Engineering Software. The joy of COFES is that there are so many really accomplished individuals, great thinkers, and people who honestly spend their mental lives “out of the box”, that there’s no more chance of not listening than there is of a child refusing to go to Disneyland.

I’ve been growing a new program. It could be a CAD program, it could be a project management program, it might be an idea facilitator. Actually its all of this and more. Its hard to put a label on it, because we’ve spent seven years thinking about how people work with CAD designs, and why CAD is so useless for that initial Eureka! moment and it’s “napkin-space” expression.

Categorizing a program is easy if it’s just another “me-to”. We all know and agree what it does. But if we go off into the wilderness and explore what kind of tools would be really useful, the result may not fit into existing categories. New thinking may yield new categories, and it usually takes more than one of something to see what about it makes it a category.

Joel Spolsky has written an excellent article on the time good projects take, Good Software Takes Ten Years. Get Used To It. He talks in his blog about the Chandler project, and how it has taken seven years so far. The observation that good software takes a long time has many examples - and the best ones always seem to involve innovative programs that really focus on user interaction and how users think about their work.

One of the most influential books I’ve ever read is Fredrick P. Brooks “The Mythical Man-Month”. While this book discusses the design and implementation of OS-360 back in the days of punch cards, it remains relevant today because it is much more about the nature and costs of communication within a design team. For over 25 years, I’ve asked every new employee of my company to read this book. The 20th-anniversary edition has four additional chapters, including the article, No Silver Bullet, which has inspired a lot of commentary. The book also includes his own re-evaluation of that article, discussing the prospects he sees for improvements in productivity.

After first reading the book, I decided to change how I went about making programs. I adopted an evolutionary approach of growing a program around a central skeleton. With this approach we always had a working program. We then mixed that with an engineer’s negative feedback loop: send copies to real-life clients and have them try to use it. Listen with an open mind, suppressing one’s conceptual immune system, and adapt the program. Repeat in as tight a cycle as possible.

Originally, sending floppy disks around the world resulted in a two or three week feedback loop. Things really took off with the internet, when we began almost-daily decision loops. To this day, this ability is what I most value about the internet - I can actively involve our clients in the design of the tools we are making.

Chapter 17, “”No Silver Bullet” Refired”, touches on this methodology. I’ve been using it for almost 30 years now, and it has enabled a very small team to make several generations of CAD programs that have satisfied our customer’s needs. One result of designing a program in this manner is that it requires radically less support - a major cost of a software product - since it was by the nature of the process designed to work the way our clients think about their work.

I’ve been thinking about software systems architecture for over 35 years now. I wrote one of the first microcomputer CAD programs, Interact, which was the prototype for the first version of AutoCAD. Since then, my company, Evolution Computing, has published both EasyCAD and FastCAD.

I intend to discuss issues in software architecture, program ease of use, what we can to to improve our productivity as programmers, and the effect we have on the world we live in. I’ve also spent many years working with the Open Design Alliance to further CAD interoperability, and have some thoughts on the causes and the political nature of interoperability problems.