Six lessons I learned about writing software

From independent software developers to the enterprise, everyone is looking for ways to improve software development, increasing productivity while not sacrificing performance. Software technologies continue to change, but have programmers really found the real keys to faster development cycles, more reliable software and improved performance?

While it is obvious we have more powerful software today, this does not mean we have better software today. As it becomes more complex, there are more things that can go wrong. In the old days, software was often written by a single programmer, while today software often is written by teams. The complexity alone of trying to get a team of programmers to work together is challenging enough, but add to this the size and scope of some applications that can be hundreds of thousands of lines of code, if not possibly in the millions of lines of code, and you can have a veritible nightmare trying to put it all together. Few trades today require so much attention to details at such a large scope as does programming.

End users assume the software they use is reliable, but developers know the truth that all software is likely to have some bugs in it. Bugs! What an interesting term we programmers use to describe "errors" in our code. The term bugs may imply that the problems with software are some how external and not our fault. Those nasty little bugs, just keep sneaking into our software. The reality though is that bugs are errors, errors in logic, errors in typing, errors in passing bad parameters. They are introduced by programmers. Yes, when our software has bugs, it is our fault! We did something wrong and it is our job to fix it.

Education Fails To Teach the Skills We Need

In the years of old, when a skill was learned it was most likely done as an apprentice to a skilled worker or tradesman. The tradesman, didn't teach for a living. The trade was his job. He used it in real life.  As the student you learned from a master of a trade who did real work for real people. Imagine seeing the work of a real cabinet maker right before your eyes and hoping to someday be able to do the same thing yourself.

While I am a self-taught programmer, who dates back to the days of CPM even before the IBM PC became popular, I did actually take a college course on programming once. I can remember back in the late 1970s, when I attended Worcester Polytechnic Institute (WPI) and studied Fortran. In those days, one had to enter a program into a main frame computer using punch cards. I can remember sitting in a large hall that could seat hundreds of students and listening to lectures on how to write software. Not what I would call an apprenticeship for sure and definitely no real world training.

I left college for personal reasons, so I do not have a degree, but my interest in computers would later come to the fore, but as a self learner. In many ways, being self taught freed me from some of the problems associated with learning programming from so called "higher education".

One of the popular programming concepts to come out of the educational system is object oriented programming or better known simply as OOP. OOP has some merits, but rather than promote OOP simply as just another tool in a programmers toolbox, it was somehow transformed into the panacea for all programming ills.

But has anyone done any extensive testing to see whether OOP is significantly better than procedural style coding? It appears that little real world research has been done in testing this out, at least that is the opinion of one long time computer expert, Richard Mansfield. In his white paper entitled "Has OOP failed?", he discusses this in length.

I Find It Hard to Argue with a Skilled Tradesman

Richard Mansfield makes a number of interesting points in his white paper, but there is one thing that adds a great deal of weight for me personally. I am a self-taught programmer, but the term "self taught" is actually a misnomer. You have to learn from someone. Everybody needs a teacher. I simply chose to pick my teachers and learn by reading, rather than have my them picked for me (as in college). When choosing a book to learn something as complex as programming I had two criteria. The first, the author must really know the subject and second he or she should be able to explain it to me without all the fancy and big words so called educators like to use, but in simple terms which make sense. I don't want a thousand page thesis on a subject that could be explained in one or two pages.

Back in the 1980s, when the home computer was really taking hold, I learned about programming on a Commodore 64, which was a huge success at the time. While many self-taught, would-be programmers of the time played with interpreted BASIC, I used an actual Basic language compiler (by Abacus) and learning machine language too. Richard Mansfield's book on 6502 machine language taught me 6502 machine language in short order. I was the apprentice and Richard Mansfield was the tradesman. Before long I wrote my own compiler, which I used to create a video game that I sold to Compute Gazette, which earned me about $1,500.

