> Try unravelling that tangled, buggy mess, which looks more like a bowl of angel hair pasta than a finely tuned piece of programming. Industry best practice would have 500 separate files instead. In our commercial reality, we would fire anyone for developing code like this and any business that relied on it to produce software for sale would likely go bust.
Having the code in more or fewer files is orthogonal to how tangled the code is. Files are just containers for classes/functions. In most cases it makes no difference to the architecture of a system over how many files the code is split.
> The approach ignores widely accepted computer science principles known as "separation of concerns", which date back to the early 70s and are essential to the design and architecture of successful software systems. The principles guard against what developers call CACE: Changing Anything Changes Everything.
Again, one doesn't separate concerns over files. You can have code split over 500 files and still have a very nasty case of CACE.
> Without this separation, it is impossible to carry out rigorous testing of individual parts to ensure full working order of the whole. Testing allows for guarantees. It is what you do on a conveyer belt in a car factory. Each and every component is tested for integrity in order to pass strict quality controls.
At the lower levels, one tests functions or classes, not files, so I don't get the argument he is trying to make that the code is not split in enough files.
I agree that some of these distinctions are correlative, not causative, but I think the number of files argument is valid for one reason: navigation. Files are effectively pointers to ranges within a code base. Without them, you’re left jumping through a huge codebase by searching or scrolling.
Even in languages with one class/file convention I find navigating using the IDE's symbol search functionality preferable to navigating using files – especially in huge codebases. YMMV.
I don’t disagree if the language is OO such that classes have reasonable functionality contained within them. But searching through many many functions because very disorienting. Just my $0.02 of course
> Imperial’s model appears to be based on a programming language called Fortran, which was old news 20 years ago and, guess what, was the code used for Mariner 1.
So the model is bad because Fortran is old/ducks and an otherwise unrelated Project using Fortran failed. Boo Fortran, boo! You're old news!
The size of the file is a red herring. Has the work been done to analyze and test the subroutines? How many lines are intricate logic, and how many are embedded data? How prevalent are references to global variables across subroutines? Are the global variables used as constants? How much is new code, and how much is code that has produced robust results for years?
Yes, they don't discuss the model itself. Perhaps unsurprisingly, given that their credentials are in software:
> First though, a few words on our credentials. I am David Richards, founder and chief executive of WANdisco, a global leader in Big Data software that is jointly headquartered in Silicon Valley and Sheffield. My co-author is Dr Konstantin ‘Cos’ Boudnik, vice-president of architecture at WANdisco, author of 17 US patents in distributed computing and a veteran developer of the Apache Hadoop framework that allows computers to solve problems using vast amounts of data.
I'm not a subscriber and only read the intro preview. That's enough to mention a few comments, which perhaps are explained more in-depth later?
> "helped persuade the UK and other countries to bring in draconian lockdowns"
Sure, but other countries too have their own models. If something is one of, say, 20 different models from 20 different organizations, all in reasonable agreement, then isn't "help persuade" ... a good thing?
Even if it's crappy looking code on the surface?
> "could go down in history as the most devastating software mistake of all time, in terms of economic costs and lives lost."
How are "lives lost" measured?
And, wouldn't the Reinhart-Rogoff spreadsheet error also be significant, in how it supported "austerity" policies around the world?
In the 5-whys analysis, a follow-up question might be, why does the UK government depend on academic code for this, rather than having their own full-time/career public health professionals and software developers working on it?
My ill-informed belief is that it's because austerity efforts caused widespread cutbacks in the government's ability to plan for these sorts of contingencies. If so, the Reinhart-Rogoff spreadsheet error is a more devastating software mistake.
9 comments
[ 4.1 ms ] story [ 33.5 ms ] threadHaving the code in more or fewer files is orthogonal to how tangled the code is. Files are just containers for classes/functions. In most cases it makes no difference to the architecture of a system over how many files the code is split.
> The approach ignores widely accepted computer science principles known as "separation of concerns", which date back to the early 70s and are essential to the design and architecture of successful software systems. The principles guard against what developers call CACE: Changing Anything Changes Everything.
Again, one doesn't separate concerns over files. You can have code split over 500 files and still have a very nasty case of CACE.
> Without this separation, it is impossible to carry out rigorous testing of individual parts to ensure full working order of the whole. Testing allows for guarantees. It is what you do on a conveyer belt in a car factory. Each and every component is tested for integrity in order to pass strict quality controls.
At the lower levels, one tests functions or classes, not files, so I don't get the argument he is trying to make that the code is not split in enough files.
So the model is bad because Fortran is old/ducks and an otherwise unrelated Project using Fortran failed. Boo Fortran, boo! You're old news!
> First though, a few words on our credentials. I am David Richards, founder and chief executive of WANdisco, a global leader in Big Data software that is jointly headquartered in Silicon Valley and Sheffield. My co-author is Dr Konstantin ‘Cos’ Boudnik, vice-president of architecture at WANdisco, author of 17 US patents in distributed computing and a veteran developer of the Apache Hadoop framework that allows computers to solve problems using vast amounts of data.
> "helped persuade the UK and other countries to bring in draconian lockdowns"
Sure, but other countries too have their own models. If something is one of, say, 20 different models from 20 different organizations, all in reasonable agreement, then isn't "help persuade" ... a good thing?
Even if it's crappy looking code on the surface?
> "could go down in history as the most devastating software mistake of all time, in terms of economic costs and lives lost."
How are "lives lost" measured?
And, wouldn't the Reinhart-Rogoff spreadsheet error also be significant, in how it supported "austerity" policies around the world?
In the 5-whys analysis, a follow-up question might be, why does the UK government depend on academic code for this, rather than having their own full-time/career public health professionals and software developers working on it?
My ill-informed belief is that it's because austerity efforts caused widespread cutbacks in the government's ability to plan for these sorts of contingencies. If so, the Reinhart-Rogoff spreadsheet error is a more devastating software mistake.