The Software Inferno 109
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.'"
A bit obtuse (Score:5, Insightful)
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?
Re:The Group of 4? (Score:5, Insightful)
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
Re:So, which is it? (Score:5, Insightful)
Re:Always a little creepy (Score:4, Insightful)
Yes... and there's a similar challenge produced by the influence of Milton's "Paradise Lost".
These two are a major source of what the general public -thinks- they know about historical Christianity.
Re:A bit obtuse (Score:4, Insightful)
Now, get off my lawn, if it's not vacuum tubes in accumulators, it's useless! We don't need these newfangled 'registers' and 'assembly languages,' we have patch wires!
Re:The Group of 4? (Score:5, Insightful)
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.
Re:So, which is it? (Score:2, Insightful)
Need mod points now... grrr
Anyone who believes "developed by experts" is a stamp of quality, is in no position to judge others.
Re:So, which is it? (Score:4, Insightful)
Re:The Group of 4? (Score:5, Insightful)
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.