Slashdot Mirror
The Software Inferno
CowboyRobot writes "The Software Inferno is a tale that parallels The Inferno, Part One of The Divine Comedy written by Dante Alighieri in the early 1300s. That literary masterpiece describes the condemnation and punishment faced by a variety of sinners in their hell-spent afterlives as recompense for atrocities committed during their earthly existences. The Software Inferno is a similar account, describing a journey where 'sinners against software' are encountered amidst their torment, within their assigned areas of eternal condemnation, and paying their penance. Quoting: 'CANTO 6 - HERESY: ...The countess explained that these chaotically traveling souls were strongly at variance with well-established beliefs and laws of software engineering developed by experts on the subject. Their unabashed contempt for universally accepted truths spawned decision making that wrought great damage upon software projects in their charge. Some challenged Fred Brooks' sacred counsel in futile attempts to rise above their failings by adding new people with woefully insufficient qualifications to rescue already-late projects. Others flaunted their derision by disregarding software design patterns sanctified by the Gang of Four, instead opting for inelegance of their own in attempts to solve problems whose solutions were already proven, well known, and time-honored.'"
Gives me chills when I see people talking about tech like it was a religion.
Others flaunted their derision by disregarding software design patterns sanctified by the Gang of Four, instead opting for inelegance of their own in attempts to solve problems whose solutions were already proven, well known, and time-honored.
Says someone posting via heretical Von Neumann Machine, long live Turing Machines!
Posted via Android on ARM hosted in Linux on x86-64 running in 32 bit mode!
Those knowledgeable of Cybernetics, Genetics, or Information Theory emit the most holy evil-grin when confronted with the term "Design Pattern".
It's entertaining, typically weird article from Bell. They're a bit snarky but somewhat long-winded - his penchant to build classifications of things overrides any real deep-dive into what he's talking about. And his daughter appears in every article, I'm surprised there isn't a "17 types of annoying child" article yet.
His other complaints: UML, XML, Agile misuse/overuse - each with an article, blog post that has invented classifications.
Where's the one on "taxonomy joke" overuse?
This is just a slashvertisement for some bloke's paper. It's a reiteration of well known mantras, at best. Nothing to see here, move along.
I figured that out just by content. I hovered the mouse pointer over the first link, saw it lead to noplace likely to have real news, and decided I'm not playing that game.
TLDR. Too Lame, Didn't Read.
Seriously, the firehose readers that vote this crap up really need to clean up their act.
Sig Battery depleted. Reverting to safe mode.
While I don't completely disagree with you, "good code" seems to imply a judgement based on some values. In enterprise systems, the transferability, maintainability and self-documenting concepts in code can play as much a role as footprint, security and speed. Not all systems are dancing on the edge of "too big" or "too slow" - they are closer to failure because of "poorly defined", "too fragile" and/or "too esoteric". .NET componentized form because they burn through developers every 2 years, like the industry avg. If your job stops as "stable and secure" you may not really be contributing to a software system portfolio like a large company needs.
A company may want to keep modules in plainspeak, well-documented and slower
Part of the fun of the Divine Comedy at the time was that specific individuals were shown being tormented, and this doesn't do that.
It totally should.
1) Does the code work/fill the requirements? (high efficiency might be a requirement, or it might not. Same with cross-platform compatibility).
2) Is the code readable? If not, it doesn't matter how great your design is, people who come after you will rewrite it.
3) Is the code flexible? If not, your design is more a hindrance than a help.
Code that fills all three of those is rare and beautiful.
A good programmer is busy writing / testing code and doesn't have the time or the need to read and remember books
A good programmer is always looking to improve his skill in any way available, including reading.
"First they came for the slanderers and i said nothing."
To be fair, their original intent was to help with communication, so they looked at patterns people had been using and tried to put them into a simple taxonomy so that programmers could talk to each other about how they structured things. It was less about 'there is a problem, this factory pattern will solve it' and more 'I used a factory pattern, now you have an idea of what to expect from this code'.
The aspects you look for in code are as follows:
The list can be reduced to:
1. Does it serve the users well.
Note that I have not said, "does it do what the users asked for" or "what the user wants". Users may make requests that fall short of what is possible, or are impossible, or will not be workable in the long run. Part of your organization's job is to let the user know what will work. Part of your job is also to surprise the users in a pleasant way. Pleasant surprises are "oh wow, we can use keyboard shortcuts for that now" as opposed to "we re-arranged the UI and added dancing bears because everybody is doing that now".
Anyway, I digress. It all reduces to the one rule cited.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?