Has programming lost its way? Part Two

Whether you are an engineer, a designer, a programmer or of any other trade that requires skill, the one lesson many have been taught early on is "keep it simple". Sadly this lesson is often lost in the name of progress, especially when it comes to programming.

Let me give you one example. I know this won't go over well with most programmers, but it needs to be said. Languages like C++ simply are not simple by design. Object-oriented programming, while possibly having some value for specific tasks, does not make programming simpler. I would venture to say that the so-called benefits of object-oriented programming has more to do with the feature set of the higher level objects that some languages provide, more so than it being accomplished using OOP.

Coding environments are no longer code editors, but they are studio environments, which do little in my opinion to make programming easier. Sure, most programmers will say they are more productive now than in the past using their favorite studio environment, but a valid question to ask: Are programmers actually writing better code today, writing code faster or are we simply looking for the computer to do all the work, rather than us do the work?

I enjoy writing code. I enjoy looking for solutions to problems and being creative in the code I write. I have found though that once some developers get away from the drag-and-drop environment, they may find themselves at a loss of how to accomplish a task. Programming tools and languages today, supposely are designed to improve productivity in software development, but in the end, much depends upon the programmer themselves.

The human mind is a better debugger than any man-made application can be. Developers of programming tools can't always be trying to solve their customers' problems by making the tools do all the work. Programmers need to learn how to code, how to debug. Coding is a skill. Debugging is a skill. When a programming environment becomes so complex that one has to read a dozen books on how to use them, then something is definitely wrong. Is that ones idea of ease of use?

Code Readability

Any programmer worth his or her salt, should be a learner. You can't know everything, but when you currently lack the knowledge necessary to accomplish a task, you must be willing to learn from other peoples' code. How quickly one grasps what code is actually doing, depends mostly on how readable the code is. Code readability in my opinion is the real test of whether a programmer has really learned the lesson of "keep it simple".

Sadly, most code I come across today is neither simple nor easily readable. I am not a C programmer (I use BASIC), but I have to examine a lot of C code to find solutions to problems, since the majority of Windows API code examples are in either C or C++. Because I am an API programmer (WIN32) I research a lot of code on the Web (ie. MSDN, Code Project, etc.) to see how to properly access Windows API's. While I don't know C (nor do I personally  like it), I usually don't have too much problem making sense of good old fashioned non-OOP C code. Now when it comes to C++, half the time I just can't even make sense of what some code is doing.

Procedural Compared to Object-Oriented Code

I have found that procedural code is often far more readable than OOP code is. While I prefer the naturalness of BASIC over say C, even with a language like C, I can see C (procedural coded) as being far easier to read than C++ is. I personally find procedural style code is more likely to be "simple" and easy to read, than OOP code is.

Programming takes time (time is money as they say) and I could write procedural code much faster than OOP code, with much less preplanning involved. What is needed though, is more modular design, which improves code readability and makes debugging easier.

Code does not need to be object-oriented to be modular. Procedural code can and should be modular in design (code reusability). Even well written Assembler, with proper modular design, can be easy to read and to code. There are some valuable points made by Richard Mansfield in his "Has OOP failed?" white paper and while I would not say that all OOP is bad, I do believe it is important to not over emphasize OOP as the solution to all programming problems. OOP has not produced simpler code over all, in my opinion. It may offer some benefits in User Interface coding, but even there it is not necessarily superior.

IntelliSense or Common Sense?

While I won't go as far as to say that IntelliSense is wrong, I do believe that modern coding environments do say something about the state of programming. For the average developer, if you took away the IntelliSense feature of the code editors, he or she likely would be overwhelmed. Why? Because of the object craze, everything has to be an object and so programming languages are inundated with a huge command set, which has become more like a New York phone book (over exaggerated for emphasis) than a programming language command set.

Downside of the Bleeding Edge!

This is one thing that concerns me because as an individual software developer I find it challenging to try to keep up with the all changes in technology. I don't have the resources (or time and strength) to keep being retrained. I use what I know and build upon that over time. As I research all the new things coming along in the tech world, the one hat stands out: Developers' obsessive thirst for new things.

New stuff isn't bad, but if we always keep developing software for the bleeding edge of technology, then we lose the benefit of all our hard work in the past. We all have heard the saying "don't reinvent the wheel" and it makes sense to a developer, but sadly because everyone keeps developing for the bleeding edge, we are forced to reinvent the wheel over and over again and sometimes the wheel gets worse in each iteration. This wastes time, money and resources.  It is possible to continue to use development methods that to some may seem dated, while progressively adding new technologies at a more reasonable pace.

To illustrate this, consider automobiles. They have come a long way since their invention, but amazingly there are some core designs in cars which have not changed all that much in 30 years. While many mechanics today use computers to diagnose computer problems, you may be surprised that some tools mechanics use have been around for decades and are still useful today. When I had to diagnose a severe problem with my car, the most useful tool was actually the good old vacuum guage. Sure I could plug in in the diagnostic computer (OBDII), but the vacuum gauge actually told me more than the computer did. I ended up rebuilding the entire engine in the end, but the point is that an old tool was still useful and even more helpful than a new one.

If programming languages keep changing year after year, but fail to maintain backward compatibility, then years of software development are literally thrown out the door. That wastes money, wastes time and wastes valuable experience and resources. We end up "reinventing the wheel" over and over again, but have we actually improved software that much?

If you wonder why many businesses are still using Windows XP, a more than 10 year old operating system, perhaps the old adage is true: "it if isn't broken, don't fix it". That is a valid question to ask, whether some of the software today is really innovation or simply just an obsession with the bleeding edge and the desire for something different, but not necessarily better.

For example, I live in a rural area and in just a few years I have gone from dial-up Internet, to 768Kbps high-speed and now 1.5Mbps. Now I can download stuff a lot faster, which is nice, but my overall experience with websites has not improved as dramatically as I had hoped. Website developers assume that more people have high-speed connections, so they get careless about how fast pages will load. Improved broadband speeds are lost because of careless web design. A similiar thing has happened with software. As computers get faster and faster, the experience does not necessarily get better and better.

An Interesting Experiment

An interesting experiment to try is this: If you can find an old copy of Windows 95/98 sitting around and some old CPU intensive application that dates back to Windows 95/98 (ie. 3D Modeler designer), try installing the software on a computer that is far more powerful than what was available when the software was available. For example, install it on a computer with a 1 ghz CPU with 1GB memory. Most of the computers when Windows 95/98 were around were likely less than 100MHz in speed. You may be surprised to see how "fast and fluid" the experience is using the software. Now imagine running the software on, say, a top-of-the-line, multi-core CPU we have today.

I really don't get the impression were are producing all that much better software than we did in the past.  Coding environments definitely lack simplicity. Software is slower than it needs to be. Software is likely still just as riddled with bugs as it was 15 years ago. Software development is likely no more productive than it was 15 years ago. User experience is not necessarily significantly improved compared to the past.

So, I ask. Again. Has programming lost its way? I will leave that up to you to answer.

Photo Credit: Gunnar Pippel/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.