A New Software Engineering
queue.acm.org
A New Software Engineering
1–10 of 94 posts
Re: A New Software Engineering
#2"Engineering" is only possible in the physical world because the laws of physics don't change every thirty years or so. In software, we aren't so lucky. Bridge-building best practices from the 1950s would build a fine bridge today. Software development practices from the 80s would get you... basically nowhere.
Re: A New Software Engineering
#3"Engineering" is only possible in the physical world because the laws of physics don't change every thirty years or so. In software, we aren't so lucky. Bridge-building best practices from the 1950s would build a fine bridge today. Software development practices from the 80s would get you... basically nowhere.
I think you both a) are greatly unfamiliar with bridge building practices and b) underestimate the ability of 1980s software design.
Seriously, were there shortcomings in the software design of yesteryear? Almost certainly. Are they blown vastly out of proportion in most discussions? My assertion is that they are.
Sadly, I do not know as that I have anything coherent to offer on how to fix things. What I can offer is that I think we'd do better by not always looking across the horizon to a silver bullet language/framework/whatever and keep focused on what the job at hand requires. The amount of failures I have witnessed due to a desire to over generalize is staggering.
Re: A New Software Engineering
#4This starts out talking about engineering having a "theory" to work with, meaning physics, materials science, etc., that is the source of its ability to construct new reliable systems.
Then it proposes a mechanism to develop a "theory" of software engineering where the generated theory seems to consist entirely of methods of project management.
Am I completely missing the point of the article? Because that doesn't seem at all parallel. Engineering has methods of project management too, but that's not what makes bridges not fall down.
Re: A New Software Engineering
#5"Engineering" is only possible in the physical world because the laws of physics don't change every thirty years or so. In software, we aren't so lucky. Bridge-building best practices from the 1950s would build a fine bridge today. Software development practices from the 80s would get you... basically nowhere.
I think you both a) are greatly unfamiliar with bridge building practices and b) underestimate the ability of 1980s software design. Seriously, were there shortcomings in the software design of yesteryear? Almost certainly. Are they blown vastly out of proportion in most discussions? My assertion is that they are. Sadly, I do not know as that I have anything coherent to offer on how to fix things. What I can offer is…
But the assertion is that bridges could be built today using techniques from the 1950's, and they would still be good bridges, because the principles and physical laws they were built on haven't changed.
Software design had a lot of cool things happening in the 1980's (possibly more in the 1970's, though), but the mindset has shifted since then. How many people are implementing their own VM's? How many are running on non x86 intel/amd chipsets? Things that needed to be heavily optimized in the early 80's might actually run faster now with JIT & whole-program optimizations. And so on.
It's hard to build an engineering discipline out of such a shifting substrate.
Re: A New Software Engineering
#6Earlier quoted context omitted.
I think you both a) are greatly unfamiliar with bridge building practices and b) underestimate the ability of 1980s software design. Seriously, were there shortcomings in the software design of yesteryear? Almost certainly. Are they blown vastly out of proportion in most discussions? My assertion is that they are. Sadly, I do not know as that I have anything coherent to offer on how to fix things. What I can offer is…
But the assertion is that bridges could be built today using techniques from the 1950's, and they would still be good bridges, because the principles and physical laws they were built on haven't changed. Software design had a lot of cool things happening in the 1980's (possibly more in the 1970's, though), but the mindset has shifted since then. How many people are implementing their own VM's? How many are running on…
And I disagree with this assertion. Heavily. Simply look at the state of most bridges in the US (and elsewhere?) to see that they are not holding up nearly as well as is implied by this assertion.
I don't know what to say regarding your examples. Don't put too much credit in JIT and whole-program optimizations. One could just as easily point to the fact that what used to be too slow of a program is now fast enough with the advance of computing speed. And memory. Do not overlook the importance of memory.
More, I doubt most programs of yesteryear failed due to lack of optimization. Seems likely to me, that the main cause of software failure has not changed that heavily in the years.
Re: A New Software Engineering
#7This starts out talking about engineering having a "theory" to work with, meaning physics, materials science, etc., that is the source of its ability to construct new reliable systems. Then it proposes a mechanism to develop a "theory" of software engineering where the generated theory seems to consist entirely of methods of project management. Am I completely missing the point of the article? Because that doesn't se…
What is the equivalent in other fields that build things? I mean, project management must be studied in other disciplines, and what have they come up with?
Re: A New Software Engineering
#8Software is more a design activity than an engineering activity. In the construction world it would be more like architecture than civil engineering. Architecture in the sense that you do need technical knowledge but it's much more about thinking about how do we design a building for people who are engaged in certain activities. What are their needs. How does it fit in with its environment etc. Soft things. Burt difficult things nonetheless. In a way the work of the civil engineer is done for software by the language, library, OS and browser developers (and the hardware people obviously)
Re: A New Software Engineering
#9This starts out talking about engineering having a "theory" to work with, meaning physics, materials science, etc., that is the source of its ability to construct new reliable systems. Then it proposes a mechanism to develop a "theory" of software engineering where the generated theory seems to consist entirely of methods of project management. Am I completely missing the point of the article? Because that doesn't se…
What is the equivalent in other fields that build things? I mean, project management must be studied in other disciplines, and what have they come up with?
The article points out in the beginning that borrowing project management practices from other disciplines is what we tried to do (which gave us The Waterfall method) and it doesn't work.
That said, I agree with the GP in that I was expecting more focus on actual software matters, like how to test the reliability of a system before it's built etc.
Re: A New Software Engineering
#10Another silver bullet in the making.
I don't mean to be rude but to me it's pure BS. A grand plan, a conclusion talking about paradigm shifts, and no substance at all. Seeing the method co-signed by Robert Martin even made me chuckle a little. I guess we're on for a second round.
This is clearly meant for management (again) and doesn't give a hint of a clue to what is the practice of software engineering.
Won't they ever understand (I use they on purpose as they're clearly not us) that software engineering is the process of discovering and documenting in a formal language the methods to be applied to solve a problem defined in an ambiguous natural language with the use of imprecise concepts. What we really do is assess the validity and feasibility of what an user wants, and along the way refit concepts, articulate them in a way that can actually work or formally make sense. Building software is the act of understanding how the implicit things we take for granted are actually not. This is a discovery process. This precludes precise estimates or estimates at all, which is very difficult to finally accept and live with, I concur. It has to be dealt with in most cases or in a large part like a research endeavour.
We'll have some day to take things at face value and learn to live with them.