Yes, there’s been a lot of negativity toward earlier versions of this document. It’s been around for a while and represents a formal, structured, and rigid approach to software development. Historically, it reflects the 1990s era, when waterfall was the preferred method, and there was a push to make software engineering a licensed profession. At the time, we were also in a “software crisis” where large, expensive projects with extensive documentation and formalized planning often failed. Today, we have quicker releases, faster feedback, and more direct user communication (what we now call extreme programming or agile). However, this has also led to too much cowboy programming. So it’s important to maintain some level of standards. Might be worth revisiting?
replies(3):