"...'Systematic' is the last word I'd use to describe the way good programmers write software. Code is not something they assemble painstakingly after careful planning, like the pyramids. It's something they plunge into, working fast and constantly changing their minds, like a charcoal sketch.
In software, paradoxical as it sounds, good craftsmanship means working fast. If you work slowly and meticulously, you merely end up with a very fine implementation of your initial, mistaken idea. Working slowly and meticulously is premature optimization. Better to get a prototype done fast, and see what new ideas it gives you. ..."
Or to put it another way: software engineering is not dead, it just happens in a much faster manner than it is commonly practiced.
Funny, you make it sound like software engineering is dead.
It doesn't sound like it makes any mention of software engineering.
[citation needed]
This debate comes up periodically, and in some forums we are lucky enough to have engineers from other disciplines pop up, who comment to the effect that they do rather more experimentation and software-like development than computer programmers often realize. The "big" projects that we associate with blueprints are rather small by percentage of projects done, and even they require a certain amount of flexibility to handle changes discovered during the course of the build ("oh, crap, this bedrock is actually sand!").
Mind you, the previous paragraph is also [citation needed], but my real point is and remains to call for actual experience and knowledge and not just regurgitations of stereotypes.
(I know a number of engineers in my circle of family and friends, and none of them actually work in anything like the "Waterfall" model, only with blueprints. The closest is the one who is in charge of designing racecars, and they still do experimental designs in computers, and before computers, did experimental builds of cars.)
Designing a building is much more akin to configuring a server (which anyone here is perfectly comfortable doing by blueprint) than developing an application.
The level of detail usually required in a software-blueprint would amount to including the placement of pencils on every desk in the building-blueprint.
Everyone's getting onto scrum and agile now, even the sceptics who can see that it has benefits as you describe.
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 a forum like hn? 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 SDLC: 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.