It doesn't take long for me to tell whether the author of a programming book is a real tradesman or not. Does the book waste time with a lot of "educated nonsense" and theories about programming or does it quickly get down to work showing me how it is done in the real world and why? Richard Mansfield proved himself a tradesman. As an apprentice I learned a great deal from what he wrote about programming. I then used what I learned in the real world.

Lessons from Consulting

To make a long story short, I took a hobby and eventually turned it into a real trade, which I got paid for. In the 1990s, I got an opportunity to do some programming for local businesses. Programmers back then were not a dime a dozen like they are today. It was not easy to make an IBM PC (or compatible) do a lot of complex business work, when it was only equipped with a CPU of less than 25 MHz, 640 KB RAM and a couple floppy disk drives (or at most a 20 meg hard drive). I just have to laugh when I hear programmers today complain about the Intel Atom CPU, or a PC with only 2GB of RAM or a lowly onboard Intel GPU (graphics). They have no idea how far computers have come in only a few decades.

In doing work for local businesses, I quickly learned the difference between programming theory and reality. I can remember one early customer who spent about $5,000 on two Tandy IBM compatible PCs. He needed custom software for his manufacturing business, but there was no one available to do what he needed. So he talked to the local community college computer department and asked them if they could provide some help. They told him, be prepared to pay five times what he spent on his computers for the software. The guy just spent $5,000 and now he was told he would have to spend $25,000 just to get the computers to do something useful.

This businessman found me and within a hours time, he knew he found what he needed. I quickly showed him how to get the most from his investment and proceded to write his custom software. I didn't charge a lot in those days, because despite my knowledge of programming I still viewed myself as the apprentice and not the tradesman yet. I wrote a complex software package that handled job estimating, job tracking and invoicing. I even designed my own network using a serial cable between two computers so he could have both computers work together. And I wrote the software using Basic, plus a little machine code added in.

The real test of a programmer is being able to write software that is reliable, within budget and with performance. In those early years I can even remember using a stopwatch and actually testing my database routines for optimal speed. I even would test different buffer sizes for the optimal size that would work best with the mechanics of the hard drive.

So doing real work for real businesses taught me a few important lessons that I doubt I would have learned in college:

1. Development time is critical, especially for custom software. This is one reason I never stopped using Basic. Over the years I checked out other languages, like C, but I never found any languages that had the naturalness of Basic. My code was easy to write and easy to read. Code readability is a must if you want reliable software that can be maintained.

2. Performance is always important. Even when I used interpreted Basic I optimized for performance.  When compilers became available I quickly moved to using them. When using assembler was the only way to accomplish something or to get the performance I required, I used it.

3. Productivity depends upon the ability to reuse code, and building quality library code is always important. OOP supposedly is superior for code reusability, but I have found that procedural code can produce just as good reusable code. Code reusability has more to do with the mindset of a programmer, rather than a technology like OOP. A good programmer knows when and how to build a quality library.

4. The less code you have to type the faster it gets done. Quality libraries can decrease the amount of code you have to type in, but also how you code makes a big difference. If speed is not critical for a subroutine or function, then writing it so it uses the least amount of parameters may be more valuable and in the long run will save time.

 5. The programmer is the debugger. Debugging is a skill or even an art. Programmers today depend too much on automation to do their debugging. No software debugger, no unit testing application or any other automated tool can replace the programmer's mind. If debugging is an issue, then the programmer is at fault, not the tools.

6. Keep it simple. Yes, the programming language you use, the development environment you use, how you code and even how you build reusable code should all follow the principle of "keep it simple". This is one of the biggest reasons I actually avoid OOP, which demands too much complexity and too much planning and the benefits of so called code reusability are not any better than procedural. Actually procedural coding styles can produce smaller executables, with less code, easier to maintain and most important faster (performance).

