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

41–50 of 94 posts

Re: A New Software Engineering

#41

Post by randomdata »

krschultz wrote: post #13
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.

I struggle to come up with a distinction between the two, with respect to the original post. The design work that goes into programming is largely irrespective of the problem. In fact, if you stick to common design methodologies you often won't even see a significant difference between "front end" and "back end" work – and I might even suggest the line is completely arbitrary.

Re: A New Software Engineering

#42

Post by calinet6 »

warcher wrote: post #38
warcher wrote: post #37

It's not like we can't design very elegant, robust, reliable software, you know. We just can't find anybody to pay for us to retool the whole stack (and I do mean the whole stack, since we're only as strong as our weakest link) while the current ad hoc solution operates within acceptable parameters. The guy who wrote this paper, in my opinion, is missing two really bedrock principles of "pure" engineering-- manufactu…

Addendum: The other real serious mischaracterization here is likening software to a physical product, even one as complicated as a skyscraper. Software is a factory that makes products, whether they're html pages, or graphics on a screen, or inputs to an industrial controller. You start looking at how to engineer and design and manage factories and a lot of the chaos of computing looks very familiar. E.g."367 days si…

The factory analogy is extremely apt.

As in a factory, Quality in software is a result of a complex myriad of factors, but it reduces to some simple concepts: an understanding of psychology, a deep understanding of statistics, knowledge and application of systems theory, and the simple idea of epistemology and scientific method applied to management and production. Finally, leadership and universal application of these concepts throughout an organization, using a PDCA cycle of continuous improvement (Agile is a rough one).

W. Edwards Deming had this all exactly correct way back in the 1940's, after WWII, where he taught these concepts to Japanese companies, transforming them from cheap crap makers into the quality powerhouse economy we know and love.

We should listen to him again. That's the "new software development" we need.

http://en.wikipedia.org/wiki/W._Edwards_Deming

Re: A New Software Engineering

#43

Post by calinet6 »

31reasons wrote: post #22
thibauts wrote: post #10

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

Software Engineering is in a way meta engineering discipline. Problem domains are vastly different. A mobile game development is different than building a system software for surgical robot. The first step is to define the vocabulary of the solution space and then build the solution based on that vocabulary. Expectations of reliability, maintenance, requirement changes adds another dimension to its solution space.

The best way I've heard this described is this:

Engineering has a well-defined constant you're always building against: gravity.

In software, you choose your gravity, and it changes all the time. Sometimes there are twelve gravities. Sometimes there are different types, and they interact in complex unpredictable ways.

In short, it is a much more difficult problem. But personally I believe we can reach a meta-engineering capable of achieving quality in a predictable way.

Re: A New Software Engineering

#44

Post by [deleted] »

thibauts wrote: post #10

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

[deleted]

Re: A New Software Engineering

#45

Post by [deleted] »

contingencies wrote: post #35
terrasect wrote: post #27

For more technical methods and theory, I would check out The Five Orders of Ignorance ( http://dl.acm.org/authorize?9919 ) and the book The Pragmatic Programmer.

Five Orders of Ignorance working link: http://www-plan.cs.colorado.edu/diwan/3308-07/p17-armour.pdf .. I didn't find it to be particularly of value.

[deleted]

Re: A New Software Engineering

#46

Post by analog31 »

Truth be told, there's a huge amount of craft in mainstream product design. Only a certain subset of the things that we use are engineered at the level of discipline reserved for things like airplanes and skyscrapers. And hardware designers are comfortable with some things that would horrify software designers, such as relying on closed source tools for critical tasks like structural analysis.

When we discuss engineering discipline, somebody will invariably remind us: "Look, we don't designin airplanes here."

Re: A New Software Engineering

#47

Post by pm90 »

calinet6 wrote: post #43
31reasons wrote: post #22

Earlier quoted context omitted.

Software Engineering is in a way meta engineering discipline. Problem domains are vastly different. A mobile game development is different than building a system software for surgical robot. The first step is to define the vocabulary of the solution space and then build the solution based on that vocabulary. Expectations of reliability, maintenance, requirement changes adds another dimension to its solution space.

The best way I've heard this described is this: Engineering has a well-defined constant you're always building against: gravity. In software, you choose your gravity, and it changes all the time. Sometimes there are twelve gravities. Sometimes there are different types, and they interact in complex unpredictable ways. In short, it is a much more difficult problem. But personally I believe we can reach a meta-engineer…

Engineering is not as simple as building against gravity. There are a lot many things that "engineers" (non-software) have to take account of, even in something as mundane as laying out a road. In this example, you not only have to build the road within the area; you have to build it so that it has the right curvature so that vehicles can make the turn etc. You have to make sure that the road you're laying out has a solid base; you need to make sure that the road can withstand the natural forces of that region for whatever time it is designed to last against. So I don't understand how engineers build against gravity.

But if you're saying that engineering has to follow the laws of physics, then yes, I'm totally on board. Computer Science departments in most universities started of as branches within the mathematics department. While most of software engineering is more than simple math; it does operate on its own plane, with no regard for the laws of physics (except maybe of time :) ).

In that regards, Software Engineering seems more of an art, doesn't it? But it does have its own guidelines; which govern how good software is written.

Re: A New Software Engineering

#48

Post by angersock »

seanmcdirmid wrote: post #19
scribu wrote: post #9

Earlier quoted context omitted.

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

Erm, how to put this delicately...it's difficult to design and construct a bridge or refinery in two-week sprints.

These are projects that span years--you bet your hat that they do that design work up-front and try not to make changes otherwise.

Re: A New Software Engineering

#49

Post by taeric »

coldtea wrote: post #29
taeric wrote: post #6

Earlier quoted context omitted.

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

> 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 find that they (from the '50s and even older) hold up just fine. If software worked initially, and survived 60 years that well as bridges from the 50s do today, that would be a miracle.

This leads to a few questions, though. First, if bridges were built just fine in the 50s, why do they build them differently nowdays? Second, why is the maintenance cost of bridges decidedly non-trivial? Third, is there any software that is that old that still works fine?

For the first question, I would only be offering speculation. Google and friends can give pretty good references.

For the second, a quick google gives "The annual direct cost of corrosion for highway bridges is estimated to be $6.43 billion to $10.15 billion ..."[1]

Third, I offer TeX as a good example of old software that has managed to survive for quite a long time. I am always pleasantly surprised when I go to typeset something from 20+ years ago and things "just work."

I think the theme here is that maintenance costs for bridges more often than not entails just keeping them working. Seems that far too often in software maintenance costs try and include complete rewrites into new technologies.

[1] http://www.dnvusa.com/Binaries/highway_tcm153-378806.pdf

Re: A New Software Engineering

#50

Post by omouse »

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…

Knowledge workers are completely screwed when it comes to getting things done if the project management techniques are crappy.

What you're missing here is that these processes/tools are light-weight and are easy to keep track of. Pick the alphas that you need, read the description on the card and if you match, that's your card for that alpha. Look at that! You just quantified how well your team is doing.

We have theories and proofs and code for everything in programming, but we don't have a good process.

Post reply on HN