Phil Hord: Distinguished Developer, Award-Winning Innovator, Entrepreneur

This week, Stephen Ibaraki, I.S.P., has an exclusive interview with Phil Hord.  

Phil is an award winning, widely regarded developer with a 20-year history in software engineering. He is well respected for his in-depth knowledge, commitment to quality and service to the developer community and to technology users.

Phil has a BSc in computer science from Florida State University. He is a Certified Master C/C++ and Windows programmer having outscored 99.7% of all C++ testers in the US.

Discussion:

Q: Phil, by earned reputation, you are widely regarded as one of the top developers. Thank you for taking the time to do this interview.

A: Thank you, and you’re welcome.  I work with a lot of other “top developers” so I really feel challenged on a daily basis.  I often feel outclassed by the work I see from others.  I really have benefited from strong peer environments.  There’s a lot of respect among senior engineers in most places, and a lot of support as well.

Q: What sparked your interest in computing initially? Can you describe your most memorable experiences at Gulf Coast College and then at Florida State?

A:  When I was a kid in school, computers were rare.  The first personal computers came out in the late 70’s. Cheap calculators have more power than those original boxes. In the 6th grade I was in an experiments class in school that had a computer.  Most of the time it sat at a “Ready>” prompt or running games that other kids loaded from cassette tape.

One day when I walked in, it was busy flashing a message onscreen.  It said “Brent Pristas is a programming god” or something like that, and it had an animated box drawn around it.  It took about 10 lines of BASIC code, but it was far beyond my simple means.  I asked Brent, a 7th-grader, how he “made the computer do that.”  He shrugged and said something about “4 loops”, and then he listed the program.  I was in awe.

My dad bought a computer for his office.  I don’t know if it was really useful there, but he used to bring it home on weekends.  I didn’t do anything else on weekends after that.  I taught myself to code and then I taught my dad.  It was a great hobby and it was all-consuming.  It was several years later before I found out I could get paid for it.

By the time I got to college, there was nothing I needed to learn.  Or so I thought.  I did learn plenty about the areas of computing that had eluded my interest thus far, like mainframes, (primitive) networking, terminals, microcode, and so on. I did pick up some stuff in data structures, statistics and finite automata. The really good stuff didn’t happen until grad school, where I learned about computability, operating systems, and some new thing called “C++”.

Most of this stuff just “made sense” to me since I had spent most of my life, by then, exploring the inner workings of computers. But there were two instances where the real world crept in.  The first was the ACM computing challenge.  We formed a four-person team and went to compete against other college teams in a sort of a “computer brain bowl” of problem solving.  We finished somewhere in the middle of the pack, with a respectable three out of seven problems solved.  But it was really the first time I had written code under unrealistic deadlines.  I didn’t think much of it then, but it turns out that’s how most code is written in the industry, so it really prepared me for professional life.

The other instance was a class, poorly organized and not very technical, where we all worked together on a class project for the school.  We had a customer, we had assigned roles, and we had deadlines.  What we didn’t have was a clue.  But this class showed me, (and the others, I guess), how it was to work with and rely on people who didn’t really do their jobs.  It was a bit like living in Dilbert-land, but it was 6 years before Dilbert was born.  As much as I hated it, this prepared me for professional life much more than any of my technical classes.

Q: Having worked with BASIC early in your career, then dBASE and Clipper, what were your experiences with these languages and what lessons still hold true today?

A: Those are some ancient languages.  They were useful in their time, and it was exciting to live through their evolution.  But today they’re as useless as rotary dial telephones.

I learned a lot about optimization in those languages, and finding more than one way to solve a problem.  The biggest lesson I learned from all these languages is to seek elegance.  I have found over the years that when I write code to solve a problem, if the code lacks simplicity and elegance, then I probably designed it wrong.  Imagine a Rube Goldberg machine, (if you remember those things), where there’s a long complicated process involved to perform some simple action, like lighting a candle.  There are so many “special cases” and unnecessary steps in the process that it’s bound to fail.  Having many potential “points of failure” in a process is an invitation for disaster.

Q: You moved into more C and C++ development in the early 90’s. Share examples of some early projects and your thoughts on these languages then and today.

A: I taught myself C and later C++.  At the university at the time, there were no classes for these languages.  And languages are mostly the same anyway.  It’s just a matter of learning a different syntax and a different philosophy, sometimes.

