This article came up on Hacker News recently. It resonated with me even given its lack of depth.
Most of what we deal with in software engineering is subjective. Let me offer a case in point.
I have worked on projects where there is a working code base that happens to be written in C. The code base isn’t that old, perhaps ten years or so. It’s been under maintenance the whole time. It compiles cleanly and generally all of the code follows the same set of patterns and conventions. They aren’t necessarily the same patterns and conventions I would follow, but in my view, the benefit of consistency outweighs having a code base where there is no single style in use.
On this project, it was decided that the code should be rewritten in C++ so that it can be extended. That’s a claim that needs to be justified, as it’s entirely possible to write extensible software in C.
The Linux kernel is one example. How many commits are there in the master repository that Linus maintains? The Linux Kernel Foundation writes that more than one million commits have been made – and that was a full year ago as I write this.
The real bone that I have to pick is that developer preferences are usually not in line with what’s actually best for the business. This isn’t a hard and fast rule, of course. But if you’re taking an existing large body of code and asking new developers who haven’t used C++ before to write code and immediately contribute to the code base, you’re making a significant operational mistake.
I have used C++ since about 1992. I started back when cfront (1) was how you compiled C++ code. The language has grown immensely in complexity since that time. I recently read about a book on move semantics (a relatively new C++ language capability) that runs to 260 pages. The C++14 language standard itself clocks in at more than 1500 pages.
My late mentor, Eli Goldratt, used to say that “What happens in one department affects every other department.” Too often, people don’t seem to get this. What’s needed is for the management team and the development team(s) to work together to develop objective analyses of what they propose to do before they launch large projects, like the one described above. Then, in execution, what’s happening on the ground needs to be reviewed closely enough so that everyone knows what’s really happening. Developers should not be pulling a technical power grab as a way to add to their skill stack. They should, instead, partner with the management team honestly.
In like manner, the management team needs to be curious about what’s going on and thoughtful in their judgment. Software development is complex. If you think you can manage it without a credible understanding what the team is doing and why, you will almost certainly be disappointed in the outcome.