Software Engineering: Dead?

Yeah, the most important thing in blogging is to have catchy title…

What we do IS crafmanship.
I have had that idea forever. Mentoned here http://www.muscetta.com/2007/12/27/simply-works/ and also Phil before used the very same word http://haacked.com/archive/2007/12/21/faceoff-haack-vs-hanselman-it-gets-real.aspx

Ok, here’s a perspective from a soon-to-be mechanical engineer:

I’ve been programming as a hobby for the last few years. And it did very much bug me that programming did not feel like engineering. I had always felt that the reason might be that in engineering (or some types of engineering), if you don’t do something right, you could risk people’s lives. So there were all these standards to be followed, and you’re held accountable by the law if you fail to follow them.

In contrast, there are just guidelines in “software engineering”. Best practices. General advice. Nothing really concrete, and few “right” answers (unlike the math-based problems I’m accustomed to).

And as much as that bugged me at first, it was also so liberating. There was a great technical aspect to programming, but yet there were few rules. And that combination allows for real creativity. It really is a craft.

Perhaps it’s time to read Mary Shaw’s classic “Prospects for an Engineering Discipline of Software”: http://conway.isri.cmu.edu/~jdh/MethodsF06/res/readings/shaw_90.pdf

“Software engineering is not yet a true engineering discipline, but it has the potential to become one. Older engineering fields suggest the character software engineering might have.”

Whoa! Thanks for the post and the links. Will delve into a little bit of introspection :slight_smile: Feeling a little light headed right now.

"So, how do you manage a project without
controlling it? Well, you manage the
people and control the time and money.
You say to your team leads, for example,
“So, how do you manage a project without
controlling it? Well, you manage the
people and control the time and money.
I have a finish date in mind, and I’m not
even going to share it with you. When I
come in one day and tell you the project
will end in one week, you have to be
ready to package up and deliver what
you’ve got as the final product.”

How would this translate to good management of your people? I could see this creating a high pressure atmosphere where everyday feels like it is in the last week of the project and you don’t have enough time to finish? I think that people like some levels of certainty and stability in their every day work life.

I think this is closely related to the observation that there are huge differences in productivity between software developers. Strict processes, rules, and control will in fact help software projects to attain a slightly higher degree of predictability. But it means that you’re cutting away the tenfold performance of awesome developers (probably by causing them to leave your team). So yes, you can get predictability if you set the bar very low; the project will predictably take forever and the code will suck.

Programming is not engineering. Enginieers have rules, they have formulas. They follow them. Programmers have patterns. Each of them, if one is lucky. some like to invent the wheel every time. Look at repositories like freshmeat, and you se the point.
Craftmanship, yes. Some even Art. However, that always gives room to introduce bugs. Which then needs another Craftmansship: The professional tester/debugger.
We make it too easy for ourselfes to break the rules. This avoids engineering.

1 Like

I like the comparison of “Software Engineers” to “Craftsmen”. I’ve seen some really well crafted beautifully structured code in my years of programming, and I’ve seen some horrendous steaming piles of crap. If some software developers were furniture makers I’d certainly think twice before plonking my bum down on a stool they’d just built.

1 Like

Huh.

I think the premise of this statement is based on a definition of “software engineering” that I never respected in the first place.

Let’s take the analogy of paint. Yes, paint. An artist uses paint to apply to a canvas to create his works. But there actually is an engineer at PaintCo who engineers the paint. He studies its viscosity, its longevity. He applies science (chemistry) to create new paints, with which the artist uses.

IMO you can’t say that programming languages themselves aren’t engineered based on solid computer science. You can’t say that something like LINQ hasn’t been engineered. Whenever you use a FSM in your software, you are applying computer science, which makes you a software engineer.

But by saying “software engineering is dead”, you basically say, “the hell with it”, we don’t need to know and apply computer science to get our projects done. Big-O notation? Who cares, we’re artists! Rules engines? I will craft the most beautifully indented set of nested IFs! Knowing how a B-tree works so I can understand WTF my database indexes actually do an then intelligently apply them? Sounds like nonsense to me. Why not just add some more indexes until it gets fast!?

Saying software engineering is dead and that all we have to go on are “best practices” is a statement that rejects the notion of actual computer science, lock, stock and barrel, and smacks of ignorance to me. Can I get a witness?