But I’ve found that you really can’t learn a language until you’ve developed a project in it.  You can read about it and study it all you want, but until you are forced to make it compile, do what you want, and then debug it, you really don’t have a good grasp of it.

It’s frighteningly easy to write bad code in any language.  C and C++ offer power and flexibility.  The big job for a developer occurs in design.  It helps to know the language well before designing the project, but writing the code is often the (relatively) easy part.

I didn’t want to write a “real” program as my first attempt at learning a language.  So I invented a game – an idea I stole from Nintendo, actually – and started writing it in C.  The last 20% of the code seems to take about 80% of the project time. That’s where I really learned the details of C, and in this case, the Windows API.

I got some acclaim for this game around the office and pretty soon people were clamoring for “scoring” and new levels and such.  But by then I wanted to learn C++, so I started all over from scratch.  I changed the architecture, created C++ objects to hold the various game pieces and so on.  And again, I learned all the best lessons of C++ by being forced into corners to solve the minutest problems. 

At my job in the early 90’s we programmed almost exclusively in 8086 Assembly language, the “machine language” code of the CPU.  My project for several months had been to translate a high-level front-end from an expressive scripting language into the barren language of Assembly.  I had not used C++ at all at this point, but I had read about this “object-oriented” programming idea that was catching on.  I understood how it worked and I wound up using it in my Assembly language structures.  To a modern programmer, that probably doesn’t sound unusual, but at the time, figuring out how to dissect a concept like OOP and code it in terse assembly-language on a PC was unheard of.

I don’t think anyone in the office really understood what I was doing at the time.  But when it came time to implement all the actual front-end features on top of this back-end framework, everything fell into place quickly and easily.  Almost all of it worked the first time it was in place.  The QA guy even came by to compliment me on it.  But more importantly to me, when I got around to exploring C++ as a language, I already had an understanding of how it all worked from the inside.

This is an important concept. I find that people who understand computers from the high-level language all the way down to the electrical signals on the circuit boards have a far easier time with computers.  People who don’t have this deep understanding seem always to be making elementary mistakes, writing suboptimal code, or setting off on bad designs.  I rarely use my knowledge of the internals of computers directly in my work.  But having it makes it seemingly easy to predict what a computer can do, should do, and will do. 

So, one of the primary things I look for in a job candidate is an innate understanding of the internals of computers and languages.  If it is not there, neither is the job offer.

Q: You have worked extensively in communications-related projects. Describe your key projects and how they have impacted your knowledge set.

A: Communications protocols always seemed very basic to me.  They still do, though some of them are extraordinarily complicated.  Essentially, they’re all the same: they just send data back and forth in some controlled manner.

The “controlled manner” part is the protocol.  And it seemed to me that we should just pick one and go with it, instead of being forced to work with so many different ones.  But no protocol ever fits all needs.  We needed one for 8-bit data on modems, a different one for “legacy” networks, handshaking for fax transmission, store-and-forward message handling for email, management-data protocols for equipment monitoring and control, custom protocols for proprietary hardware, and so on. So I frequently wound up designing a new protocol, coding one to an existing standard, or working with a hardware engineer to meet his protocol needs.

I wanted to get the intricacies of protocol code out of the way so I could get to the real coding.  But I always found that there was another protocol to write, as if someone should have done this already and hadn’t.  After a while, I realized I was writing a lot of communication code to support other projects.  I also realized I was good at it.

Protocol design is far more complicated than I originally imagined.  There are so many issues a protocol might have to deal with.  It makes a fascinating puzzle.  Crafting an efficient and robust communications protocol for a particular need is such an intricate process that it is akin to writing an entire computer application.  In fact, most modern protocols rely on several layers of protocols beneath them, much like modern languages rely on machine language and microcode beneath them. Working with them has led me to a greater understanding of the underpinnings of the network, like writing software led me to a greater understanding of the computer.

Q: You have worked on many interesting projects as President of Phord Software including writing award-winning utilities for the Windows environment. Detail your top systems. What lessons can you pass onto other developers?

A: I’m not sure how to classify my “top” systems.  All of the projects Phord Software develops are tools that fill an immediate need.  Shove-it, for example, was supposed to be a temporary “bug fix” for Windows 95.  The problem it fixed still exists today in Windows XP and Server 2003.  I’m sure it will be there in the next release of Windows too.

