Why We Need a Theory for Software Engineering | Hacker News Reader

Why We Need a Theory for Software Engineering

ddj.com

18 pointsedw51915 comments

Ok, I'll go out on a limb and say no we don't. If you followup to the authors blog, he states:

"At its core the theory relies on practices. Now there are good and bad practice concepts. The idea of practices has been around for fifty years, but these practices are loosely defined. We need a practice concept that is more precise."

That doesn't seem to really drive home the need for a theory of software engineering to me.

What we need is a better definition of what the craft of software requires (the practice of writing software) - not a theory of software engineering. Then we need to think about how we encapsulate those basics of software craftmanship in a way that we can communicate to each other and apprentice newbies into. There's still no silver bullet for managing software development.

I recognize that in some ways, the author is pointing out that we tend to drop everything and reinvent the wheel every few years. But that's how the consultants make their money, right? Isn't incumbent on us (practitioners) to call BS when we see it? If the point of having a theory of software engineering is to stop the rush from one process to another, that's not going to stop the snake-oil salesmen. They'll just move on and talk about how the "theory" doesn't measure how much better the new process is because it is such a radical new process.

I'm also curious about the number of successful software deliverables that are due to the software engineering process followed by the team that created the software. Anybody here feel like the most successful project you worked on was due to the specific software engineering process that was used?

I agree.

I TA what I believe to be one of the better undergrad Software Engineering courses around, "Fundamentals of Software Engineering." As the undergrad TA (the other is a Ph.D. student with real-life industry experience), I can honestly say that it's a nightmare.

Software Engineering today basically amounts to anecdotes and marketing. I mean, if you look closely enough, there are some interesting theoretical nuggets: static/dynamic analysis, theories of testing, etc. But the reality is, a semester of the fundamentals of software engineering leaves you only slightly more able to choose a good development path than the next guy. In the end, choosing a quality process is a task left up to the reader, which is why we have so many pair and agile programmers (and so many more Duct Tape Programmers), IMHO. Developers either go for what's best marketed or for what's easiest.

At the end of the day, something unifying would be a huge benefit to everyone, but we're a long way off from that. Right now, the question is: Is that even possible?

what is TA?

I'm a Teacher's Assistant for it. It means I teach recitation, answer questions, and grade stuff.

One question we need to answer first is that are new frameworks, practices and methods simply a fashion and reinventing the wheel or is it because the pace of change of software industry is so fast that we need to have new innovations every couple of years in order to keep up with it?

We have plenty of theories of Software Engineering. The problem is that there are impediments to empirical verification of these theories. There are other impediments to replicating the results.

Hang those impediments on any discipline, and you transform it from a technical field to mumbo-jumbo. Basically, the problem has to do with flows of information.

Free/Open Source helps, as it facilitates the flow of information. However, it's not a complete solution.

We have plenty of theories of Software Engineering. The problem is that there are impediments to empirical verification of these theories.

I don't get it - software engineering is not physics. There doesn't need to be a Grand Unifying Theory. Software engineering is like skinning a cat - there's more than one way to do it.

Yeah, but even some random ad-hoc curve from geology for packing of sediments does better with empiricism than lots of Software Engineering. Heck, I bet some carpenters have more effective metrics than many programming groups do.

The problem is that company's will either conduct no analysis of their own software engineering processes or they will conduct an analysis but the data for it will be hidden meaning that it cannot be verified or reproduced.

So everyone has a theory, but there is little data to support the theories and getting that data is very difficult.

Right, it's like the dark old days of Alchemy before the scientific discipline of Chemistry. We are still transitioning from quirky weirdo/geniuses doing arcane things in secret for a wealthy patron to doing things in the open, with peer review and an open fact-based debate.

A bit of both. The reinvention is partly very similar to business books, each of them saying the same things, but with a different spin... and not mentioning the others nor their similarities. For software, the rapid creative destructionism of hardware - disruptive innovations - creates opportunities for the next methodology to get a foothold.

On the other hand, just as different branches of engineering (chemical, mechanical, civil etc - and their sub-branches) need different methodologies because the issues are different, a disruptive innovation in effect often creates a new branch of engineering, that changes the issues, so that, a different methodology really is appropriate. My thesis would be more compelling if I could think of some examples.

But here's an observation: if methodology really mattered, wouldn't the firms that followed one of them triumph over everyone else? But that doesn't seem to happen. It's not because methodology is unimportant, but that it is unimportant relative to marketing and technical innovation. In "real" engineering, most of that has settled down as they mature, and methodology rises in relative importance. [Just my thoughts]

EDIT I think the above count as some of the impediments mentioned by stcredzero.

So your take is just that things change so fast, it creates chaos.

Strikes me as an inaccurate exaggeration, but something like that. More like building on a fault-line or flood-plain.

Spoken like a true theorist.

No, a true theorist would say we need theory or theories, not a theory.

Reply on news.ycombinator.com