Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A New Software Engineering

queue.acm.org

Post reply on HN
Print view View original

11–20 of 94 posts

Re: A New Software Engineering

#11

Post by Nursie »

sgrove wrote: post #5
taeric wrote: post #3

Earlier 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…

They might be good bridges, but they wouldn't necessarily be up to modern safety spec or tolerances, and may not take advantage of new materials.

It might actually be a good allegory after all...

Re: A New Software Engineering

#12

Post by taeric »

scribu wrote: post #9
seanmcdirmid wrote: post #7

Earlier quoted context omitted.

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.

Actually, what gave us the waterfall method was an attempt to self reflect on how we built software. I can't help but see irony there.

Re: A New Software Engineering

#13

Post by krschultz »

discreteevent wrote: post #8

Software 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 diff…

It depends on what you are working on. I would argue front end is more like architecture and back end is more like civil engineering.

Re: A New Software Engineering

#14

Post by minthd »

taeric wrote: post #3
didgeoridoo wrote: post #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.

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…

Like others said, it's hard to compare because the hardware also greatly improved. But if you look at embedded programming - in 80's we had c/ada, today we might have rust - fitting similar environments. That's surely an improvement.

Re: A New Software Engineering

#15

Post by taeric »

minthd wrote: post #14
taeric wrote: post #3

Earlier 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…

Like others said, it's hard to compare because the hardware also greatly improved. But if you look at embedded programming - in 80's we had c/ada, today we might have rust - fitting similar environments. That's surely an improvement.

Why? And there is a lot more to tooling in embedded systems creation than the language that the software is specified in.

If anything, I think the dream from back then would be that embedded systems of today would be more FPGA based. Screw this using fixed design systems. :)

Re: A New Software Engineering

#16

Post by minthd »

taeric wrote: post #15
minthd wrote: post #14

Earlier quoted context omitted.

Like others said, it's hard to compare because the hardware also greatly improved. But if you look at embedded programming - in 80's we had c/ada, today we might have rust - fitting similar environments. That's surely an improvement.

Why? And there is a lot more to tooling in embedded systems creation than the language that the software is specified in. If anything, I think the dream from back then would be that embedded systems of today would be more FPGA based. Screw this using fixed design systems. :)

Why rust is better? for example, it has generics, which more abstract and offering greater reuse while still being efficient.

As for the dream of dropping fixed systems, you can already buy a cheap fast mcu from xmos with 4 cores which you can use 3 to create extra peripherals.Or another cheap CPU with a small fpga. But of course if you're fighting for pennies of cost or power, there might be better fixed alternatives than those 2.

BTW the reason we don't have FPGA on chips is probably mostly commercial - charging by the peripheral offer chip companies ways to more revenues and more differentiation between each other. They really don't want to sell the same commodity chips of mcu+fpga.

Re: A New Software Engineering

#17

Post by jacques_chester »

Computer science isn't a science and it's not about actual computers. Software engineering isn't engineering and is really about the limits of people, not software in and of itself.

Nevertheless, my job title is "Software Engineer". Where it makes sense, I model myself after our elder cousin professions. When it doesn't, I don't.

Re: A New Software Engineering

#18

Post by jacques_chester »

seanmcdirmid wrote: post #7
wrs wrote: post #4

This 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?

A book I read, Industrial Megaprojects, suggests that everyone else makes a lot of the same dumb mistakes we do.

We're not comparing ourselves to civil, structural, process, mining, aeronautical or industrial engineering.

We're comparing ourselves to flawless platonic ideals of those professions that we invented whilst talking amongst ourselves.

Re: A New Software Engineering

#19

Post by seanmcdirmid »

scribu wrote: post #9
seanmcdirmid wrote: post #7

Earlier quoted context omitted.

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.

I don't think waterfall is actually used in other disciplines, perhaps we were just cargo culting back then?

But my question is: if SE is supposed to be based on a theory of project management, then what is the theory used in other disciplines? Or do project management not see that as their underlying theory, but rather something more hard like physics or chemistry?

It sounds like there must be a general field of project management out there...getting people to apply technical skills to get things done. It is probably a soft science, but definitely necessary. So why not talk about this aspect SE as a sub-field at that field rather than as an aspect of a more hard science (computer science)?

Re: A New Software Engineering

#20

Post by taeric »

minthd wrote: post #16
taeric wrote: post #15

Earlier quoted context omitted.

Why? And there is a lot more to tooling in embedded systems creation than the language that the software is specified in. If anything, I think the dream from back then would be that embedded systems of today would be more FPGA based. Screw this using fixed design systems. :)

Why rust is better? for example, it has generics, which more abstract and offering greater reuse while still being efficient. As for the dream of dropping fixed systems, you can already buy a cheap fast mcu from xmos with 4 cores which you can use 3 to create extra peripherals.Or another cheap CPU with a small fpga. But of course if you're fighting for pennies of cost or power, there might be better fixed alternative…

Sorry, I shouldn't have thrown in the quip on FPGAs. It really is a complete non-sequitor. I think a very neat topic, but didn't belong here.

I don't accept that generics are somehow an automatic win for languages. I do like them somewhat, myself, but I don't think there has been compelling evidence that they can be used to great effect in building embedded systems.

Consider, at the low level, the majority of the code written is still in C. Not C++, C. And I can't bring myself to agree that it is lacking because of it.

I know he is intentionally inflammatory, but I think Torvald's rant on why he rejected C++ for Git is somewhat poignant. As is all of the attempts at writing the git core in higher level languages. Specifically, how they haven't really succeeded.

I will confess to being open to the argument, but outside of revisionist history and wishful thinking, I just don't see proof that things are automatically better with today's practices over those of yesterday's.

Post reply on HN