Capability
May. 30th, 2017 09:12 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
jsburbidgeA few days ago I was looking into some roughly seven or eight year old production C++ code, and saw, basically, the following (the only thing I have changed is the function name):
try {
doSomething();
} catch (...) {
throw;
}
It is, enough to make one despair, because although I have seen worse code - this at least introduces no bugs - I have never seen anything that more clearly shows that the author had no idea what the hell he was doing. (The problem being that the effect is exactly the same as not putting in a try/catch block at all; it shows that the writer failed to understand in any real sense either the mechanisms nor the rationale for the use of exceptions.)
As a piece of cargo-cult programming it belongs with this, also from the same codebase:
~Foo() {
try {
delete m_bar;
} catch(...) {
}
}
Here, the author has been told that exceptions should never be thrown from inside a destructor, and has possibly been exposed to the idiom that surrounds generalised cleanup functions (like close()) with try/catch blocks in destructors to avoid it. He - it was a he, there were no women on the team that produced this - does not seem to have internalised the ability to make the judgement that when you are calling delete, if the class is yours you should be hewing to the above stated standard and if it's not you should drop it like a hot potato if it throws from a destructor. (The member class pointer was to another class in the same library.) There is no need to guard a call to delete with a try / catch block; if it throws an exception you are probably already screwed (corrupted heap, or something equally bad).
The same codebase betrays a failure to grasp polymorphism, const-correctness, the use of initializer lists, the Law of Demeter, design patterns, data hiding, package dependencies, global data use, and so forth. The code base dates from no later than 2008: it might be permissible in code from 1990.
This is massively depressing.
I am no great defender of the modern rush towards credentialism and the move of the universities to become glorified trade schools for their students - my undergraduate university syllabus is now full of departments of humane letters trying to appeal to undergraduates based on usefulness in the world of employment - and my own background has scrupulously avoided any such thing (I write software with an M.A. In English and an LL.B., which I took out of an interest in law as such). But the one thing which having Computer Science courses is supposed to give us is properly trained and capable graduates. And from what I know organizationally these developers must have been at least CS grads, and very possibly Software Engineering grads.
These are not isolated observations. The majority of the "professional" code I see reflects sheer incapacity. The flaws it has are not those of carelessness, which can happen to anyone - nobody writes bug-free code, and even extensive testing and many eyes cannot be guaranteed to flush out all bugs - but of a sheer unwillingness to think about design or structure. Maintainability as an end is tossed to one side (even otherwise "good" developers seem to feel that there is nothing wrong in adding another 25 lines to a function which is already 500 lines long rather than breaking out, at a minimum, the new code and refactoring towards better modularization). Nobody seems to perform dependency analysis. In 25 years I have from time to time seen lip service paid to code reviews but never seen them actually implemented as general practice.
There are good developers out there; I've worked with some and read books by others. But whatever standards general training is supposed to impose are either too low or breached more often than observed.
This sort of complaint can be focussed just on the local area of software development, in which case it tends to become part of the standard debate about software engineering standards in academy and workplace, usually drawing distinctions between the generation of code and, say, building bridges, with the difference in length of existence of disciplines being adduced. However, I suspect that it is one aspect of a more general pattern, a kind of milder Sturgeon's Law. Certainly I have not known a surfeit of good managers, wide variations in teaching skill are prevalent in the schools, and competent politicians seem to be a vanishing breed (probably always vanishing, as the past is seen by the light of nostalgia: I'm not suggesting that things are getting worse, just that they've always been pretty dispiriting).
Some of this is institutionally driven: it really does make more pragmatic sense in many contexts to fill your required roles with what you can reasonably easily get rather than spending seemingly inordinate amounts of time hunting down significantly more able candidates, after a certain threshold has been passed, and to make the roles to be filled have responsibilities and expectations which can be met by the run-of-the-mill rather than to craft roles around the specific skills of the very good. Interchangeable parts apply to human roles as well as physical components. Likewise, society expects universities to turn out reasonably full classes of graduates rather than putting standards high enough that a significant number of students fail, drop out, or take six years to obtain a bachelor's degree. The intersection of the production rules for human capital and the onboarding rules which govern its corporate deployment can quickly lead to positions being filled with less than ideal employees.
That's not to say that it's right, either. I've seen a number of expensive projects which would have been much cheaper, and faster, if those in charge had been willing to pay to get them right the first time rather than be cheap the first time and have to pay more for a rebuild on the second - or third - try. (These have frequently been cases where an "essential" project has budgetary constraints, so a budget is deliberately confected which comes in just under the limits in time and money, and the rest of the time and money predictably become available once the project is further advanced, due to the sunk cost fallacy's domination over the minds of senior managers.)
Some of it is socially driven. Just as our Deweyan schools are built around social promotion for social at least as much as administrative reasons, so also much of our working world is socially built around the idea that most people are reasonably competent. There's a general attitude that encourages a culture of "good enough" when applied to domains which benefit from expertise.
But we, collectively, pay for it. Shoddy work - in infrastructure, education, management, politics - takes a toll on the lives of all of us, frequently indirectly, occasionally directly.
try {
doSomething();
} catch (...) {
throw;
}
It is, enough to make one despair, because although I have seen worse code - this at least introduces no bugs - I have never seen anything that more clearly shows that the author had no idea what the hell he was doing. (The problem being that the effect is exactly the same as not putting in a try/catch block at all; it shows that the writer failed to understand in any real sense either the mechanisms nor the rationale for the use of exceptions.)
As a piece of cargo-cult programming it belongs with this, also from the same codebase:
~Foo() {
try {
delete m_bar;
} catch(...) {
}
}
Here, the author has been told that exceptions should never be thrown from inside a destructor, and has possibly been exposed to the idiom that surrounds generalised cleanup functions (like close()) with try/catch blocks in destructors to avoid it. He - it was a he, there were no women on the team that produced this - does not seem to have internalised the ability to make the judgement that when you are calling delete, if the class is yours you should be hewing to the above stated standard and if it's not you should drop it like a hot potato if it throws from a destructor. (The member class pointer was to another class in the same library.) There is no need to guard a call to delete with a try / catch block; if it throws an exception you are probably already screwed (corrupted heap, or something equally bad).
The same codebase betrays a failure to grasp polymorphism, const-correctness, the use of initializer lists, the Law of Demeter, design patterns, data hiding, package dependencies, global data use, and so forth. The code base dates from no later than 2008: it might be permissible in code from 1990.
This is massively depressing.
I am no great defender of the modern rush towards credentialism and the move of the universities to become glorified trade schools for their students - my undergraduate university syllabus is now full of departments of humane letters trying to appeal to undergraduates based on usefulness in the world of employment - and my own background has scrupulously avoided any such thing (I write software with an M.A. In English and an LL.B., which I took out of an interest in law as such). But the one thing which having Computer Science courses is supposed to give us is properly trained and capable graduates. And from what I know organizationally these developers must have been at least CS grads, and very possibly Software Engineering grads.
These are not isolated observations. The majority of the "professional" code I see reflects sheer incapacity. The flaws it has are not those of carelessness, which can happen to anyone - nobody writes bug-free code, and even extensive testing and many eyes cannot be guaranteed to flush out all bugs - but of a sheer unwillingness to think about design or structure. Maintainability as an end is tossed to one side (even otherwise "good" developers seem to feel that there is nothing wrong in adding another 25 lines to a function which is already 500 lines long rather than breaking out, at a minimum, the new code and refactoring towards better modularization). Nobody seems to perform dependency analysis. In 25 years I have from time to time seen lip service paid to code reviews but never seen them actually implemented as general practice.
There are good developers out there; I've worked with some and read books by others. But whatever standards general training is supposed to impose are either too low or breached more often than observed.
This sort of complaint can be focussed just on the local area of software development, in which case it tends to become part of the standard debate about software engineering standards in academy and workplace, usually drawing distinctions between the generation of code and, say, building bridges, with the difference in length of existence of disciplines being adduced. However, I suspect that it is one aspect of a more general pattern, a kind of milder Sturgeon's Law. Certainly I have not known a surfeit of good managers, wide variations in teaching skill are prevalent in the schools, and competent politicians seem to be a vanishing breed (probably always vanishing, as the past is seen by the light of nostalgia: I'm not suggesting that things are getting worse, just that they've always been pretty dispiriting).
Some of this is institutionally driven: it really does make more pragmatic sense in many contexts to fill your required roles with what you can reasonably easily get rather than spending seemingly inordinate amounts of time hunting down significantly more able candidates, after a certain threshold has been passed, and to make the roles to be filled have responsibilities and expectations which can be met by the run-of-the-mill rather than to craft roles around the specific skills of the very good. Interchangeable parts apply to human roles as well as physical components. Likewise, society expects universities to turn out reasonably full classes of graduates rather than putting standards high enough that a significant number of students fail, drop out, or take six years to obtain a bachelor's degree. The intersection of the production rules for human capital and the onboarding rules which govern its corporate deployment can quickly lead to positions being filled with less than ideal employees.
That's not to say that it's right, either. I've seen a number of expensive projects which would have been much cheaper, and faster, if those in charge had been willing to pay to get them right the first time rather than be cheap the first time and have to pay more for a rebuild on the second - or third - try. (These have frequently been cases where an "essential" project has budgetary constraints, so a budget is deliberately confected which comes in just under the limits in time and money, and the rest of the time and money predictably become available once the project is further advanced, due to the sunk cost fallacy's domination over the minds of senior managers.)
Some of it is socially driven. Just as our Deweyan schools are built around social promotion for social at least as much as administrative reasons, so also much of our working world is socially built around the idea that most people are reasonably competent. There's a general attitude that encourages a culture of "good enough" when applied to domains which benefit from expertise.
But we, collectively, pay for it. Shoddy work - in infrastructure, education, management, politics - takes a toll on the lives of all of us, frequently indirectly, occasionally directly.