KeyBlock was a solution to the Ctrl-Alt-Delete “problem”.  You can’t trap Ctrl-Alt-Delete in a Windows application because it’s supposed to be like dialing 9-1-1.  It should always work.  But people who put their computers out for public use often need to exercise a bit more control over the machine.  KeyBlock fills that need by disabling system keys, including Ctrl-Alt-Delete.  I was surprised how successful KeyBlock was.  These days I even have some competition.

One of my most profitable (in terms of hourly wage) projects has been www.shove-it.com (not actually related to Shove-it, the program).  It’s a horribly inept web site that I accidentally created that fills a dire need.  It does that so successfully that it now requires a dedicated server simply to keep up with the website traffic from daily visitors -- in spite of my complete lack of attention to it or advertising for it.

Lessons to share:

1. If you don’t know how something works (and it’s your job to fix it), take the time to find out exactly how it is designed.  The correct solution to the problem will only come from a good understanding of its source.  Far too many bugs exist because someone “fixed” something without knowing what they were doing.



2. Someone once gave me a bit of advice on contract rates and salaries (granted, in the 1990’s).  He said, “Before you go in to meet the prospective client, think of the biggest number you can say out loud without laughing. That is your rate.” And further, “over time, you’ll find that this number gets bigger.”  I offer this because it was useful to me for this reason:  I so enjoy the work that I do that I forget that people are willing to pay me for it.  Consequently I undervalue my time.  I think any job that you enjoy will suffer the same problem.



3. First corollary to lesson number 2, in lean times you may have to take your “subsistence” number instead of your “straight-face” number.



4. Second corollary to lesson number 2, find a job that you enjoy so much that the salary is an afterthought.



5. Learn by doing.  I don’t think real lessons are learned from reading or studying.  If you want to learn a new operating system, program, language or tool, pick out a project to build with it and then go build it.  Finish it.  Completely. Then you’ll know.



6. Explore new technology but don’t worship it.  Before you rely on it, wait a while for the bugs to get worked out.  In the meantime, play with it.



7. Find a need and fill it. 



8. Live life unashamed.  Be embarrassingly honest at all times.

Q: Amongst the various development languages, tools, resources, and frameworks, which are your favorites and for what reasons?

A: I don’t think I have any favorites anymore.  I used to, but now I only have “currents”.  That is, whatever I’m working in currently is what I know and love.  I’ve been working on Unix systems for a few years now.  And I’ve been working on embedded controllers where the resources are extremely limited.  I’m not a fan of the programming environment on either system, but I’ve learned from each of them.

Having said that however, I’m a big fan of some systems.  I like PHP for web development, because it’s easy to write readable code in PHP.  I like Perl for its flexibility, but it’s so easy to write illegible Perl code that doing so intentionally has become one of its most basic tenets. 

I really like the C++ Standard Template Library (STL).  The design and consistency of this framework is impressive.  The time it saves, (when I can use it), is wonderful.

Q: It’s hard to predict the evolution of program/system development however with your wide and proven background of innumerable successes; we would appreciate your thoughts in this area. Describe program/system development in five and ten years.

A: Sadly, I don’t think it will change much.  If you think about where we were 10 years ago, it seems we do many of the same things today.  C++ is a bit stronger today, but it was in fairly wide use 10 years ago.  For a while there was more focus on maintainability and defect tracking in the industry, but then the bubble burst in about March 2001 and everyone learned to “get lean” again.  Defect tracking is making a comeback as we try to manage development more like a science and less like an art.  I hope that the future will integrate it more into our development cycles.

Java and other “simpler” languages will allow more people to write code that doesn’t crash.  But it also will let more people write code without really understanding the system.  That is a good thing in many ways.  But it means the software industry will continue to have the image that its product is unreliable.

Exponential processor speeds and storage capabilities will even make us even lazier about optimization.  So those mediocre programmers with C-sharp and Java in their hands will be able to produce useful tools anyway.

There’s a lot of bleeding edge development in internet technologies, and open-source efforts have kept that alive.  Linux will someday make a serious play for end-user desktops, but they will have the same battle to fight as Apple and with less money.

Q: Which technology areas excite you the most and for what reasons?

A:

