As someone working with real buildings and building engineering, and as someone who has been working on a daily basis with software engineers, for a while nearly in a product management type role, software engineering principles and approaches are utterly puzzling to me and seem quite buzzword driven. I may misunderstand… (…and will use this to go on an overdue rant)
Take for instance Agile Development. This was introduced to me as an innovative way of software development. Short, quick iterations, close to the client to keep short feedback loops and get paid while you develop. Maybe someone could expand this to things I left out, however, my thought was immediately: How else would you build something?
This is virtually how every sizable building project is done and has been done for all modern times. You have sometimes weekly design presentations, sometimes more often, of all aspects: from architecture to HVAC engineering to structural to functional to user experience to operational aspects to Business Continuity Planning… and yes, it also happens that you accelerate the physical delivery of parts so the building can be used earlier, while other areas are still in construction.
I’m also certain that this is how engineering is done in any other area. Because, frankly, it’s just common sense and the amount of lecturing I received on Agile just baffled me. Even more so, because while they talked a lot about Agile Development, they were neither fast, nor flexible, nor close to the client. Feedback was either not recognised as such or nearly completely ignored most of the time. Putting them in front of a client was like landing them on Mars…
The whole process was very frustrating since there really was a significant lack of client understanding and business focus. Agile, AI and blockchain became my personal trifecta of terror for a while…
This was with a large x00,000 employee organisation, so maybe that had something to with that. I also think that software engineers managed to convince people that they are doing magic, and hence get away with things they shouldn’t.
One thing I disagree with in the article in particular is that engineering has strict protocols and the article makes it sound like engineering is some kind of a cookie cutter approach. There are strict protocols in place, but those are just a given and often mandated… so there is nothing to win there and nothing to think about too much.
Design briefs by clients however are effectively the battlefield that is negotiated in a pursuit to make more money. They are extremely fluid and the negotiations can change drastically any aspect related to the build outcome, depending on who wins. You may engineer one solution nearly to the end, only to end up starting from scratch with another one because you lost your argument. I again suspect that this is the same in industries that have nothing to do with building buildings.
So to close this rant, software development seems to have some very rough edges and we all need to work together to fix the situation.
It is up to us, as educated individuals, to use these rough edges to chase those f#$%&s out of the city when they try to sell you a blockchain instead of a f#$%! SQL database, or AI instead of a g@d d@#n 10 minute effort linear regression and freaking implement the stupid thing today and not 12 months later! Let’s all be part of that change! WE CAN DO IT
Iterative development is how software development was done initially. Then there was a misunderstanding and Waterfall was invented. The DOD spread the idea that you should be finished with the design before you start implementation. I think in practice barely anybody really did Waterfall because of common sense.
Maybe Agile can be understood as the correction (or over-correction in many cases). What the movement celebrates as huge innovation is mostly a regression toward the mean.
deleted by creator
I think being associated with trades scares software people because of the negative stigmas assigned to traditional trade work. That shouldn’t set us astray from calling a spade a spade.
Software has been ever consistently marching towards more standardized higher level abstractions. That brings closer to the concept to trade work. Where in the practitioner isn’t necessarily engineering as much as they are applying a process. Computers are still quite hand wavy magic to many people so it’s easy for that to be obscured behind a veil of engineering.
I think the author lends too much to how easily it is to move between the two modes of operation. A very intelligent engineer can design an elegant system of software architecture for practitioners to apply. Not every practitioner can so easily do the opposite.
deleted by creator
