Old Man C++

Well, I’m back after a short hiatus. I know you missed me, but no explanations will be forthcoming, so you’ll have to live with it.

But it’s time to write again, and for the past eighteen months or so, I’ve been working on a single Windows C++ project, after leaving Windows development altogether since around 2004. I actually started my career in DOS and Windows 3.1 C++ development (yes, I’m that old), and I’ve been doing software development (mostly in C++) on one platform or another pretty much constantly for the 20-odd years of my career. Coming full circle, as it were, to Windows again, I’m noticing a few interesting things…

  • General quality of commercial code has gone way down.
  • In contrast, the quality of the Microsoft Windows platform itself, and the API has improved considerably (some can probably imagine how much it hurts to write that, but it’s true)
  • C++ used to be viewed as the cool kids’ language – now it’s what the old guys make the cool kids use as a form of punishment
  • Compiler and platform differences are still there, but they’re far less of a problem than they used to be
  • Despite some improvements, they still haven’t solved the whole stupid DLL mess
  • Dot-Net may make a difference to all this, but not everywhere, and probably not where it matters most
  • Windows 8 is probably Microsoft’s last chance to dominate in the platform arena. It might just work.

There’s a few chunky ‘out on a limb’ statements there, and it’s a bit much for just one post. So, welcome to part 1 of a series I’m going to call the “Old Man C++” articles. What I’m hoping to communicate is something of how Windows C++ development has changed since the 16-bit days.

And yes, I’m aware that there’s been lots of other stuff happening in software development in the last twenty years. There’s this Java thing that some of you kids keep going on about, and Windows isn’t the only game in town any more. But let’s stay focused – narrowing this down to a single language and platform will hopefully reveal some trends and directions that wouldn’t be apparent if we jump around too much. Besides, I’m old, and my fingers get tired easily.

So my first observation has been that, in general, the quality of the commercial code that I encounter in my work has gone down significantly. Seriously.

Mainly I’m talking about commercial third-party APIs with which I work, but also about legacy code that I’ve had to maintain – stuff that has been written by qualified people for money. With a very few exceptions, the commercial C++ code I’ve encountered written in the last five years has been well below the standard we would have expected for software engineers with a few years of experience ten years ago. It certainly wouldn’t have passed code reviews, and the culprits wouldn’t have lasted long in the industry.

A lot of it’s pretty basic ‘best practice’ implementation stuff, like const-correctness, or the choice of pointers versus references. Others are design-related, like bad application of patterns, or improper use of derivation and composition. I’m not talking about things that I simply disagree with – I’m talking about stuff that goes against expert opinion, documented in books that every C++ developer should have read. Stroustrup… Meyers – people in that league.

And I don’t think it’s because software developers aren’t as smart or well-trained as they were twenty years ago. Most of the people I work with right now are (a) younger than I, (b) excellent software engineers, and (c) smarter than I am. You know who you are.

So here’s the “old man’s” opinion: The problem with software engineering today is that there’s no discipline.

I’ll go so far as to say that lack of discipline is the most significant factor in bad software today.

Obviously it’s hard to come up with anything quantitative to support this, but here’s a personal observation. Let’s look at processes (which are a favourite hobby-horse of mine). Back in ‘the good old days’, if you didn’t dream in UML and sleep with Booch or Rumbaugh (or preferably both) under your pillow, you didn’t bother applying for a software job. Just about every project I worked on was done in some variant of a waterfall methodology, it was all documented, and you had to care about the process, because if you didn’t, other people would come down on you pretty hard for it…

… And possibly beat you and burn you as a witch. We knew how to party back in the day.

You analysed, designed, executed and tested, and documented your little heart out, because that was they way software was written. There was no other way, and everyone understood that.

Now in these (supposedly more) enlightened times, we have a veritable cornucopia of methodologies to choose from. There’s lots of options – in theory, you choose whatever process suits your goals, business needs or preferred way of working. Everything’s really adaptable and flexible and… ahem… agile.

But which software development process does your software company use? Have you had training in it? Where is it documented? Do you follow it? Do all the software engineers in your group follow it? How do you know? How can you demonstrate it to me? If you can answer all of those questions positively, you’re in with the very small minority of people I’ve worked with in the last ten years.

I think the sheer number of new (and very good) processes are choking us. Every time we go to a new job, we usually have to learn the problem domain (even if we’ve got previous experience), but we’ve also got to learn this particular company’s specific variation on the current methodology du jour.

It all costs time and money, and that’s significant because personnel turnover is notoriously high in the software industry. And I think that the underlying effect is a reduction in process compliance. Processes take time to learn, and you want your people to be productive as quickly as possible. That’s a big incentive to skimp on process, because it’s a long-term consideration, versus a short-term gain. And you don’t want to invest a whole stack of time training someone who may not be with the company after the project is done.

Just to be clear, I don’t equate process with software discipline or quality, but if you can’t show me why your code is right, why should I believe that it’s right? And right there, you’ve got the beginnings of a process, discipline and quality.

Which is what I’m being a grumpy old man about.

Just to finish up, there’s two reasons I care about the quality of C++ code. First of all, I believe good quality software makes more money than it costs, so it’s good business sense. Secondly, I like doing a good job. I hate rework, and I’m always grateful when I have the time and resources to do a software job properly.

Doing the job right first time every time may be a fantasy, but when it happens, it’s cheaper and more fun.

Speaking of fantasies, my next post is going to be about the (possibly paradoxical, or even blasphemous) observation that the Microsoft Windows API has hugely improved in quality since the Windows 3.1 days.

Please don’t burn me.