1. VOIP: I was the designated “computer-telephony technology guru” at Hayes for several years while “voice over IP” was being born.  Now, 7 years later, it has finally reached the masses.  I guess that’s par for the course.  I’ve been using a VOIP phone (from Vonage) exclusively for 18 months now.  It hasn’t been problem-free, but the trouble I had was related to my internet provider.  These days, my broadband pipe is so fat and clear that nothing bothers my VOIP connections anymore.
   
   The phone companies can’t seem to do anything right without the protection of monopoly-status.  It’s about time that someone came along and showed them up.  When I moved recently, I considered getting a landline phone again.  But the cost was 5 times more than my VOIP connection and the features were fewer.
   
   I love my VOIP.  I get my voicemails in my email, my calls are all free, and I can take my phone with me on trips. 
   
   Also in the mass-market category is Tivo. Tivo is the first computer my wife could use right away from day one.  It’s ironic that it was a Linux computer. I can’t adequately explain Tivo to a non-Tivo owner and I need not to anyone else.



2. Nanotechnology: This field is still highly experimental, but it holds exciting promise.  For me, its future is still too far off to be clear, but I’ll bet it will be used in ways that are unimagined today.  From a programmer’s standpoint this would be most interesting to work on if I could somehow model and build the machines logically.  The really cool work here is being done in labs by mechanical engineering folks today.  But there’s no telling where it can go once we’re able to put some intelligence into microscopic machines.



3. RSS: Blogs are the new media.  In these early days there are plenty of crackpots and also-rans, but ultimately the dissemination of information will more commonly flow over something like RSS than anything else. It has a built-in immunity to spam, a natural popularity/relationship mechanism, and it is supremely democratizing.  It will be belittled for a while longer, but in a few years, we will wonder what we did without it.



4. Virtual machines: These are programs that let your computer pretend to be a different kind of computer.  Java does this, and MAME, the Multi Arcade Machine Emulator. 
   
   I really have never been a big fan of Java.  The VM idea is inherently flawed in that it immediately wastes a non-trivial portion of your resources.  But the flaw is being mitigated as the technology progresses by talented people who are always shrinking that last bit of loss out of the system.  I think it may actually be reaching the point soon where the VM will always be running and applications will be able to use it as if it truly was part of the hardware.  I don’t know if it will be a VM for Java, C-sharp, or some other abstraction.  But the prospects for software are very interesting.



5. Computer-enhanced molecular biology.  If I were going to change careers tomorrow, I would want to work in a research lab that focused on using computers to help analyze and model microbial machines.  I think we are just a couple of years away from being able to do near-instantaneous DNA sequencing, and a few years more from being able to do large-scale DNA database comparisons to identity traits, flaws, species, and so on.  I’ve always felt that not enough was being done in this area and it would be exciting to work on.  I have heard reports recently that make it sound like plenty of others thought the same thing.  I think we’re getting close.
   
   Also we’re starting to engineer biological viruses.  This technique has the capacity to destroy us all, but it also has the potential to cure cancer, AIDS, and nearly every other systemic affliction known to man.  I hope its potential for good use is realized before its potential for harmful use is.  But I don’t think, for example, that prohibiting research by the “good guys” will prevent it from being used against us in the future.



6. Molecular computing:  If you think about it, DNA, the stuff which we are all made of, is really a huge computer program.  Granted it’s just the microkernel stuff; it doesn’t control everything.  But it is an amazing technology.  We are starting to use this to design our own computer systems.  But this has nothing to do with biology or life creation.  It has everything to do with speed and efficiency, instead.  But on the downside, it renders every known key-based encryption method to date utterly useless.
   
   I don’t think DNA computers will be commonplace in the home in our lifetimes.  But that’s the funny thing about technological acceleration: it’s recursive, and so it is unimaginably impossible to predict the future beyond just a few decades.

Q: Here is where we turn it around. Pick three topic areas of your choosing and provide commentary.

A: These are pretty diverse topics.  Thanks for leaving the floor so completely open.

Area 1: Debuggers

I used to work for guy named Bruce who never used a debugger.  When he searched for a bug, he simply went to the source code and read it, stepping through it in his mind and trying to imagine what might go wrong.  I thought he was pretty foolish because, like any good programmer, I never trusted any code I had written until I saw it run, instruction-by-instruction, in the debugger. 

Our debuggers were pretty limited back then, but sometimes the debugger today is even more limited, depending on the environment.  I have so many debuggers now for different platforms that I don’t get to know any of them very well.

These days, however, I find that I don’t have to know the debugger well.  I have reached the point where computer languages are like natural languages to me.  I can read them, I can write them, and they make sense.  If I design the system right, they even make logical sense.  So when there’s a problem I find myself reading the source code, just like Bruce did, line by line, imagining what might go wrong.

