Does it make sense to keep two different versions of code?

As a professional software engineer writing embedded software (i.e., the software itself is not a product, but it is part of a physical product), nearly all the time I am working with and extending an existing code base.

As I am not in the habit of doing things twice, we only have a single code base for a product (or a range of products), but using different build settings we can create variants with, for example, test and debug facilities enabled or disabled.

As software gets read way more often than that it gets written, the first rule of good software engineering is to write good readable (maintainable) code. Only if measurements have shown that the performance is not good enough, then there might be an argument to sacrifice readability of the code that is positively identified as the bottleneck in order to meet the performance requirements. But that is a rare occurrence in my experience.

Personally, I can imagine where writing and keeping two software codes makes sense. For example, one wants to have a test version that simply implements all the desired functionality and use that one as the base-line and test system.

Sometimes, we do this in professional projects. But we usually don't do this for full programs, we do this only for small, time critical parts, like single functions or single classes, and in rare cases for single modules. In the majority of cases, a concise and readable version of a module is already efficient enough. Even if we need an optimized version of a certain function, it can still be readable and concise enough for not having any need to maintain two variants in parallel.

But for sure, there are indeed cases where we keep a concise and readable, but slow function as a reference, whilst we also maintain a more sophisticated, faster, and more complex version of the same function. Whilst the complex version then goes into the production code, the slow function may be used inside some automated test to verify the correctness of the more complex version.

And yes, specificially when using compiled languages, we also do what Bart already wrote: making use of build settings to let our compiler or build system create two differently optimized variants from the same source code, one for debugging and one for production usage.

We actively do this. Our reference code base follows academic papers, and it's easy to show a one-to-one mapping. This gives us the confidence that the results are correct. It's rather slow, though - the theoretical model implemented was not designed for speed. On the plus side, it runs on pretty much all hardware.

We also have SIMD implementations for AVX and NEON CPU's. These implementations are much faster, not only due to the parallel execution but also manual optimizations. We can test these against the reference implementation, within rounding error.

This is isolated in a few classes, though, and 95% of the code is still identical. Which class is used is a simple compile-time choice based on target CPU.

One thing I would add here is that on the performance topic, I have encountered in my career far more code that some engineer thought might be performance critical and over-engineered an unreadable solution for, than code that was actually performance critical. (And we do have actual performance critical code where I work now). In general, I strongly recommend writing code to be a clear as possible. Only when you have a performance problem do you need to troubleshoot.

Now, troubleshooting performance hot spots is a valuable skill to learn and one a lot of developers do not have patience for. I know earlier this year, we had a performance issue with one of our products and for months various engineers would guess what was wrong and optimize that path, and invariably the issue would not be resolved or only be resolved in a very small subset of cases. Finally I got assigned it and actually spent some real time figuring out where we were spending our time (and documenting it) so that we could actually implement a real fix that addressed the the problem which was completely unrelated to what everyone was guessing the problem was.

On another topic you touched on: In practice if I see commented out code, I always have to question whether someone left something unfinished. In code I am responsible for, that is a hard no: you never leave commented out code lying around, it just confuses future developers.

In rare cases (like every couple of years or so) I am refactoring some legacy code where I think that maybe the refactor would cause us to lose some knowledge that we don't want to relearn. In those cases, I use our version control system to tag the previous revision of software and add a comment like: "This code previously used to connect to service "X" to perform its job. Connecting to "X" is a bit complex, if you want to see an example of how to do it please look at tag "Y" in git for an example of how we use to do this."

There are several more case not covered so far when several versions of the code maintained for some time or forever: reference implementations, dark launches, backward compatibility and versioned APIs. Usually for all these cases only small part of a product/service have multiple implementations - so the answer is it's unlikely for whole code base to be duplicated and maintained, but having multiple implementations of small pieces of functionality is very common, especially for products that have many customers.

In case of reference implementation it is unlikely the code will be in the same code base. I.e. people who wrote a standard for some feature like encryption may provide an implementation that is clear but slow and implementers of the standard for different libraries will have they own versions targeting different languages or platforms with different implementations. Another visible case of reference implementation is testing site like leetcode which have reference code for all problems to run against code submitted by users - again code maintained by different people in different places.

Dark launches in case of updates to the existing features usually implemented in the exact way described in the question (also again usually for a tiny part of the code base) - two variants of the code exist at the same time, and which one is executed is selected based on some condition at run-time. Unlike reference implementation usually the goal it to either pick better variant (A/B testing) or eventually replace the old one (rolling out new version). Making sure that unused version is removed requires process so... and if such process is missing/broken one will end up with multiple variants of the same code that had to be maintained.

The backward compatibility can be implemented in multiple ways and one of the ways is indeed to keep both old and new versions forever in the live code and maintain both forever allowing customers of the code to pick variant using some sort of switches at run-time. In extreme cases one may end up with multiple active versions of "the same" code that are maintained in parallel for a long time - as an example python2 vs. python3 or quirks mode in browsers can be considered such case.

Versioned API case is somewhat different from one asked in the question (as code explicitly behaves differently), but it is a case where very similar code sometimes had to be written and maintained for some time in the same project to provide incompatible versions of an API if your customers are unable/unwilling to move and there is significant financial benefit (or more likely legal requirement). For services usually there some way to stop "maintain for some time" to turn into "forever", but for applications that expose APIs for extensibility (i.e. AutoCAD, MS Word) keeping of API all variants working as long as possible is critical.

I wanted to flush out Bart's answer a bit.

As Bart noted typically we don't want to maintain multiple versions of code as generally speaking we don't see a return on the extra development effort, but we do have tools that make life easier, specifically:

• We can choose debug or release builds, typically debug builds:
  • Include extra symbols to make it easier to figure out what went wrong.
  • Some languages include additional checks (automatically) to check for accessing data off the end of an array or dereferencing a null pointer.
  • Support Asserts which allow the programmer to state that they believe the state will be a certain way - typically these are removed from release builds.
• Choose compiler optimization levels - reducing the optimization level can make it easier to debug issues.
• Many languages include logging levels, hence more logging can be enabled only when trying to diagnose an issue, optionally a check for a logging level can be use to enter a debug routine, to print a whole bunch of extra details.
• Cache configuration can also be different in production vs development environments.

Especially with Test-Driven-Development one often encounters a fast first solution, and then a reimplementation with more effort, special cases, border cases, extra data structures, paralellism, whatever.

Sometimes (rarely) it may be useful to keep separate implementations of one API. This is true if one implementation uses an embedded database, or is far more general (shorter, less cases) but slower. Those separate implementations may reside in the same code base, as API library and multiple implementation libraries.

Mostly one would keep one single best version. And try to avoid the mistake of leaving "alternative code" commented-out. Version control / local history should suffice.