What if an architect could specify an entire skyscraper, push a button, and have it manifest in the real world in 30 seconds? What if they could slightly tweak something about the plumbing, push the button again, and have the old thing torn down and the new building put up? What if they could push another button to put 10 times the rated mass on every floor to see what happens? What if they could push another button to summon an 8.3 magnitude earthquake for ten minutes? What if they could write a for loop that did that for every .1 magnitude increment, ten times a day, until the building collapses, and gathered statistics on which buildings do the best?
Do you think maybe this would affect their design process a bit? Maybe just a little?
If you stop and seriously think about it, you should expect that programmers have a very different optimum design methodology. It would be crazy if we didn't!
Now, there are good practices and there are bad practices, and the bad practices are more widespread than they should be, and there are cowboys where there should be engineers. However, based on the prevalence of posts like this, I have little confidence in the ability of a "professional organization" to improve things. It seems based on the evidence far, far more likely to mandate counterproductive practices that make software more expensive, less reliable, and harder for the disadvantaged and underprivileged to get into.
Don't be envious of the other engineering disciplines. They envy us.
They shouldn't. Our work is deplorable. Any non-trivial internal codebase would probably give any mathematically savvy engineer nightmares for days. If our office buildings were designed as needlessly hastily the software designed inside them, having our tech hub in an earthquake hotspot would be a serious issue.
Yes, there is something to be said about the convenience of our "agile"/rapid-development cycle, but it's not like we use that power responsibly. We have enough decades-old codebases that have been in a perpetual state of 'fragile legacy-code' since they were first written, that prove that we don't take our designs seriously enough to improve them despite all our conveniences. If building engineers suddenly had access to some magical 'easy-bake oven' for building skyscraper MVP's and making 'agile' changes, I know I'd be concerned, looking back at our track record with software.
They're objective is, does it work? Then don't change it.
You have to remember software is incredibly complicated due to the amount of possible states it can be in.
Same deal with "software engineer". I know that PEO (Ontario), APEGA (Alberta) and OIQ (Quebec) are pretty strict on this; Google's devs at the K-W and Montreal offices are known as "software developers", as a result: https://www.google.com/about/careers/search#!t=jo&jid=324000...
Recently APEGBC has been cracking down as well. The main problem is that there are only 100 registered Professional Software Engineers here in BC, out of 50,000 registered Professional Engineers and Geoscientists. Because you can't get your PEng without working under another PEng first, the deck is stacked against "software engineers" using the Valley/Puget Sound definition. HootSuite now uses the term "software developer", but some of the more prolific companies in Vancouver (Amazon, Microsoft, Tableau, Mobify) still use the term "engineer" in positions, even for positions that don't exclusively need licensed engineers/geoscientists.
>No one took design and security too seriously. They still don't.
To some degree, but the whole idea of Agile is very test-based: Write something, see if it works, toss it if it doesn't. That's not a hard workflow to integrate security auditing and testing into: It's just another kind of testing, if a slower one.
Given, you are right about this kind of thing being highly anti-planning. As to whether that's a bad thing, I don't know.
However, I can safely say that it's better than some alternatives. There is no way epoll would have gotten through a proper testing in its present state.
So yes, I thing these are big problems, but casting the blame on agile is like saying that a large dog ate your bed: He might have wrecked it a bit, or maybe not, but he couldn't have eaten the entire thing.
Yes, you can have a good product if you have a very strict spec, written by true experts that really know what they're doing. Otherwise forget about it
I am a software engineer.
And as it happens I work for a famously, even notoriously, doctrinaire agile company: Pivotal. Which is the first place I've worked which actually felt like I'm engineering instead of coding.