Software Art Thou: Glenn Vanderburg - Real Software Engineering

This discussion reminds me of a talk given by Glenn Vanderburg ( [VIDEO] ), wherein he explores the question of whether "software engineering" is or can really be engineering. Around the 27 minute mark, he quotes Billy Vaughn Koen, a nuclear engineer, as follows: "The Engineering Method is the use of heuristics to cause the best change in a poorly understood or uncertain situation within the available resources." That's hardly the end of the debate, and I'm still undecided, but it seemed worth lobbing in before hitting the rack.

Agile is not a methodology or a process, it is literally[1] a set of values and principles which can be summarized by "stop being stupid and trying to reproduce what they do in construction engineering, and start discussing about the why and collaborate, doing things that matter, and being flexible, since after all, we're doing _soft_ware. The set of methodologies and processes that ensued, as well as the entire industry of coaches, consultants, evangelists and "practitioners" was probably coming from a good place - trying to propose an implementation for how to put in place those abstract values and principles, or to help with that. The commercialization, envy and corruption that followed is what the problem is. "Agile" has become a synonym for "cargo-cult brainless implementation of sprints and stand-ups to copy something called scrum but effectively doing things in a very much waterfall and old fashion that isn't even remotely close to the original intent". The problem is of semantics order. What does need to "die" is the "agile" industry, with cargo-cultish coaches whose only value is to repeat Scrum says X, XP says Y, Agile says Z, my other customers do Ω, without trying to convey the reason behind those implements ; "agile" methodos like "safe" which have very little agility backed in and whose "Enterprise Architects" proponents usually don't get any of the intent. But take a look at the manifesto[1] and tell me that you want it to die, I feel like the arguments will be

Saw an interesting talk just about this topic [1] The gist of it was: Other engineering disciplines use the techniques you've mentioned because of the the costs, both time and money, associated with getting it wrong. Software engineering lends itself to different methods of development and construction, as the costs associated with getting it wrong or making changes after the fact are much lower. (For most applications, anyways). As such, (this definition would be another sticking point) these less rigid methods should still be considered engineering, with engineering being a balancing of resources with outcomes, not fixation on mathematical models. [1]: [VIDEO]

Just wanted to post this video link in this discussion: Glenn Vanderburg - Real Software Engineering [VIDEO]

You have any stats on that or just the feeling? I find that a lot of flaws are ignored in for example physical structures because they don’t even know. Take construction inspector and walk with him through five buildings. Let me know if he left any building without pointing out any flaws. Doctors, a lot of stuff is „let’s try this and see how if it gets better”. Taking complexity of software and limited budget - we as industry are much much better in building anything. We have better tools and better practices. Business people are mostly running around like chickens without head, can’t even bother to learn how to use Excel properly. We have GIT, whole testing approach from unit to integration, team organization etc. Most of the world runs on software as is now and it works and there is much more software in the world than any other structures we built as a species. Bonus watching material: [VIDEO]