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: 3, Informative) by BsAtHome on Saturday September 07 2019, @08:50PM
This is related to painting the bikeshed problem (see http://bikeshed.org/ [bikeshed.org] and https://en.wikipedia.org/wiki/Law_of_triviality [wikipedia.org]).
Solving higher order problems requires both experience and talent. When you cannot grasp the complexities of higher order problems then you still want to put "your mark" on the project. This is done by opening discussions on first-order problems, which, in effect, is painting the bikeshed.
You need strong project management to solve the problem. Project management is not hierarchies in the traditional sense. Good project management is a communication channel that makes everybody both appreciated and will give their best effort. Project management is a steering machine that nobody notices when done right. That makes it so difficult.
(Score: 0) by Anonymous Coward on Saturday September 07 2019, @08:51PM
There is a big difference between architecture and craft. A true Master masters both to perfection. That's called Art. Discrimination is the key. In software, the Art is very rare to find. Any formalism is ephemeral and dependent on cultural context.
(Score: 1, Insightful) by Anonymous Coward on Saturday September 07 2019, @08:55PM (4 children)
Kind of hard to be afraid of goto if you first learned assembler. All those different jmp mnemonics are just jumps (absolute or conditional).
That's what your compiler ends up emitting, so it's much ado about nothing.
As for lint, I only worry about bellybutton, pocket, and dryer lint. And with advances in fabrics, I haven't seen bellybutton lint since at least the 90s.
I like that my programming style is significantly different that I can tell when someone else has changed something, or I can point out that I didn't write that section because it's not my style. Style let us catch one co-worker who was spending his time plagerizing code, would just check it out at the beginnong of the day, then check it back in with no changes. We could all tell the various workers he swiped code from at a glance once we started looking for it.
Mind you, in the future, humans probably won't be writing code at one point. Either our artifical intelligence progeny will be doing it (along with everything else), or we'll have destroyed all the infrastructure necessary for a technological society to function.
From our perspective, it's probably a loss either way. At least the folks with their noses buried in their phones on Facebook probably won't notice ...
(Score: -1, Offtopic) by Anonymous Coward on Saturday September 07 2019, @09:52PM
(Score: 1) by anubi on Saturday September 07 2019, @10:03PM
All too many times, GOTO has left me with the weirdest bugs in the stack.
If the language supports subroutines, a GOTO in the wrong place can net you a helluva lot of debuggin'.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 0, Troll) by Anonymous Coward on Saturday September 07 2019, @10:32PM (1 child)
You are as dumb/naive as the dumb piece's author. The GOTO was desecrated from the perspective of structured programming, where complex programs are built out of blocks and modules, where there is explicit entry/exit point so that we can better grasp how the whole thing flows. If anything, learning assembly ( which ever kinds of chips) would make you appreciate more why higher level languages discourage GOTOs.
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @03:14AM
FALSE - Please learn your craft.
A "return" in middle of a code is just as bad.
A "goto end" is clear and better at documenting the intention.
Now a "goto X", where is X is not even in the code segment... that person should be "shot".
A "goto" and can keep code clean and structured, specially helpful is case and turning logic, but only if tuaght to use them correctly. Problem no one teaches the right use, just "Only fucking morons use them!".
(Score: -1, Flamebait) by Anonymous Coward on Saturday September 07 2019, @09:36PM
Another wet-behind-the-ear douchebag spews rambling nonsense screaming "i'm so smart".
Better to have posted another quality aristachu post instead.
(Score: 1, Insightful) by Anonymous Coward on Saturday September 07 2019, @11:24PM (1 child)
You think it's bad with linters? Try to work around incoming industry "standards" like Misra-C and watch your codebase turn to a toxic waste dump of workaround spirals to satisfying the unsatisfiable combination of: working software + compliant software.
Everything methodology police go about, from linters, to TDD, to code reviews, XP, to agile is the industrial equivalent of a superstition. Backed by 0 scientific evidence and each one alone capable of bringing a software project to its knees under the sheer weight of bureaucracy and lost time.
We laugh at homeopaths, but we don't blink an eye at the notion that Hungarian notation will make the code better. Programming is still a pre-enlightment profession.
(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.
(Score: 2) by bzipitidoo on Saturday September 07 2019, @11:32PM (9 children)
There is reason to focus on first order issues. Programming languages are still overly verbose and redundant, and that goes all the way down to the level of the notation, syntax, and even individual characters. For example, why are we constantly exhorted to use Proper indentation in languages that do not need it because they use curly braces? To both indent and use brackets is redundant. Most expert programming language designers are too high minded, too dismissive of this "trivial" problem. LISP is perhaps the best language for illustrating another first order problem: excessive parentheses. Lots of solutions have been proposed, but seems none have been adopted. And that's in part because experts dismiss that problem as trivial.
Picking on such rigid rules as line length limits and "no GOTOs" is beating up a strawman. As first order problems go, those are just stupid. They're not limitations of the programming languages, they're additional, imposed limitations. Proper Indentation is also self imposed, but at least that one doesn't force coders to make awkward compromises.
Experts want to focus on the tops of the structure, when the foundations are still unsettled. Certainly, the difference between a good algorithm and a bad one can outweigh all other considerations. But a cleaner programming language could do a lot to bring programming to more people. At the very least, a good, clean language could take away some of the trivial issues that incompetent programmers seize on to sow confusion, avoid facing the tough questions, and dodge the risk of being exposed as posers, frauds, and bandiers of IT lingo.
(Score: 2) by c0lo on Sunday September 08 2019, @12:10AM (1 child)
For the machine/compiler, yes.
Over the years, I had spent too many hours searching for a bug that I found in column numbers in over 150.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @03:22AM
It is why prettyprint exists. force code on check-in thought a "standards keeper" to correct the error and the error is no more.
Been doing that since the early 80's. solved LONG AGO and FAR FAR AWAY. Biggest help was in setting up multi-lingual system. Found lots of constants directly en-code in the code. Externalize externalize externalize. Tehn all can be right.
(Score: 4, Interesting) by optotronic on Sunday September 08 2019, @01:50AM (5 children)
Think of it this way: the brackets tell the compiler where the block starts and ends, and the indent tells the humans looking at the code the same thing. While I could figure out where the blocks are without indenting, it would take a lot longer. I'm not convinced that's just because it's what I'm used to.
Sure, Python does away with brackets, but in my opinion it makes it too easy too make a block-leveling mistake. And copying/pasting code becomes much harder.
(Score: 1) by khallow on Sunday September 08 2019, @03:05AM
Even if this were truly somehow redundant, redundancy still has a huge role in computing. For example, error correcting codes deliberately introduce redundancy. Yet we consider them quite useful - because there are errors to correct (or at least notice). Similarly, here there are errors that can be caught and corrected because of attention to such details.
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @05:48AM (1 child)
Python's problem is that it allows both tab and space for indentation, and when both get used, it gets messy not only visually but also for parsing. I try to pass the source through a filter that replaces all tabs with set number of spaces before editing.
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @08:27AM
Specifically, Python's problem is that it allows *mixing* tabs and spaces. Using either/or is and has never been a problem except for the most petty-minded.
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @08:30AM (1 child)
How does it make block-leveling mistakes easier, when it would change the operation of your code, so make their presence easier to spot?
You say that like it's a bad thing
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @12:02PM
We live in an age where people copy code from web pages.
Think about that for a moment.
I do not voluntarily code in Python. It's my opinion that only a sadist could have come up with it.
This from an ex-COBOL developer should say something. Loudly.
(Score: 2) by hendrikboom on Sunday September 08 2019, @03:35AM
It's quite useful to get a compiler warning when the indentation conflicts with the brackets.
-- hendrik
(Score: 2) by darkfeline on Sunday September 08 2019, @05:14AM (3 children)
Most of the summary is sensible, but
> The worst thing about fixations is that they generate work that does nothing to reduce the complexity of the business problem.
Complaining about following the style guide is a red flag. It could indicate the mentality of "I'm too good for the style guide that the rest of the team/project uses. I want to write code MY way, and the rest of you suck it." No matter how amazing they may be, you do not want this person on your team/project.
What's in the style guide is not important, but the style guide is important. Pick a style and stick with it. It's the same with natural language writing (e.g., the Chicago Manual of Style, the Associated Press style guide).
Join the SDF Public Access UNIX System today!
(Score: 0) by Anonymous Coward on Sunday September 08 2019, @12:09PM (1 child)
Or the style guide itself could be a red flag. Indicating that the company thinks that the placement of braces, or tabs verses spaces, is a more essential issue than writing functional, adaptable code for the business.
I have seen enough style guide compliant software to know that style has NO EFFECT on code quality whatsoever. So what is the point of making every worker on a creative project paint with the same brush?
(Score: 0) by Anonymous Coward on Monday September 09 2019, @02:56AM
True, style guides have no "direct' impact on quality, but it does have an indirect impact on the quality. At the end of the day, if you're in a commercial setting, total cost of ownership matters. Anything that increases that directly/indirectly is an issue.
Even something is as crude as a style guide affects that. If every single developer that passes through have their own style, it add just a little more overhead to everyone both existing and new coming through the organization which increases the TCO. If the company's cost increases it may be force to cut spending and lower its bar on dev cost leading to poorer quality devs and ultimately poorer quality code.
Sure it might be a stretch to say a style guide in on itself can contribute to a meaningful change in TCO, but its the thought behind it that is applicable to everything else you do in the SDLC process. Getting the right balance of just enough convention and flexibility to get the optimal TCO is still an art form - one that a lot of folks don't even understand exists let alone appreciate.
As someone mentioned, there's no perfect style guide, pick one sensible form and stick with it.
(Score: 2) by hendrikboom on Sunday September 08 2019, @12:10PM
How about a discussion about how fixing not only the style guide, but also the language, is damaging to a project?
For an example to start discussion, see STEPS Toward the Reinvention of Programming, 2012 Final Report Submitted to the National Science Foundation (NSF) October 2012 [vpri.org].
How they made a rather complete system in less than 20,000 lines of code instead of the many millions in conventional systems.
Let me quote: