Well, when software engineering is as good for one's personal social life as being an athlete, perhaps I'll buy your argument. :)
More seriously, I see what you're saying--that said, there is a huuuuge difference between how we develop software now versus even five years ago, much less ten or twenty.
Github. Stack Overflow. Agile methods (ugh). Lean methodologies. Various testing methodologies. Changes in the funding structure of companies. Order of magnitude increase (comfortably) in debugging tools for web and network applications. The entire single-page browser app movement. The entire GPGPU movement. Truly convenient and open collaborative coding platforms.
The field, and the people in it, have changed a great deal, and we've learned a lot. I'm increasingly skeptical of professors of professional software engineering who don't, as a day job, professionally engineer software. This applies to other folks--and I mean this nicely--like Uncle Bob or Martin Fowler as well.
Folks like Carmack who have been pushing the envelope and getting scarred the hard way for 20 years are probably simply better sources of learning.
TDD and agile are both about 15 years old, and both built on well-established pre-existing development patterns. Github doesn't change many of the fundamentals of how software improves in quality or how development works.
What I've observed in the industry has been a shocking lack of self-awareness about application of best practices, and decidedly half-assed attempts to improve. The state of the industry is not dev shops on the bleeding edge of the best tools, best methodologies, best policies, etc. It's almost universally a tale of failing to even get to "ok" in terms of well-known best (or even better) practices. There are a ton of dev shops that don't do any code reviews at all, and formal code reviews (which have been shown to be one of the best methods for improving code quality) are almost unheard of. Even at places that take testing seriously or do TDD they still typically don't do it very well.
That's why folks like Uncle Bob and Martin Fowler continue to have so much traction in the industry, because simply following good advice that was old 20 years ago is still a huge step forward for the average, or even above average, dev shop in the industry today.
Saying "we've learned a lot" just tells me that I shouldn't take you seriously, because clearly we haven't. Software dev. is still a shambles. Security is still a nightmare. Performance is still a nightmare. Quality and robustness is still a nightmare. Work/life balance is still a nightmare.
Reading books like "The Mythical Man Month" (which is 40 years old!) still holds a ton of lessons that have yet to be taken to heart by the majority of the industry.
It's really only relevant when someone is passing down personal wisdom based on their own experiences (like John is).
Capers is conducting and providing research findings and so we should care about his research abilities, and the evidence he presents. His personal software development abilities aren't important.
I think that it is completely reasonable to question the applicability of any operations research conducted by people who aren't themselves intimately embedded in the current practice of the fields they're commenting on.
I believe that because I find there to be a lot of dynamics in software development that are seemingly completely unaccounted for in the literature. I admit that this may be because I'm unfamiliar with the current edge of the research being done, but then again, research does tend to lag rather far behind the state-of-the-art, and our field moves quickly.
Is that really true in terms of organisational structure, communication patterns, team sizes, management structure, or best practices?
Tooling has improved significantly across the board but, for the most part, it has improved and refined existing patterns and processes rather than enabling radically different/novel practices.
The two major differences, IMO, over the last 15 years have been in 1) remote work and 2) the ops space.
On 1) Better tooling has really made remote work viable in many places it didn't use to be. And many companies are starting to take advantage of it.
On 2) the real improvement here the power shift from ops to development. When I first started working in software I was frequently blocked from experimenting by the ops team. These days Ill fire up a few dynos, try out my idea, and then if it works bring the ops team on-board. The workflow itself has significantly changed.
First of all, we still haven't settled on a set of common abstractions and tools for the industry--so much reinvention happens that most projects can almost be considered bespoke every time. There is no common and simple way of estimating development time. There is no common and effective way of accrediting engineers. There is no commonly-understood legal liability and responsibility for software engineers. Frankly, any schmuck who decides to smoosh jQuery libraries together can claim to be just as much of an engineer as a high-end PhD or person with decades of experience--and the nature of the work is such that, quite frankly, that schmuck may deliver more value than their more experienced counterparts.
That said, the technology on which we are deploying has changed a great deal in the last forty years. Orders of magnitude increase in both processing speed, secondary storage, and memory have made a lot of formerly unthinkable approaches commonplace. The problems we face in terms of networked systems and security concerns are far different and more ubiquitous than they've ever been.
If the fundamentals of software engineering haven't changed, we shouldn't take ourselves seriously at all.
That doesn't speak of advancement, it speaks of stagnation for the most part.
And sure, technology has changed, some ways of doing things are different, but the core software engineering fundamentals haven't changed that much.
Take a classic book that is definitely showing its age, Code Complete, and look at what that book has to say about what the fundamental nature of software projects is: managing complexity. That's still true and will always be true, that's what software is all about. As I pointed out in another comment, you could go back even further to a book like The Mythical Man Month and find tons of lessons that are still applicable today. Because despite all the technological advancement that's happened, the fundamental practice of software engineering has not advanced much. "Agile" is just a way to make sure that a team is able to do anything at all and actually ship something that works and is not miles away from what the customer wants. Agile isn't an advanced technique, it's a rudimentary technique to rescue potentially failing projects/teams.
And security? Security is more important than ever. But what does that mean? That means that dev shops follow, oh, say 10% of the most important security best practices instead of 1% or 0% as they might have done 20 years ago. And it means you have to protect against a few specific kinds of attack vectors that were previously unknown. But that's not a sea-change in the way things are done, it's just incremental changes to details.
Comments
Thanks for the reading suggestion!
That said, it seems that his last practical experience in the field was better than two decades ago ( https://en.wikipedia.org/wiki/Capers_Jones ).
A criticism of that sort is available to other folks as well--I feel compelled to ask, "Interesting results, but what have you shipped recently?"
Don't you think this is a bit like not listening to coaches or sports medicine experts because they haven't been professional players in two decades?
Well, when software engineering is as good for one's personal social life as being an athlete, perhaps I'll buy your argument. :)
More seriously, I see what you're saying--that said, there is a huuuuge difference between how we develop software now versus even five years ago, much less ten or twenty.
Github. Stack Overflow. Agile methods (ugh). Lean methodologies. Various testing methodologies. Changes in the funding structure of companies. Order of magnitude increase (comfortably) in debugging tools for web and network applications. The entire single-page browser app movement. The entire GPGPU movement. Truly convenient and open collaborative coding platforms.
The field, and the people in it, have changed a great deal, and we've learned a lot. I'm increasingly skeptical of professors of professional software engineering who don't, as a day job, professionally engineer software. This applies to other folks--and I mean this nicely--like Uncle Bob or Martin Fowler as well.
Folks like Carmack who have been pushing the envelope and getting scarred the hard way for 20 years are probably simply better sources of learning.
TDD and agile are both about 15 years old, and both built on well-established pre-existing development patterns. Github doesn't change many of the fundamentals of how software improves in quality or how development works.
What I've observed in the industry has been a shocking lack of self-awareness about application of best practices, and decidedly half-assed attempts to improve. The state of the industry is not dev shops on the bleeding edge of the best tools, best methodologies, best policies, etc. It's almost universally a tale of failing to even get to "ok" in terms of well-known best (or even better) practices. There are a ton of dev shops that don't do any code reviews at all, and formal code reviews (which have been shown to be one of the best methods for improving code quality) are almost unheard of. Even at places that take testing seriously or do TDD they still typically don't do it very well.
That's why folks like Uncle Bob and Martin Fowler continue to have so much traction in the industry, because simply following good advice that was old 20 years ago is still a huge step forward for the average, or even above average, dev shop in the industry today.
Saying "we've learned a lot" just tells me that I shouldn't take you seriously, because clearly we haven't. Software dev. is still a shambles. Security is still a nightmare. Performance is still a nightmare. Quality and robustness is still a nightmare. Work/life balance is still a nightmare.
Reading books like "The Mythical Man Month" (which is 40 years old!) still holds a ton of lessons that have yet to be taken to heart by the majority of the industry.
"but what have you shipped recently?"
Looks like he has shipped 14 books and at least 36 papers on software engineering methodologies.
Why is that relevant?
It's really only relevant when someone is passing down personal wisdom based on their own experiences (like John is).
Capers is conducting and providing research findings and so we should care about his research abilities, and the evidence he presents. His personal software development abilities aren't important.
I think that it is completely reasonable to question the applicability of any operations research conducted by people who aren't themselves intimately embedded in the current practice of the fields they're commenting on.
I believe that because I find there to be a lot of dynamics in software development that are seemingly completely unaccounted for in the literature. I admit that this may be because I'm unfamiliar with the current edge of the research being done, but then again, research does tend to lag rather far behind the state-of-the-art, and our field moves quickly.
"and our field moves quickly."
Is that really true in terms of organisational structure, communication patterns, team sizes, management structure, or best practices?
Tooling has improved significantly across the board but, for the most part, it has improved and refined existing patterns and processes rather than enabling radically different/novel practices.
The two major differences, IMO, over the last 15 years have been in 1) remote work and 2) the ops space.
On 1) Better tooling has really made remote work viable in many places it didn't use to be. And many companies are starting to take advantage of it.
On 2) the real improvement here the power shift from ops to development. When I first started working in software I was frequently blocked from experimenting by the ops team. These days Ill fire up a few dynos, try out my idea, and then if it works bring the ops team on-board. The workflow itself has significantly changed.
I feel compelled to ask, do you think the fundamentals of software engineering have changed so much?
Of course!
First of all, we still haven't settled on a set of common abstractions and tools for the industry--so much reinvention happens that most projects can almost be considered bespoke every time. There is no common and simple way of estimating development time. There is no common and effective way of accrediting engineers. There is no commonly-understood legal liability and responsibility for software engineers. Frankly, any schmuck who decides to smoosh jQuery libraries together can claim to be just as much of an engineer as a high-end PhD or person with decades of experience--and the nature of the work is such that, quite frankly, that schmuck may deliver more value than their more experienced counterparts.
That said, the technology on which we are deploying has changed a great deal in the last forty years. Orders of magnitude increase in both processing speed, secondary storage, and memory have made a lot of formerly unthinkable approaches commonplace. The problems we face in terms of networked systems and security concerns are far different and more ubiquitous than they've ever been.
If the fundamentals of software engineering haven't changed, we shouldn't take ourselves seriously at all.
That doesn't speak of advancement, it speaks of stagnation for the most part.
And sure, technology has changed, some ways of doing things are different, but the core software engineering fundamentals haven't changed that much.
Take a classic book that is definitely showing its age, Code Complete, and look at what that book has to say about what the fundamental nature of software projects is: managing complexity. That's still true and will always be true, that's what software is all about. As I pointed out in another comment, you could go back even further to a book like The Mythical Man Month and find tons of lessons that are still applicable today. Because despite all the technological advancement that's happened, the fundamental practice of software engineering has not advanced much. "Agile" is just a way to make sure that a team is able to do anything at all and actually ship something that works and is not miles away from what the customer wants. Agile isn't an advanced technique, it's a rudimentary technique to rescue potentially failing projects/teams.
And security? Security is more important than ever. But what does that mean? That means that dev shops follow, oh, say 10% of the most important security best practices instead of 1% or 0% as they might have done 20 years ago. And it means you have to protect against a few specific kinds of attack vectors that were previously unknown. But that's not a sea-change in the way things are done, it's just incremental changes to details.