4 ms·
You are making the assumption that the actual science of Computer Science has anything to do with "Software Engineering". The formal theories of CS, eg proof of
by rswail 6y ago
You are making the assumption that the actual science of Computer Science has anything to do with "Software Engineering". The formal theories of CS, eg proof of correctness etc, have very little to do with day to day programming. The only example I know of true software "engineering" was the NASA Space Shuttle software team.
But they had the benefit of a fixed platform and total control of the software environment. Attempts to implement similar levels of "engineering" (eg CMMI etc) always fail unless they have similar constraints.
Software development is not "engineering" in the classic sense, where there are a set of formalized approaches, acceptance criteria etc to specific areas of implementation.
People wrap things up in "process" to try to present a picture of "engineering" but it's a Potemkin village.
On the other hand, software "architects" are doing what building architects do. They apply heuristic approaches, hopefully using patterns that have shown to be successful. The reason architectual patterns appealed to programmers is because both fields are not engineering.
The trouble is that many software architects are focussed on the low level engineering. Architects that draw "C4" diagrams that go lower than maybe 2 levels aren't being architects.
Design doesn't travel in circles, it learns from experience. It understands that there needs to be constraints, otherwise the problem to be solved is unbounded. It understands that the system or product has to interact with its users and that the interaction needs to be as seamless as possible, so affordances are vital.
Don't judge a professional field ("design") by empirical science standards.
Design is not engineering.
- Geminidog 6y ago>The trouble is that many software architects are focussed on the low level engineering. Architects that draw "C4" diagrams that go lower than maybe 2 levels aren't being architects. I would argue software architects aren't doing any engineering. There doing something similar to art. Drawing and painting. The main problem is that these big words like "architect" deceptively paint a picture as if they're doing anything other than art. >Design doesn't travel in circles, it learns from experience. It understands that there needs to be constraints, otherwise the problem to be solved is unbounded. It understands that the system or product has to interact with its users and that the interaction needs to be as seamless as possible, so affordances are vital. Much of it does travel in circles because what happens is people encounter two differing designs but they can't really know which design is better. Additionally it doesn't necessarily always improve because nobody can truly define improvement. Take the monoliths vs. microservices argument. It's cycled away from monoliths and back. Take FP and OOP, it's also cycled from FP to OOP and back to FP again. Or what about the newest framework flavor of the week in javascript that tries to improve on all the faults of the front end but ends up being a step to the side? These circles are everywhere. >Don't judge a professional field ("design") by empirical science standards. I judge it by whether it's improved or not. It has not. Technology shifts but it doesn't shift in the direction of improvement. Many shifts are just horizontal genetic drift. >Design is not engineering. "Engineering is the use of scientific principles to design and build machines, structures, and other items, including bridges, tunnels, roads, vehicles, and buildings.[1] The discipline of engineering encompasses a broad range of more specialized fields of engineering, each with a more specific emphasis on particular areas of applied mathematics, applied science, and types of application. See glossary of engineering." keyword: "design" source : https://en.wikipedia.org/wiki/Engineering https://en.wikipedia.org/wiki/Engineering