1 Like

For those on small teams I think the argument is valid. For those writing software on the scale of NASA or other similar projects, then the answer IMO is “No, software engineering is not, and cannot be dead.”

Webbie apps and the like (twitter, SO, etc, can be seat-of-the pants development, but when working with large teams the process is important and so is the engineering.

The wrong-headedness was when DEMarco and Yourdon and Humphreys pushed everyone (even one-man teams) into huge complex process frameworks for no good reason.

wait, what, how are we defining engineering?

i don’t know either, but i contend that
{engineering} ∩ {software development} ≠ Ø .

engineering has its craftsmanlike and design-iterative elements. the pyramids, the first Tay Bridge, the Titanic, the numerous missions that were performed before the moon visits …

software design is chock-full of the nuts-and-bolts-mathematical analysis that characterizes engineering. scalability comes to mind as the first example.

at the overused end of the day it’s tomayto vs tomahto, a distinction not even at the level of nomenclature, but more like at the level of pronunciation. it’s the same mental tasks performed in a different order under a different set of priorities.

there’s value to both disciplines in understanding those differences. to that end, look to cultural/social/personnel factors, as other posters have said.

1 Like

Those who say that there is no engineering in software and that Agile solves everything have probably never been in a situation where people will die if their code fails. And I mean “die” as in “forget Dr. House, we need the guys from Six Feet Under” dead.

1 Like

Are you really surprised? He’s really attacking that first line in his book that has led to such nonsense as believing that SixSigma for software, CMMI and ISO for software can effectively drive software projects.

“You can’t control what you can’t measure” - RIP

DeMarco’s fatal error wasn’t in associating software development with engineering - it was in believing that software development is vastly more like plant floor engineering than as the engineering that goes into things like building entirely new products. Those are vastly different.

That line, incidently is still right - it’s just that PMs have spent that last 30 years trying to fight that line rather than embracing it.

DeMarco did some favors by this vision early on, but people who actually ship software fully understand just how wrong the effort to fight that line was. The problem was, you couldn’t say it without drawing ridicule - because kicking sacred cows is reflexively frowned upon.

It’s been a long time coming, and I don’t completely agree with DeMarco’s conclusions around that point, but it’s nice to see he has made them public.

And like all crafts, there are many different types of craftsman.

There are those whose practice is close to that of a true engineer. There are those who are true artists. There are many who are good, dependable master craftsmen. There are journeymen, well on their way to being masters, engineers or artists - and you can normally tell which it will be. And there are some who can cobble something together that basically works, and do so because it pays the bills.

If you think of programming as akin to a traditional craft, the variation in the types of people you find doing it starts to make a lot more sense.

@codinghorror well this again proves my notion that good developer = passion for development + ready to discuss + complain if it doesnt feel right + always yearning for better methodology.

good developer != put your head down and code + yes man.

all in all “I think therefore I am (a good developer)”.

Software Engineering is not dead. It just isn’t what most of us do every day. People who write very close to the hardware most certainly are engineering. There are only so many ways to add two numbers. Making sure the Bus talks to the CPU in the correct manner is engineering.

Those of us (myself included) who are writing high level applications have much more freedom in the way we construct our software. Our abstractions are insulating us from the engineering. Which is a good thing. On a day to day basis we design how the code will function, but it is the compiler or the interpreter that does the engineering: Putting the 1s and 0s in the correct place at the correct time.

Take away all of our abstractions and return us to the moving of ones and zeroes and I think you’ll find all the engineering principles will become a lot more appropriate.

This realization was taught to my during college. Several different instructors pointed out that software engineering and civil engineering at not held to the same exact standards.

I think what people are trying to say is that software development should not be thought of as a manufacturing process.

That does not mean software development is not a form of engineering - in the broad sense of “the application of scientific principles”.

FWIW, here s some plainspeak “best practice”:
Get specs from client.
Design a chunk of framework and plumbing in isolation.
Show client half-ready code. Ask for changes/suggestions.
Iterate.
Charge by time, obviously.
Product emerges just like customer wants. Very happy customer.
Applies only to small/medium business apps - compilers, interpreters, OSes, scientific apps, rocket science, supercomputing, etc. out of scope.