Software Engineering: Dead?

Software engineering projects can require from little to very high levels of “ingenium” and “cleaverness” as well as challenge the barriers of math, physics and creativity.
That is the case of embedded systems where limited resources and tight integration with hardware are required.

I think the problem is that ‘software engineering’ as such has come to be dominated to a certain extent by a mongrel breed of half-assed bureaucracy which has gotten away from software, the thing itself, and which is why, of all the things on the To Do list for a piece of software, the software itself is likely to be towards the bottom, at least from the perspective of the people who pay the programmers to write the software. Which is why it’s so important to be a craftsman; in the teeth of that kind of well-hey-lets-just-use-VB6-then bureaucracy.

It saddens me that thisis the case, but in my experience it’s also true. I have never seen engineering principles carry even a moderately complex project through to success in the absence of genuinely passionate developers. Yet I’ve seen passion create amazing software without a heavy engineering process time and time again. I firmly believe that skilled, passionate devs will naturally create and follow an effective engineering process without intervention simply from a desire to create. Deadweight devs, on the other hand, will never create profitable software no matter how much process you throw at them.

Don’t worry Jeff, you’re not a software engineer… You’re just a VB noob.

Or C++ shudders even worse.

I have maintained for years (and nothing has changed my mind yet) that software development is all about the people. If you have good people around you, people who care, who have courage and integrity you will succeed no matter what.

I think that is what the spirit of agile is all about, it’s not pair programming or refactoring (those are just a means to an end) it’s about the people, the environment and how they interact, it’s about getting everyone just a little bit personally invested in the success of the project. That doesn’t sound like any sort of engineering I’ve ever heard of.

1 Like

This just makes me wonder if we haven’t really gotten started yet. While I do totally agree that conventional engineering principles don’t really apply to software development (do they apply to the construction of any complex system?) there is definitely a place for rigour in our discipline.

For example, how much better has both QA and testing become as we learn and understand more about the field.

Likewise we still need to take into account, things like medical systems which require sophisticated controls to prevent faults from slipping through the process.

That said, the development itself still needs to be iterative to keep things moving quickly.

– Lorenz

1 Like

“Project A will eventually cost about a million
dollars and produce value of around $1.1
million. Project B will eventually cost about a million
dollars and produce value of more than $50
million.
What’s immediately apparent is that control is really
important for Project A but almost not at all
important for Project B.”

Why isn’t control almost not at all important for Project B? Just because it is going to make a huge profit? How do you guarantee that your project is of type Project B. In the beginning you can think that it is of type Project B, but what if later it turns out that it has become of type Project A and you have completely neglected all control up to that point?

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