I’m in agreement that what this article puts forth is more of what has been rejected already, but I think it’s a mistake to ignore it simply because it is fashionable and simple to dump on any attempt at formality in software.
I read that article and I came away thinking it’s the next attempt by managers to produce better project management, not better software. That said, there’s some stuff that the developer community should think about:
“In the end, however, a craft discipline can take you only so far.”
“As a craft develops into an engineering discipline, it is important to recognize commonality between the methods of various masters, based on the underlying shared experience of the endeavor being carried out. This common understanding is then captured in a theory that can be used as a basis for all the different methods to be applied to the endeavor.”
“A method may appear monolithic, but any method may be analyzed as being composed of a number of practices. A practice is a repeatable approach to doing something with a specific purpose in mind. Practices are the things that practitioners actually do.”
I want to reject this article because it uses poor analogies (skyscrapers) and trumped up language (another paradigm shift!), but there is certainly some truth to it. In fact, I have to think that there is something better than the current state of affairs, which seems to be a lot of intuition and praying to the god of StackOverflow.
And it is somewhat concerning that “I’m going to ask on StackOverflow” is an acceptable thing in software development. You would never hear a civil engineer say, “I don’t know if this beam will work on the bridge, I’m going to ask on the internet.”
But the more I think about it, it seems a large part of it boils down to the relative triviality of most software. Most engineering disciplines have far more serious repercussions for failure. If my iPhone game crashes or the website I’m visiting temporarily returns 500 it’s really not a huge deal in the grand scheme of things - nobody’s going to die, nothing is going to short circuit and catch on fire. I’ll restart, and that’s it.
Software that has serious real world repercussions does usually have more strict project management and more disciplined adherence to software engineering “best practices.” If people want to improve and standardize those, then I’m all for it. But I don’t think those techniques will ever be used for all software development.
Actually, that’s not correct. Typically the engineering firm who designs the bridge is also highly involved in the construction, so much so that they’re often the same company. All of the problems you mention WOULD be blamed on the engineering company, and they would almost certainly be found liable. In fact, it even goes above and beyond that in some cases, with the final responsibility being on the individual engineer who signs off on the project and its changes: https://en.wikipedia.org/wiki/Regulation_and_licensure_in_engineering
Your second paragraph pretty much sums up the problem, IMO. No other engineering disciplines would tolerate those things. It should be part of a software engineer’s job to make sure the tools used are adequate, the project is well specified, the hardware is adequate, the expected lifetime is realistic, etc. That’s par for the course in every other engineering discipline.
Ok, I’m sorry, I shouldn’t post when I have a migraine. I’m less than pleasant.
So let me try again.
Why did I react so negatively to it?
I couldn’t put my finger on any paragraph that I would want to show to anybody I knew.
I think we are all eminently aware of the strengths and weaknesses of our “craft”, but we are looking for practical ways forward.
This paper didn’t give any. It also gave me a cold shiver that I would start to see some of this meaningless waffle appearing in clumsy “merit assessments” and “role descriptions”.
We must do something
This is something
Therefore, we must do this.
Or worse, it feels like the Manager’s Syllogism….
Manager's get paid more.
Manager's must be important.
Management must be important.
Therefore the solution to the problem must be more Management.
Except Management should be view like Optimization. The best performing teams I have ever seen had no managers. (Manager’s absent, visiting clients, resigned…)
The rule with Optimization is “No code is faster than no code.”
The rule with management is “No management intervention is more effective than the one that results in the team needing no management.”
We have this tiresome harkening back to “scientific engineering principles”.
Except software engineering has more in common with psychiatry than the newtonian physics behind civil engineering.
Now that is a productive chain of thought.
Stop using the word “Software Engineering”, use “Software Psychiatry” instead.
Think of any proposed, tool, method or practice.
Does it work?
How would you know?
The problem of finding out is very analogous to finding out whether a new anti-depressant works.
Problem 1.
Is the problem the propose method or process or tool addresses well defined?
Do the users of this treatment agree on what the problem is? If you have N patients and M doctors and P diagnoses… Do all the Doctors give the same patients the same diagnosis? If not…. Well, you have a problem Right There! (Hint: Psychiatrists are proven lousy at this, hardly better than random, and “software psychiatrists” I bet are even worse…. except unlike real psychiatrists, nobody has done the studies!)
Problem 2. How do we know what “Better” is?
Do we have an objective measure? Does everybody who measures it agree it’s better, and comes up with the same result?
In software engineering we haven’t even got the formal equivalent of the Hamilton Rating Scale for Depression…. an instrument a chemist or engineer would scorn, but is the mainstay of modern Psychiatry.
Problem 3. Like the Dismal science of population nutrition…. there are no placebo’s in software psychiatry (or dietary advice).
The placebo (and nocebo) effect is very very real. Yet so called software engineering hardly ever controls for it!
Problem 4. Compliance Issues.
In medicine there is a range of certainty from “Doctor injects treatment”, to “Patient takes pill in doctors presence” to “Patient takes pills at home” to “Patient modifies life long ingrained habits and reports back whether he has.”
Almost all Software Psychiatry interventions have compliance issues at the “Patient modifies life long ingrained habits and reports back whether he has” end of the scale.
Problem 5. No “double blind” randomize clinical trials.
All and every intervention is a tiny secondary effect compare to the characteristics of the actual people you have in hand, on that day, to do the work. At best you can hire someone different. From the pool of applicants available on that day.
Oh gawd.
Please. Please please let this whole initiative die in fire, be buried under a mound of manure and forgotten.
It’s so deep into “The Dilbert Zone” I actually feel physically nauseous reading it.
Sigh! I’m sure the PHB’s are going to love it.
I’m in agreement that what this article puts forth is more of what has been rejected already, but I think it’s a mistake to ignore it simply because it is fashionable and simple to dump on any attempt at formality in software.
I read that article and I came away thinking it’s the next attempt by managers to produce better project management, not better software. That said, there’s some stuff that the developer community should think about:
I want to reject this article because it uses poor analogies (skyscrapers) and trumped up language (another paradigm shift!), but there is certainly some truth to it. In fact, I have to think that there is something better than the current state of affairs, which seems to be a lot of intuition and praying to the god of StackOverflow.
It’s definitely something to think about.
And it is somewhat concerning that “I’m going to ask on StackOverflow” is an acceptable thing in software development. You would never hear a civil engineer say, “I don’t know if this beam will work on the bridge, I’m going to ask on the internet.”
But the more I think about it, it seems a large part of it boils down to the relative triviality of most software. Most engineering disciplines have far more serious repercussions for failure. If my iPhone game crashes or the website I’m visiting temporarily returns 500 it’s really not a huge deal in the grand scheme of things - nobody’s going to die, nothing is going to short circuit and catch on fire. I’ll restart, and that’s it.
Software that has serious real world repercussions does usually have more strict project management and more disciplined adherence to software engineering “best practices.” If people want to improve and standardize those, then I’m all for it. But I don’t think those techniques will ever be used for all software development.
[Comment removed by author]
Actually, that’s not correct. Typically the engineering firm who designs the bridge is also highly involved in the construction, so much so that they’re often the same company. All of the problems you mention WOULD be blamed on the engineering company, and they would almost certainly be found liable. In fact, it even goes above and beyond that in some cases, with the final responsibility being on the individual engineer who signs off on the project and its changes: https://en.wikipedia.org/wiki/Regulation_and_licensure_in_engineering
Your second paragraph pretty much sums up the problem, IMO. No other engineering disciplines would tolerate those things. It should be part of a software engineer’s job to make sure the tools used are adequate, the project is well specified, the hardware is adequate, the expected lifetime is realistic, etc. That’s par for the course in every other engineering discipline.
Ok, I’m sorry, I shouldn’t post when I have a migraine. I’m less than pleasant.
So let me try again.
Why did I react so negatively to it?
I couldn’t put my finger on any paragraph that I would want to show to anybody I knew.
I think we are all eminently aware of the strengths and weaknesses of our “craft”, but we are looking for practical ways forward.
This paper didn’t give any. It also gave me a cold shiver that I would start to see some of this meaningless waffle appearing in clumsy “merit assessments” and “role descriptions”.
It feels to me like the “Politicians Syllogism”
Or worse, it feels like the Manager’s Syllogism….
Except Management should be view like Optimization. The best performing teams I have ever seen had no managers. (Manager’s absent, visiting clients, resigned…)
The rule with Optimization is “No code is faster than no code.”
The rule with management is “No management intervention is more effective than the one that results in the team needing no management.”
We have this tiresome harkening back to “scientific engineering principles”.
Except software engineering has more in common with psychiatry than the newtonian physics behind civil engineering.
Now that is a productive chain of thought.
Stop using the word “Software Engineering”, use “Software Psychiatry” instead.
Think of any proposed, tool, method or practice.
Does it work?
How would you know?
The problem of finding out is very analogous to finding out whether a new anti-depressant works.
Problem 1.
Is the problem the propose method or process or tool addresses well defined?
Do the users of this treatment agree on what the problem is? If you have N patients and M doctors and P diagnoses… Do all the Doctors give the same patients the same diagnosis? If not…. Well, you have a problem Right There! (Hint: Psychiatrists are proven lousy at this, hardly better than random, and “software psychiatrists” I bet are even worse…. except unlike real psychiatrists, nobody has done the studies!)
Problem 2. How do we know what “Better” is?
Do we have an objective measure? Does everybody who measures it agree it’s better, and comes up with the same result?
In software engineering we haven’t even got the formal equivalent of the Hamilton Rating Scale for Depression…. an instrument a chemist or engineer would scorn, but is the mainstay of modern Psychiatry.
Problem 3. Like the Dismal science of population nutrition…. there are no placebo’s in software psychiatry (or dietary advice).
The placebo (and nocebo) effect is very very real. Yet so called software engineering hardly ever controls for it!
Problem 4. Compliance Issues.
In medicine there is a range of certainty from “Doctor injects treatment”, to “Patient takes pill in doctors presence” to “Patient takes pills at home” to “Patient modifies life long ingrained habits and reports back whether he has.”
Almost all Software Psychiatry interventions have compliance issues at the “Patient modifies life long ingrained habits and reports back whether he has” end of the scale.
Problem 5. No “double blind” randomize clinical trials.
Problem 6. The big one.
http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development
All and every intervention is a tiny secondary effect compare to the characteristics of the actual people you have in hand, on that day, to do the work. At best you can hire someone different. From the pool of applicants available on that day.