[rramadass]

> On the other hand, software engineering is about sprints, useless deadlines, using the wrong tool for the job, writing code to increase shareholders value, high-performing-team obsession, useless C-level execs, broken tech interviews…

That is not at all what "Software Engineering" is. It is Management's view and practice of what it should be based on the fad of the month/year, simplistic efficiency/productivity models, cluelessness about human psychology and its specific nuances when it comes to knowledge/programming work, erratic/idiotic business goals, bad human resources management and in general not understanding that while one can look to established Engineering disciplines for inspiration one cannot apply those processes/techniques blindly to Software Development since it is so very different.

The classic works of Gerald Weinberg, David Parnas, Barry Boehm etc. gives one the proper viewpoint to have towards "Software Engineering".

[marxisttemp]

Barry Boehm is the epitome of the process-obsessed, elegance-hating middle manager

[rramadass]

I have had this argument before and No that is not quite true. For people not familiar with his work - https://en.wikipedia.org/wiki/Barry_Boehm

His research was a product of his times when programming/coding was considered a clerical job with the real brain work being done by System Analysts and System Designers who produced System Requirements Specification Documents and System Design Specification Documents. He was the first to show that software development costs would outstrip hardware development costs and the importance of its Risk Management through a Spiral Model. He brought "big picture" engineering process lens to the management of software development which became "Software Engineering" today.

All of these ideas are still valid though they would need to be modified for current times given the decades of experience we have had since then. Software development at the Individual level involves creativity/art/craft/individual flair and companies must acknowledge and provide means for expression of these psychological needs. OTOH, Software development at the Company level is all about Risk Management in the service of its Business Goals and hence needs a reproducible process and associated methodologies. We need to find a balance between the two.

[marxisttemp]

I agree that risk management is important for software companies, in the same way it is for construction companies, and part of that involves software engineers.

But I think pretty much any business has risk management processes that involve domain knowledge, and a much larger and more distinctive part of any kind of engineering involves non-business considerations and tradeoffs that AFAIK Boehm didn’t really concern himself with. For example, a civil engineer designing a bridge is thinking about wind shear, traffic volume, vehicle weight allowances, and so on, just as a software engineer is thinking about latency, throughput, error propagation, and so on. To me, these sort of non-business-logic but very much domain-specific considerations are what comprise the core of software engineering (as compared to programming, which I would classify as just getting the business logic correct without any meta-considerations).

This comment is poorly edited, but essentially Boehm’s processes to me are better described as “software business management” than “software engineering”.

[rramadass]

Agreed, though IMO "Software Engineering" subsumes everything. You are looking for a holistic and reproducible process which can be communicated using well defined methodologies.

One important point though; IMO Risk Management in the Software Industry is qualitatively different than that from other Industries. This is because of the greater play and importance of Human Factors involved and their cumulative non-linear effects. In very few other industries (eg. Finance) can you have a factor of 10x/100x productivity between the average and the best since it does not follow the normal distribution. If i have a Jeff Dean/John Carmack programming or a Steve Jobs salesmanship in my company i can break every engineering rule i want and still come out on top.

Nassim Taleb's ideas on Mediocristan/Extremistan, Power Laws/Fat Tails are all relevant here. Here is a great video explaining these concepts (though we have to adapt and apply it to Software Engineering) : Pareto, Power Laws, and Fat Tails - https://www.youtube.com/watch?v=Wcqt49dXtm8