SoylentNews is people
SoylentNews
Arthur T Knackerbracket has found the following story:
In March 2008, Paul Graham of Y Combinator wrote an essay called "How to Disagree." In the article he defines a hierarchy to gauge the quality of one's disagreement with another person's argument, a measure which ranges from name-calling at worst, to refutation of the central point at best.
I think a similar hierarchy can be defined to gauge the quality of architectural thinking and discourse of software engineers. I have noticed that most entry-level programmers focus their attention and criticisms on first-order issues such as code style, naming conventions, source code and repository layout, etc. They neglect or are unaware of higher-order concerns that can make a bigger impact on reducing the complexity of their systems. Even experienced programmers seem to suffer from this myopia.
If we're to build the systems of the future, I think we must set our sights above first-order issues. To afford the time to do so, we may need to reconsider, or even abandon, some concerns and practices that currently constitute much of what we call software engineering. Here I propose a hierarchy of concerns, ordered by the degree to which they reduce system complexity from lowest to highest.
I use the word "fixations" to denote those concerns that programmers often argue about which generate more heat than light. Some examples include code style, line length limits, repository layout, unit test coverage, avoidance of GOTO, and other "best practices," but this list is merely suggestive. Fixations are self-imposed constraints that prematurely restrict the set of possible implementations (set A) to a subset of implementations that are comfortable to the engineers who impose them (set B). Rarely, if ever, is it demonstrated that the set of optimal solutions (set C) is a subset of B.
Fixations are often adopted to solve problems that the team does not have, and may never have. There are cases where a GOTO is the perfect choice -- even Dijkstra admitted as much -- but many teams will flatly reject code that includes even one GOTO because "GOTO can make the code hard to read." Yes, we've all read Dijkstra's paper and understand the problems of excess GOTOs, but the question is not whether a tool used in excess causes problems, but rather whether the use of the tool in this particular case has in fact created a problem.
The worst thing about fixations is that they generate work that does nothing to reduce the complexity of the business problem. They become a continuing source of puzzles for engineers to solve. The complexity compounds when the satisfaction of one self-imposed constraint conflicts with that of another. For example, line-length limits often conflict with indentation rules, so programmers spend time searching for the least-ugly compromise. I have seen a mob programming group of 6 engineers spend 45 minutes fixing these exact problems to satisfy their linter. This is waste.
There are reasonable arguments to support the myriad views surrounding these kinds of concerns, but that's precisely the problem. If you can go either way on a particular issue, it can't matter that much. It would be a better use of time to not worry about it at all by increasing our fortitude toward trivialities. One heuristic we might use to recognize fixations is this: Before you offer a criticism in your next code review, ask yourself, "would I still be as concerned about this if the entire program fit on a half-page?" If the answer is "no", then use the energy you would expend on criticism to figure out how to make the program shorter.
[...] Looking back, we see that the hierarchy defined above moves from first-order, everyday programming concerns, to higher-order architectural concerns. Even more interesting, as we move up the hierarchy, aspects of the problem domain that were explicit at the lowest level become more and more implicit as we move up the hierarchy.
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @01:54PM
There are plenty of research papers on all those methodologies. The fact that you have choose not to look them up and read them doesn't mean they don't exists. It just means you've chosen to have an anti-vaxers level of understanding of your own field. And just like them you're proud of it.
All of them try to solve specific problems. If you don't have or don't care about the specific problem each is trying to solve then you shouldn't use them. Of course people push them beyond what they're supposed to do and advertise them as silver bullets, but when was the last time you saw an honest ad? If all you do is hear ads and read blogs about a subject, you have a completely distorted view of it. Yes, most books on a subject should also be consider ads. A ton of media is created these days to soak up your money rather than explain the technical aspects of something. That's why your first stops should be reading the manual and reading the research papers. Textbooks on the topic area, rather than on a specific tech product, are normally good too.
Programming already passed though an enlightment era. We don't learn from our own history.