Coming from another perspective of software creation, being functional safety, software design and build can be organised when it has to be and you have no oth

Coming from another perspective of software creation, being functional safety, software design and build can be organised when it has to be and you have no other options. But this generally means waterfall, knowing more or less exactly what you are doing before you start building, along with expensive design, build and test schedules with budgets to match. The "move fast and break things" philosophy will in many cases create messy outcomes, that maybe get tidied up incrementally later. But this approach is also the most prudent when a fast developing field means that if you were to engineer "properly" you might miss a business opportunity, and the potential consequences don't constrain the way the work is done. It's all about balancing the goals and the value add, along with the way they are achieved, and currently for a lot of software that means build like it's a shanty town at a gold rush, and worry about tarting it up later, if enough gold is found.