The Problem with Programming

In a recent interview, Bjarne Stroustrup, probably best known for inventing C++ and currently a professor of Computer Science at Texas A&M University, talks about some of the big issues of program development, C++ and his legacy and other related matters. The interview is full and important and valuable observations. I recommend it as a starting point for discussion about how to create really good (reliable, robust) programs. I'd like to highlight a couple of comments though.

I think the real problem is that "we" (that is, we software developers) are in a permanent state of emergency, grasping at straws to get our work done. We perform many minor miracles through trial and error, excessive use of brute force, and lots and lots of testing, but--so often--it's not enough.

What he describes in the paragraph above is how most students program. They throw a bunch of code in, test it and when it doesn't work they try different code. All at break neck speeds with little time to calm down and plan. We, as teachers, like to think we can teach them better and that they will change. Well the first part is true but is the second? Another comment from Professor Stroustrup:

In theory, the answer is simple: educate our software developers better, use more-appropriate design methods, and design for flexibility and for the long haul. Reward correct, solid, and safe systems. Punish sloppiness.

In reality, that's impossible. People reward developers who deliver software that is cheap, buggy, and first.

And there is the rub. People do know better but they are not given the time nor are they rewarded for doing it right the first time. In fact there is a whole school of thought around rapid development and throwing the first few versions out. Frankly that idea scares me. I'm a great believer in many of the things that W Edwards Deming taught. I was fortunate enough to take his famous 4 day course from him. One of the things he really convinced me was that quality results were largely an issue of management.

It seems to me that the real answer to software quality is going to have to start with management. Oh the right language and the right development methodology can help. But it is the responsibility of management for fist provide the training and then provide the environment (and that includes reasonable schedules) so that programmers can do quality work. Read the interview and discuss the issue with your students. What do you come up with in your class for the answer to "the problem with programming." Let me know what you come up with. Maybe we can get a discussion going here.

tags: ,


Comments (4)

  1. Ben Fulton says:

    The problem is, you can do the best quality work in the world, and the user will say, "Very nice, but I’d like to be able to…" and then you have the choice of either telling him he can’t do it; or reorganizing your schedule.

  2. AlfredTh says:

    Yeah I’ve been there. The truth is that someone has to explain reality to customers. If you want a change it will take time. Period. There is no free lunch. I think the expression is "Fast, good, cheap – pick two."

  3. dls says:

    The interview was interesting, but ran away too quickly toward a discussion of the (de)merits of C++. Before it did, and in the Wiki’s discussion of Dr. Deming, I found a theme that I like to think is mixed up in the problem with programming. Abstractions hide information, whether hardware abstracting object models in software or operations abstracting management models in a company’s organization. Where the fitness of these abstractions is imperfect, the abstractions invite contradictory reasoning. Where the contradictory reasoning is the basis for a critical decision, we invite risk that may not be evident before it has concretized.

    So abstractions are risky, but programming needs abstractions. Most programming projects can’t afford to recreate even relatively high level wheels–such as a logging solution–let alone the lower level wheels–such as a video driver.

    I think that living with the abstractions and appraising them is something programming does badly. Understanding and explaining the abstractions, their interactions, and their limitations during the earliest customer and programmer interaction is vital, but usually doesn’t happen.

    I have some _small_ hope that better tools for managing abstractions will be developed which can flexibly classify abstractions and use machine reasoning techniques to validate expressions about them.

    Unfortunately the cost to use these types of tools is high (my best example is in model based design tools that _run_ a model).

    Until it’s solved, I plan on stakeholder education, rigorous evaluation of reusable abstractions, and craftsmanship.

  4. John Hunter says:

    I agree with your thoughts on Deming – management needs to improve the system for software development.  David Anderson has some great ideas on Deming, lean, agile and software development.  Also see my Curious Cat Management Improvement blog <a href ="">software development</a> and <a href="">deming </a> categories.

Skip to main content