Many people will likely want to debate this point, but I can simply point to the obvious bloat in most software today. Remember, I come from a day when a person could write something like a complete accounting package (or any business app) that could run on a computer with only 640 KB RAM and two floppy drives. Today's huge UI frameworks that are 20, 30 or 40 megabytes in size says something. I can remember when some amazing programmers could build a Mac-like (or Windows) environment even with multi-tasking that could run on a Commodore 64 with only 64 KB memory (the software was called Geos). Today, Windows despite having benefits of 2GB memory or more requires a great deal of page swapping with the hard drive, just to keep pace.

Reconsider How You write Code

Now I won't say don't use OOP, which has value, particularly with some UI stuff. All I am saying is at least reconsider whether to always use OOP or not. Just because the majority of programmers have swallowed higher education's view that OOP is superior should not prevent you from considering a more balanced approach of using procedural coding first and then OOP when it really does fit the task at hand. Just for the sake of discussion and an open mind, do a Google search for the words:

Google "software performance productivity OOP procedural" and see what you find. Some of it may be nonsense, but there are a number of good programmers out there who are rethinking how they write code. Even some who use OOP regularly, have issues with it.

Regardless of whether you prefer to use procedural or OOP, take a second look at how you write code and ask yourself whether it really does follow the principle of "keep it simple". Is the code easy to follow? Is the code easy to read? How difficult is it to follow the flow of the code (the actual order the computer will execute it)? If it is difficult to follow the actual flow of the code, then simply put it will be a nightmare to debug.

A Tradesman is a Better Teacher than an Educator

If you have ever worked closely with a real tradesman (or woman) of any sort, like a carpenter, a mechanic or even a computer programmer, who really knows the trade, it is amazing when he (or she) can quickly show you not only how to accomplish a task better but also explain why it works. I can remember when my father, who was a plumber most of his life, showed me how to properly solder a joint in copper water piping. It was a little trick he had learned, and it was quite surprising. He said that some  plumbers like to make their solder joints look pretty, so they carefully run the solder around the joint. It sure looked nice, but many a time he had to go to a job to fix pipes that busted just because of this. His technique was to put a little flux on a flux brush and after putting the solder on the joint, while it was still fluid he quickly wiped around the joint with the brush as if he were wiping it off.

The end result was not pretty. Some plumbers would take one look and say it looked terrible and messy. Then my father unsoldered the pipe he just connected and showed me the inside of the joint. He told me the wiping action with the flux brush caused the solder to get sucked deep into the joint and when I saw what it looked like inside I knew he was right. The joint didn't look pretty, but it was much less likely to bust when under pressure.

The point is that the real test of the quality of anything is when it is put under pressure (or used in the real world). Software is no different. No matter how one writes software, the real test is whether the software is good or not. Does it work as intended? Is it easy to use? Was it done under budget or even faster? Is it reliable?

I am amazed at how often programmers will quickly see the word "BASIC" when I refer to how I write software and automatically come to the conclusion that this guy does not know what he is talking about. Who uses Basic anymore they will say. But the real test of any tradesman is what he has built and if it is being used by others successfully. I can honestly look back at much of the software I have written and feel a sense of accomplishment when I see how it benefited the businesses I wrote it for. Some of that software is still in use even after 10 or 15 years, because it works so well.

Today I write programming tools for other programmers and when I see a customer using my tools to build their software and they are successful it means a lot to me. Then I remember what my father said about how others viewed his technique for soldering copper pipe. All I can say is "thanks dad, you were right". If he were alive today, I would venture to say he would be happy to know I still solder pipes the way he taught me all those years ago and if asked why I do it this way, I can easily explain the reason "why" it works, because a tradesman taught me well.

When some people take issue with the white paper by Richard Mansfield about "Has OOP failed?" I tend to feel similarly. Maybe it's how we teach programming today that needs to change if we want to have better programmers.

Photo Credits:  kentoh/Shutterstock

Chris Boss is an advanced Windows API programmer and developer of 10 year-old EZGUI, which is now version 5. He owns The Computer Workshop, which opened for businesses in the late 1980s. He originally developed custom software for local businesses. Now he develops programming tools for use with the PowerBasic compiler.