The “Software is Simple” Syndrome

In looking back over the years, it seems that I have worked in either the rigorous environments of hard real-time mission critical software, or I’ve worked in scientific research environments. Which strikes me as odd, since the two realms are, in many ways, polar opposites when it comes to how software is designed, implemented and tested. I would have to say that while I like the formalisms of the embedded real-time work, I also enjoy the intellectual challenges of scientific programming. But there’s a price to be paid for that, and I want to share with you my thoughts on that score.

Over the course of my career I’ve done a lot of work in environments filled with very, very bright people, most of which had PhD degrees in something or other. Physicists, chemists, astronomers, optical scientists and so on, doing exciting research and making all kinds of cool discoveries. I’ve also noticed that, by and large, there is a pervasive attitude towards software that makes it difficult to practice good software engineering in the context of the scientific research environment.

What I’ve run into, time and again, is that these people are so focused on just getting the data they need for their work that they really don’t give much thought to the software used to collect and process that data. They just want it to work and be accurate. When they took their “Introduction to Computer Programming” classes as undergraduates it all came very easy (at least for a lot of them) and looked enough like simple mathematical logic that once they had mastered it and gotten an A in the course they were done with it. Software is simple.

Then there is the all too common attitude one encounters wherein engineers are viewed as fancy appliance repair technicians who lack the “deep insights” into the technology they work with. A really good EE with some patents under the belt and a deep knowledge of VHDL might be able to push back on this successfully, but a good software engineer is often viewed as someone who does a lot of non-productive stuff involving diagrams, spreadsheets, hand-waving and cryptic terms. Now add in the attitude that “software is simple” and it becomes apparent that it could be a long uphill battle to get some of these people to accept that the processes and procedures of software engineering are not only a good thing, but essential.

For example, I once worked with a young person who had little formal training in software development, but who had been tasked with developing a rather complex piece of software. There were no requirements, no up-front design and no test plan. Just a directive to make something that did a particular function. He labored mightily on this project, writing and re-writing and debugging and compiling, over and over and over again. I would occasionally wander into his area and inquire on his progress just to marvel at how much wasted effort one could expend going around in circles and listen to his bizarre attempts to prove to me that he was also a software engineer. But what really amazed me was that the scientists who had requested this provided very little oversight, and didn’t seem to understand that if it didn’t work someone might get hurt, or even sued in court (I’ll just say that it involved lasers and leave it at that). The only criteria for success was that it could be demonstrated successfully and everyone would go “Hey, that’s cool!” and that would be the end of it.

There was no documentation to speak of, and the code itself was one of the ugliest things I’ve ever seen. I only saw it by accident, as this young wizard refused to let anyone review his work. He would wave it in front of the scientists knowing that their eyes would quickly glaze over and he’d be free to carry on with his glorious project. When a couple of us who actually did software as a profession asked him (nicely, mind you) about safety and reliability issues he became very defensive. Downright irate, actually. The scientists told us to leave him alone, so we did.

Well, to make a long story short, it did work, soft of. At least for a while. The software would mysteriously crash at random intervals (null pointer errors, mostly), the display would sometimes lock up (often operator error because there was no real documentation and no input checks) and there was so much coupling in the code that attempting to fix something over here was guaranteed to break something over there. Needless to say, no one wanted to take the responsibility of maintaining it, not even the person who wrote it.

The moral of the story is that while the software did embody the necessary basic concepts it did so very poorly, because the ability to distinguish “good software” from “bad software” is not something one can determine from simply understanding the underlying math—it’s a function of how carefully the software is designed, implemented and tested. Until this is understood the result will be garbage software, and no matter how much data it produces (or how many papers are written about it) it will always be garbage. And, like most garbage, it will eventually get thrown out.


0 Responses to “The “Software is Simple” Syndrome”

  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

Follow Crankycode on

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: