Has programming lost its way?

The average end user has no idea what goes into developing software. All they see is whether the software works or not, whether it looks good or whether it is easy to use. But for developers it is a totally different story. They are overwhelmed with new technologies every day and programming, rather than getting easier, at times becomes more and more challenging.

Programmers often are at the mercy of those who create the development tools they use. Drag and drop, IntelliSense, XAML, code editors replaced by Studio environments, debuggers, OOP and more OOP. Now we have Metro, WinRT and a totally new world of Windows development. Has programming really become easier and easier, with all the choices we have today? Or has programming lost its way?

What Is Programming All About?

1. Bits and bytes. When you really come down to it, programming is all about bits and bytes. The text on our screens are bytes. The graphics we display are bytes. Memory managers handle bytes. A complex data structure is just a lot of bits and bytes. True, to the end user, they see words, they see pictures, they see all sorts of data, but to the programmer, his job is to move a lot of bytes around to the right place at the right time.

2. Logic. Yes, programming is all about logic. If this, then do that. Do this, while that exists. At its simplist, programming is all about logic. If the logic is good, the software works correctly. If the logic is bad (in error) it will not work as intended. It is as simple as that.

3. Lots of math. If there is one thing that I have learned over the years, it is this: When it comes to programming, "math counts" (not a pun). Yes, the better a programmer can translate a task into its mathematic components, the better his or her software will be and the faster they can code it.  Now some tasks are so complex, that only the most advanced programmers are capable of handling them. I have great respect for the people who write things like video codecs or graphic engines. Likely an excellent math background plays a large role in their skills.

Now notice, I haven't mentioned XAML, OOP, COM or any other technology. No matter what high-level language or technology is used by a programmer, it all culminates into much simpler things like I mention above. In the end, a computer must execute some machine code and then make logic decisions and move lots of bytes around. It does not know what high-level languages we have used. It just knows bits and bytes and logic.

To appreciate this, consider the latest iPad that Apple released March 16. Look at all the excitement about the new Retina display and the more powerful CPU. Guess what? Four times more pixels in a display, means four times more data for software to move around, which means more space in memory to store all those bytes, more space on a disk drive to handle all that data and a CPU that is four times more powerful to handle the four times more display data. See how simple that was?

I just burst your bubble, because this means that you have literally lost much of the benefit of the faster CPU in the iPad, because it now has four times more work to do. Programmers have to consider things like this. Imagine a person who cleans houses for a living. When others see a huge mansion with dozens of rooms, they see a dream home. When the house cleaner sees a mansion, the first words out of his or her mouth is: "I would hate to have to clean all those rooms, what a nightmare that would be". Can you better appreciate the challenges programmers face now?

Two Skills Sometimes Lacking

If I was asked the question: "What do you think is most often lacking in programmers today?" There are two skills that I feel are critical to software development which are more likely to be lacking.

1. Understanding end users. One of the biggest problems developers can have is understanding their end users. No matter how good we are at programming, this does not mean we understand what the end user wants or really needs. Sadly, our own technical skills can even get in the way. We can get so caught up with the latest technology, that we easily "miss the forest for the trees", as they say. A good question to ask, when developing software, is: "Are the choices I make leaning towards the complex or towards the simple?"

Also we need to ask ourselves whether we really do understand our end users. In my own experiences, I have found that the many years of writing custom software for local businesses has benefited me greatly. I have written software for large companies, as well as for small mom-and-pop operations. The one thing I learned early on, was that I needed to come down off my programmers "high horse" and take the time to really learn what my customers wanted and needed.

The first step I would take with a new customer often was simply to just spend some time learning about what they do. I would say something like  "give me a tour of your business and show me how you do things now". This would often lead to questions like: "Why do you do this or that?" or "Explain to me how this works?" I may be a programmer, but that does not mean I am a doctor, a lawyer, a machinist or a retail store owner. When it comes to the tasks my customer has to deal with daily, I am the dummy, not them.

It is easy for developers to think they know what an end user wants, but still get it all wrong. To illustrate, consider what sometimes happens when a parent thinks he or she really knows what toy the young children want. The parent purchases this really big, huge and expensive plastic toy, with all sorts of bells and whistles and when he or she takes it out of the box for the child, the five year-old plays with the box instead. How humiliating that is! The parent got it all wrong. Purchase an empty box, and the child would be just as happy. Do we as programmers, some times make the same mistakes?

So to write good software, a programmer needs to be a good learner, a good listener.

2. Debugging is an art. Now if there was just one thing that I would want to teach a new, young and budding, developer, it would be this: Debugging is an art form, not a technology. New developers often ask experienced programmers: "What debugger would you recommend?". My answer? "You are the debugger, and no computer technology can replace you".

Debugging is an art form, a skill, which is hard to teach another. To be a good debugger, requires more of the skills of a Sherlock Holmes, than anything else. In my case, I design tools for programmers. This means not only do I have to debug my own software, but often when customers have problems I have to help them debug their software too. You see, the only way I can make sure that the problem is not with my tools is to help the customer find the actual cause of a problem. In a few cases, my code has a bug, but many times the customer's code is the cause, and I had to work with the client to uncover the real problem.

If you were to ask my customer base (which are all programmers), what is one of best features of my software tools, likely the most common answer would be its reliability and stability. I actually have had customers try to break my software on purpose, just to test it out. One told me he would pass bad parameters to functions just to see what would happen. Fortunately, I write code with a lot of parameter checking in it, so it is more difficult to break it. The point is, that if I had not learned the art of debugging, I would not be able to provide software that is reliable, especially in the minds of other programmers.

Now when my customers ask me how I debug software, they're often surprised to find that I don't use any debugger software at all, not even the ones that exist in the compiler I use. All I need is a simple debug window (which I added to my tool) to display text at key points of a program's execution and a messagebox and the BEEP command in the programming language and the skill to debug.

In rare cases, I may even create a debug log file of my own design. Yet, without all the fancy tools other programmers use, I can develop some very reliable software. Now this does not mean debuggers have no place, just because I don't use them. The point is, that programmers may expect a debugger to accomplish something that depends more on the programmer than the debugger.

Now there is more to debugging than this, and I don't think I could even write an article to try to teach others how to do it the way I don But the point is that the programmer is the debugger. Unless the programmer views himself as the debugger, then no tools he or she uses will every accomplish what is required. So if you do use debug tools, try an experiment to see how much you can accomplish without them. I have nothing against using a debugger, but the debugger can not replace the programmer.

A Shock To My System

From my bio attached to this article, you obviously realize that I am a long time Windows API programmer (WIN32). What you may not realize is that I don't use OOP. I don't currently use a Microsoft Programming language, and I definitely don't use any .NET frameworks.

I have used Microsoft languages in the past, such as QuickBasic, PDS 7.1, Visual Basic 1.0, 2.0 and 5.0 Professional, but it has been at least 10 years since I have done anything substantial using a Microsoft programming language.

So it was interesting last year when I downloaded the Windows 8 Developer Preview with all the Microsoft programming tools and installed it on one of my computers. I am very interested in Metro; since the programming language I use is not Metro-ready yet, I had no choice but to play around with Visual Studio.

I am no stranger to Windows. I visit websites like CodeProject and MSDN to read articles that interest me, trying to learn new things about using the Windows API. I have the Windows SDK installed on my computer for reference, and I use some of the tools with the SDK -- like the Depends utility. I enjoy playing with things like the Control Spy utility found on MSDN to see how different control classes work.

I am also not a novice when it comes to the Windows API. I have learned a great deal about it during the last 10 years and this has allowed me to learn some advanced coding. For example, I developed my own drag-and-drop engine, so it is easy to build WYSIWYG style visual designers. I have written a number of custom control classes, such as a Masked Edit control, Canvas control, MCI control, Files Listbox control, Property Listbox control, Shape/Hotspot/SplittarBar control, drag handle control, Turtle Graphics control and my latest glCanvas control.

I wrote my own proprietary 2D sprite engine for my Canvas control that can handle things like frame animation, antialiasing, alphablending and collision detection. I have written image filters for drawing bitmaps. My glCanvas control is a hybrid control which blends my Canvas control features with an OpenGL based 3D scripting language.

I have worked with things like ownerdraw, DIBs, complex window regions, multimonitor support, theme drawing, OpenGL, threads, subclassing and superclassing, memory DC drawing and more.

So what was my experience when I tried to use the latest Visual Studio as someone who hasn't really worked with a Microsoft language for 10 years? Shock is the only word I can use. I am used to coding in a programming language that is only a few megabytes to download. I use a simple code editor IDE and I write code, lots of it. I built my own drag-and-drop visual designer with a code generator / Smart Parser technology which integrates with my programming languages code editor.

By comparison, Visual Studio is this giant development environment that requires gigabytes to install, not megabytes. I don't think I am a total idiot, but I can not find my way around the IDE. Very few things make sense to me. XAML is just so totally foreign to me, just forget that (So what does XAML have to do with Windows?).

Even the Metro form designer is not intuitive to me. Now I may not use Microsoft programming languages today, but I have plenty of higher-end graphic applications that I can use, such as CorelDraw and other visual oriented design tools, so I think I can find my way around a drag-and-drop environment. So it makes me wonder, what has become of programming today? Has programming really become easier today? Have we as programmers lost perspective? Do we even know how to code anymore?

Visual Studio is an excellent programming tool in the right hands. But for one who does not use Microsoft programming languages like myself, I do wonder what has happened to programming. So, what is so easy about software development today? Will the programming languages of the future require terrabytes rather than gigabytes?

If development tools are so complex today, has all of this power in the hands of programmers trickled down to the end users? Well, we still get complaints about software being slow, bloated, buggy and not intuitive. I know, you can't please everyone, but are we as developers really accomplishing the ultimate goal of making our end users happy and productive? Remember the analogy of the child prefering the box to the toy and look at customers' behavior, such as the challenge so many businesses have moving away from Windows XP.

I finish this article with the question I started with: Has programming lost its way?

Editor's note: Please read the follow-up post.

Photo Credit: Gordon Warlow/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.