ALWAYS look behind the curtain at what software consultants are selling to what they have actually built, and then you can ascertain if they are selling you hard won engineering knowledge or a bunch of marketing BS.
ALWAYS look behind the curtain at what software consultants are selling to what they have actually built, and then you can ascertain if they are selling you hard won engineering knowledge or a bunch of marketing BS.
Sure he was pulling from Structural design ideas, which even Tom DeMarco, the author of the canonical book on SD, now says should have been iterative and Agile-like, but he was also pulling from papers like the following from 1972 about modularity.
https://dl.acm.org/doi/10.1145/361598.361623
The SOLID principles are a specific application of computer science principles to OO.
Separation of Concerns is a specific example of core CS principals that he pulled from but are from Dykstra.
https://www.cs.utexas.edu/users/EWD/ewd04xx/EWD447.PDF
So is your reason for discrediting him that he aspired to be a professional writer, or that he tried to collect concepts from the wider tent into a more domain specific presentation?
Because structural design is an example where the founders realized that not paying attention to that first paper was problematic.
"We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart.
We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others. Since, in most cases, design decisions transcend time of execution, modules will not correspond to steps in the processing. To achieve an efficient implementation we must abandon the assumption that a module is one or more sub- routines, and instead allow subroutines and programs to be assembled collections of code from various modules."
How about addressing Robert Martin's position, instead of irrelevantly attacking random aspects of the person who is making the argument. A.K.A Ad Hominem fallacies.
In the context of this thread, if a candidate could only express their objections to _ideals_ that are intended to be the defaults, and couldn't express their objections in a way that related to business and customer needs, I would be a hard no on the hiring position.
It is OK to not agree with these ideals, but to only offer personal attacks to dismiss them, it indicates someone who will probably be a difficult team member and lack customer focus.
Ad Hominem's never address the real concerns or needs of a project and are simply not constructive.
We know that EA failed, we know SOA works better if imperfect, we know that aiming for loosely coupled and highly cohesive code results in systems that are easier to maintain and scale, and we know that with the rise of the cloud most needs will be distributed. All of those apply the same principles at a different scale or domain.
Hand waving away those well known concepts because you have a distaste for an author won't change that. But if you share ideas that address the limits of those ideas perhaps it can help move us further.
https://www.washington.edu/is/fin/fas/standards/cobol.html
R.Martin had nothing to do with those rules related to procedural code.
There's little to no hard science and serious research behind them, aside from Uncle Bob writing about them and some hazy papers.
The Liskov substitution principle was developed by an actual computer scientist working on such research, but the general field of programming methodology Liskov worked in remains scientifically something like what psychology was before Freud.
Not saying Freud is scientific - saying that programming methodology is even less well established and researched scientifically in 2024 that psychology was not just at the time of Freud, but even before Freud.
Dijkstra himself, in many of his notes regarding methodology, was basically 90% opinion, even when he was right.
https://arxiv.org/abs/1601.01447
There is lots of studies that show that modularity is one of the most significant factors for evaluating maintainability of OO systems.