I can’t recommend this technique for everyone.  Certainly a good debugger is an essential tool.  But I find myself with this talent for reading code now, after all. I didn’t try to cultivate this ability, but I encourage other debugger-dependent programmers today to try it.  I would have worked at it sooner if I had known it was feasible.

Area 2: Hobbies, computers, and kids today

All my hobbies are computer-related.  That used to be a sad statement to many.  They thought I had a limited imagination.  They thought I needed to get out more.  But they didn’t understand computers like I did.  I tried to explain (hard to do in the pre-internet days) that there’s a whole different universe inside computers that does not exist on the outside.  There is room for near-infinite creative expression inside a computer.  But in the end, the only physical manifestation of my work is a rearrangement of invisible magnetic charges on a tiny aluminum disk sealed inside a hard drive.

It’s not as bad as it sounds, though.  My hobbies include digital photography, political debates, bioethics discussions, foreign languages, cultures, mathematics and all forms of computer programming.  (I also enjoy kites, boating and tae kwon do, but they’re not in this meme.) So I had a hard time explaining to my family just what is that I do. 

But kids today just get it.  They are immersed in it.  Computers are all around them, they grew up this way, and they always have at least three microprocessors on them at any given moment.  They are used to living life online. 

Dire predictions about the loss of social intimacy have not arisen; there will always be customs and taboos. But the technological gap has widened for those who refuse to “get online”. 

These days, my 86 year old grandmother IM’s me about once a week.  Maybe it’s not “kids today” but rather the proliferation of technology that did it.  Either way, the future of technology and society is pretty exciting.

Area 3: Honesty

I think a lot about ethics and self-awareness.  A few years ago there was a curious chain of national events which opened my eyes a bit.  I realized that my aspirations to be chronically honest were unusual and that troubled me. 

I started researching it a bit more, and through some non-scientific polling, questioning and small samples, I came to the conclusion that there’s only about 30% of the population of the US that is habitually honest.  I know a lot of people won’t see anything wrong with that, because they see nothing wrong with “little white lies” or inconsequential falsehoods in the name of tact.  But I do and I wish everyone did.

I think it’s insidious.  The state of habitual dishonesty damages society and relationships.  It leaves us unable to trust most of what we hear, even from those closest to us.  This distrust tends to make us even less trustworthy ourselves. It’s a vicious cycle.

I noticed some cues in peoples’ speech and mannerisms which can suggest into which category they fit: chronically honest, chronically dishonest, or somewhere in-between. I look for them as part of this research.  I wish more people were aware of their own category and could imagine a world with more honesty and less embarrassment.

Q: Can you share your experiences with the Carputer and what are your ultimate hopes for the system?

A: I could go on and on about my carputer.  And I did, at my blog. (www.philhord.com/carputer/).  But basically it is a Windows 2000 PC installed inside the dash of my Honda Odyssey minivan.  I have a touchscreen on the dash which I use for GPS navigation (with voice prompts) and primary control of the system.  I also have a flip-down monitor for the rear passengers to watch.  The 2nd monitor has its own video output independent from the touchscreen, so I can use the front display for navigation while the kids watch a movie on the rear monitor.  I have about 20 movies on the hard drive at any given time.  I can rip new ones from DVDs or from my Tivo. I can even surf the web on the road (90kbps) by plugging in my cell phone. 

The carputer is a custom-built system, and dozens or hundreds of others have built something similar.  I looked at packaged systems instead, but none of them did exactly what I wanted mine to do.  So I built my own.  It really wasn’t very hard to do.

My wife, who hates computers, loves her carputer (she drives the van).  She admits to relying on the nav system to find her way around our new neighborhood, and the kids love the movies for the long drives to events in the old neighborhood.  When I disabled it for two weeks while I worked on a power problem, my wife actually pleaded with me to get it working again. I try not to break it anymore.

Q: Any new freeware utilities we can expect from you?

A: I have about a dozen that I want to write, but I have no time anymore.  I always bite off more than I can chew.  I have some digital photo sharing software that I started almost four years ago, but then life got in the way and I never finished it.  I wrote some tools for my carputer, and I’ll probably release those soon.  I’ve got a TRS-80 Basic emulator I wrote in a span of two weeks to see if I could. I’ll give that away, source and all as soon as I clean it up a bit.  So I guess the answer is “yes, when I get around to it.”

Q: Phil, we are indeed fortunate to have your share your considerable and valued experiences with us. Thank you!

A: Thanks for your interest.  I enjoyed our chat.