Software capital

Recently, I’ve been updating my C++ skills. In the far past, I’ve used it to speed up algorithms in scripted languages. However, I have never used it as a standalone programming language. And when I say C++ I think I really mean C, I just happen to compile it with g++. Currently, I have a couple of problems which might change my limited exposure and get me much deeper in C++ code. It’s been interesting to see how many “problems” have been solved by some of the recent major upgrades to C++. Certainly last time I was using C++ I wasn’t using unit testing, although I did some testing informally from the calling language. However, I am now using Catch to do behaviour driven development. As part of the upskilling, as the evening goes on and I’m too tired to do any coding I’ve been watching some videos. The idea of the videos is to get a higher level picture of what has been going on in C++.

David Sankel’s conference presentation (in the video linked above) is interesting even though it’s not that specifically tied to C++. It does however deal with a development frustration - the problem with tech debt. There is a powerful graph (which I’ve now seen several times) that argues in the early days of a software project, incurring technical debt affords a quicker route to market. It then does a great job of explaining why the compound interest on that debt accumulates exponentially fast. The result is that later it is made far slower to ship a product than if you had been addressing tech debt all along. And more constructively, it suggests what to do about this. There is also discussion at the end where some experienced developers share their history, and perhaps it needs to be noted at the time of this presentation David Sankel was working a Bloomberg. Many of the seven recommendations are widely accepted such as unit testing, code review and engineering infrastructure to enable building and system testing. However, one thing it does call for is documentation. This seems significant because many professionals claim that the “code is the documentation”. The counter argument is that in a large and complex software project, it is not feasible to read all the way down to the basic functions to understand what is going on. Well constructed and documented APIs should be all you need to work with. David therefore emphasises the importance of documenting contracts and how they add value. Firstly, to the developer of the underlying code, they serve as a specification for all the tests that are needed to ensure that code behaves as it should. To the developer who is going to call that API, it tells them all they need to know; they don'’t need to understand all the implementation details.

O’Rly satire: R software has been exceptionally well documented from its launch

What was so profoundly interesting to me is that I don’t think anyone would suggest that you learn R as a means of learning computer science. It lets you do amazing stuff with data, advanced models and visualisation. But it has many peculiarities which would rule it out as a place to study computational structures. However, in building R packages you are forced to write documentation for any public functions or datasets. So for all that might be quirky about R, developers are forced to document their contracts, and all users get to read the contracts. That doesn’t mean the software quality is universally high across all the R packages that exist. It’s just interesting that from the offset, R, which has always placed an importance on good scholarly documentation is a case study of how clearly documented contracts can be valued.