“Software Engineering is Dead” is obviously an overly sensational title, but let’s look for the deeper truths.
First a little background. I have built a career developing business applications as a contractor, often in very large organizations. I am almost always very successful and I’m often regarded as a hero doing what most people here would call “just doing my job”.
Why is it so easy to be a hero in the enterprise with software that would just seem ordinary in other places? Is it because enterprise programmers aren’t as good as us? Is it because their managers are all phbs? Or because they don’t know how to run projects?
I’d say no to all of the above. Enterprises are filled with lots of excellent people doing great work.
I think that the real problem is that the Systems Development Life Cycle (SDLC) that so many depend on so much “never really did work”. Why?
Every phase depends upon Phase I, Analysis to be rigorously done. This rarely happens for 2 reasons: users often don’t know what they want and most systems analysts don’t know how to extract it even if they did.
So almost everything done after Phase I is built upon a foundation of sand. It’s either wrong or sinking fast.
And what do most people do? Everything except fixing the problem: more resources, more project management, freezing specs (which aren’t right in the first place), more rigorous deadlines, etc.
But rarely does anyone attack the core problem with the Systems Development Life Cycle: defining the expected result.
So what should we really do? Develop something, anything, quickly, cheaply, and get it out to the right users. They will instantly give you feedback. What’s right, what’s wrong, what’s stupid, all the cool stuff that no one thought of.
No one can just sit down and write a Functional Specification for a large business application. And even if they could, you don’t want them spending time on it. Better to get the right people together and find out what they need. Usually, no one of them knows what the result should be, but all together, any decent developer should be able to extract enough data to write version 1.0 of “something”.
It’s a lot easier to judge something that exists than define something that doesn’t.
The larger the organization, the more difficult it is to change their ways.
Software engineering isn’t dead. It’s just that the process of depending upon blueprints before you get started never worked in the first place.