Slashdot Mirror
More Than Coding Errors Behind Bad Software
An anonymous reader writes "SANS' just-released list of the Top 15 most dangerous programming errors obscures the real problem with software development today, argues InfoWeek's Alex Wolfe. In More Than Coding Mistakes At Fault In Bad Software, he lays the blame on PC developers (read: Microsoft) who kicked the time-honored waterfall model to the curb and replaced it not with object-oriented or agile development but with a 'modus operandi of cramming in as many features as possible, and then fixing problems in beta.' He argues that youthful programmers don't know about error-catching and lack a sense of history, suggesting they read Fred Brooks' 'The Mythical Man-Month,' and Gerald Weinberg's 'The Psychology of Computer Programming.'"
The most common errors: SQL injection, command injection, cleartext transmission of Sensitive Information, etc.
People make mistakes. Software needs to ship, preferably yesterday.
How much would it cost to have perfect software? I happen to have worked in an industry that requires perfect coding. So I can imagine what it would look like if Microsoft tried it.
The debugger would cost half a million dollar per seat (gdb is free). There would be an entire industry dedicated to analyzing your source code and doing all kinds of proofs, coverage, what-if analysis and other stuff that require Ph.Ds to understand the results.
The industry I'm referring to is the chip industry. Hardware designers code pretty much like software developers (except the languages they use are massively parallel, but apart from that, they use the same basic constructs). Hardware companies can't afford a single mistake because once the chip goes to fab, that's it. No patches like software, no version 1.0.1.
It's just not practical. Let the NSA order special versions of Office that cost 10 times the price and ship three years after the consumer version.
But for me, "good enough" is indeed good enough.
--
FairSoftware.net -- work where geeks are their own boss
Fred Brooks's 'The Mythical Man-Month',
I read that as "the Mythical Man-Moth." I bet that would be a great book.
Kwisatz Haderach
Sell the spice to CHOAM
This Mahdi took Shaddam's Throne
It would have avoided the embarrassing typo of 15, when in fact the article states 25. Oops!
Someone must be counting in the wrong number base or something, because the article clearly states 25 in about a million (in base 400) places.....
In the early '80s there were no "older" programmers unless you were talking mainframe data processing. On microprocessor CPU systems the average age was low, as I recall. Back then we didn't blame poor software on "youthful programmers". We blamed it on idiots who didn't know what they were doing. I think it's safe to say that much hasn't changed.
The waterfall method is still the best development model. Uou have to analyze, then plan, then code, then test, then maintain. The steps need to be in order and you can't skip any of them. Unfortunately waterfall doesn't fit into the real world of software development because you can't freeze your requirements for so long a time. But cyclic models are a good second place, because they are essentially iterated waterfall models. When you boil all the trendy stuff out of Agile, you're basically left with a generic iterated waterfall, which is why it works. The trendy crap is just so you can sell the idea to management.
Don't blame me, I didn't vote for either of them!
10. Writing '15' instead of '25'
modus operandi of cramming in as many features as possible, and then fixing problems in beta.
Sure his waterfall method works when you can guarantee that 100% of the features/functions you need in a product are determined during a Requirements phase. However, when company X will buy $10m of your product if you paint it red; then you agree to it; let the date slip and paint it red.
The industry I'm referring to is the chip industry. Hardware designers code pretty much like software developers (except the languages they use are massively parallel, but apart from that, they use the same basic constructs). Hardware companies can't afford a single mistake because once the chip goes to fab, that's it. No patches like software, no version 1.0.1.
Yeah...Right:
-There is never a revision AB/BB silicon
-Microcode updates don't exist
-No hardware designer has ever had to ECO something in
-The synthesis program NEVER makes mistakes
-The formal equivalence program is perfect
-The simulation environment is perfect
Keep dreaming...
Yeah, those good for nothing programmers cramming in features all over the place and not ad-hearing to time honored development practices like waterfall!
And requirement changes? WTF are those? Using waterfall you specify your requirements at the beginning, and these are then set in stone, IN STONE! Nothing will ever change in 6 -12 months.
It's not like they're working 60-80 hour weeks, been forced to implement features, having new requirements added and not being listened to! That would be like marketing driving engineering! Insanity!
As an aside - why is he dragging OO into this? Pretty sure you can use waterfall with OO - you even get pretty diagrams
The list is actually 25, not 15.
Most horrible projects I've seen were "extensible frameworks" that can do just about anything with appropriate extensions (plugins or whatever). But currently, without any existing extensions, it is bloated pile of crap. Also, there is nobody in sight willing to make one extension for it (except sample, done by author himself, on how to easily create extension).
839*929
I've heard from several ex-Softies that the company inculates its recruits with a serious dose of übermensch mentality: "those rumors about history and 'best practices' are for lesser beings who don't have the talent that we require of our programmers." "We don't need no steenking documentation," in witness whereof their network wireline protocols had to be reverse-engineered from code by what Brad Smith called 300 of their best people working for half a year.
However, I'll note that they were right: anyone who wants to say that they did it wrong should prove it by making more money.
Lacking <sarcasm> tags,
7.
If people refused to use and pay for buggy applications, they would either get fixed or die off.
Combination - fun iPhone puzzling
of.
Which is precisely why I would *never* in a million years hire a programmer under 30, and rising.
I interviewed someone who became proficient enough in computer programming to get a masters degree from what was, when I was in school, an amazingly advanced Comp Sci program -- who didn't know what a linker does.
Oh great a rant by someone who knows nothing, providing no insight into a problem.
Must be an Op-Ed from a media pundit.
And they wonder why blogs are replacing them?
I work at Microsoft. We use agile development and almost everybody I know here has read the Mythical Man Month. Get your facts straight before taking cheap shots in story submissions. Thanks.
Most companies simply refuse to spend the money do get it right. The reason that early programmers didn't have as many bugs is that their development efforts had virtually unlimited funding to resolve errors, because a bug in the system was far more expensive relative to the cost of development (compared with today, where you can reboot the machine and try again in 5 minutes "for free").
The reason that Microsoft or any other company finds itself using these methods of cramming everything it can into a build and then BETA testing is because of some marketing group who told the world that the product could be built in half the time that it really takes. I really don't see that business model changing anytime soon but it will definitely continue to cause engineers grief since it basically feels like we are always living a lie. This capitalistic world we live in will not allow this to change I fear
A waterfall process and object-oriented design and programming are orthogonal issues. The summary, at least, is nonsense.
For the life I me, I can't figure out what the choice of {waterfall vs. cyclic} has to do with {writing code that checks for error return codes vs. not}.
Waterfall vs. cyclic development is mostly about how you discover requirements, including what features you want to include. It also lets you pipeline the writing of software tests, rather than waiting until the end and doing it big-bang approach. Whether or not you're sloppy about checking return codes, etc., is a completely separate issue.
Despite the author's protests to the contrary, he really is mostly complaining incoherently about the way whipper-snappers approach software development these days.
Most of the teams I've had contact with inside the tools group at MS (in the last four years or so) use SCRUM.
I don't know how widespread that is in other divisions (say the MSN/Live folks or the Microsoft.com teams) but that clever comment in the submission is nothing more than an ignorant cheap shot.
Don't be so twitterish and make up crap about Microsoft. Get your facts straight or you just come across as an idiot.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Dr. Royce used it as an example of a methodology that doesn't work, but what he described was easy to understand so it gained traction with management types. It's like the joke where the guy says he's looking for a lost quarter under a streetlamp because the light is better than where he lost it.
http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf
I think his suggestion was to 'build it twice' via prototyping to discover what was missed in the requirements gathering and design phases.
nine!
The fact is that software development is very difficult. I think there are several reasons why it is more difficult to develop robust software now than it was 20 years ago. Some of these reasons are:
I'm sure there are more causes and other folks will chime in.
As long as:
You will have buggy, insecure software.
Fast. Cheap. Good. Pick any two.
The market has spoken, and said that they would rather have the familiar and flashy than secure and stable. Microsoft fills this niche. There are other niches, such as the Stable and Secure Computer market, and they're owned by the mainframe and UNIX vendors. But these aren't as visible as the PC market, because they need not advertise as much; their reputation precedes them. But they are just as important, if not moreso, than the consumer market.
The society for a thought-free internet welcomes you.
The software industry gets away with it, because they can.
-Becase software is 'licensed' with :
-NO WARRANTY
-NO 'FITNESS FOR A PARTICULAR PURPOSE'
-May Contain ERRORS/OMISSIONS
Taken from the license agreement of 99.999% of the software out there.
Programmers are responsible to nobody. Shoddy work, because users have no recourse, nobody to sue, no rights to complain, etc.
9.
Fuck.
The biggest impact on software quality is putting the release schedule in the hands of businessmen. speaking as a former (long ago) MS SDE, the coders I worked with there were at least as good as a random developer (frequently /much/ better). However their job is to code things in triaged order, not make release schedule decisions. When the execs tell everyone to stop typing and RTM, then that's it. The state of the software is generally known prior to ship because of their full-time /real/ QA teams with ad-hoc testing, automation, and metrics that are all much better than all other teams I've been on before or since. Don't rag on the MS devs for their suits' decisions to release with known bugs.
I find it more than a little amusing that summary mentions waterfall method being a time honed, excellent example of how all software should be made. Here's the history of the none existent waterfall method has to say about it.. Waterfall Method does not exist!
An experienced programmer can differentiate the concept of "can" from the concept of "should". For a younger, novice programmer, the concept of "can" and "should" are one in the same.
The real source of the problem isn't the development model itself, but in the way Management does its own job. This isn't anything new. Ten years ago, I was working for a small software company (less than 100 employees), and was told by the owner to meet the promised deadline "at any cost". He was quite happy with fixing bugs later "when the customer complains about them", telling me that this would allow them to promise the customer a new (later) deadline. The result was an endless stream of unhappy customers, and a rapidly deteriorating reputation in the field.
In my experience, delivery deadlines are made by management hacks to meet customer requirements, instead of the restrictions placed upon the project by budget (only so much money for resources) and Physics (only so many hours in the day), and not the poor schleps tasked with meeting those impossible dates.
Good. Fast. Cheap. : Pick two. Or, to quote Star Trek's Montgomery Scott: "I canna change the laws of Physics, Captain!"
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
ME. Vista is still in 2nd place compared to the Millennium Edition. I know, I've used both.
I dream of a better world... one in which chickens can cross roads without their motives being questioned.
Waterfalling your entire project will doom it to failure. But that doesn't mean you you don't use waterfall on a small level. Most modern techniques are iterative versions of the waterfall model. You take a small chuck, plan it, spec it and ship it. If somebody thinks you scale waterfall to an entire project, well, get with the times gramps.
Scaling waterfall to a large project is a huge waste of resources. It would require your usability dudes, marketing dudes and stuff to do the plan and then sit idle for the remainder of the project. Likewise your programmers would only be usefully in the middle part and your testers in the final stages.
Lord help you if something changes. And guess what, it will change because this is reality and not the "good old days when I was a kid programming on punch cards uphill in the snow" that gray-beards wax poetic about. Unless you are designing an "about box", nobody knows the problem nor its solution initially. It takes many iterations to get to both a definition and a solution.
Waterfall died long before I ever entered the scene and it cracks me up when I hear people still promoting it as a good idea. These days we just sit down in front of the keyboard and click buttons in fancy "IDE's" using un-proven things like "Object Oriented Programming". Kids these days... we don't even manage our memory, the garbage collector does it for us. ;-)
You're all niggers in a troll thread
It's just another "I have 40 years of experience doing X... Damn kids these days. Get off my lawn." Hey, here's something to chew on -- I bet he screwed up his pointers and data structures just as much when he was at the same experience level. Move along, slashdot, nothing to see here. I will never understand the compulsion to compare people with five years experience to those with twenty and then try to use age as the relevant factor. Age is a number... Unless you're over the age of 65, or under the age of about 14, your experience level is going to mean more in any industry. This isn't about new technology versus old, or people knowing their history, or blah blah blah -- it's all frosting on the poison cake of age discrimination.
P.S. Old man -- reading a book won't make you an expert. Doubly so for programming books. I'd have thought you'd know that by now. Why not get off your high horse and side-saddle with the younger generation and try to impart some of that knowledge with a little face time instead?
#fuckbeta #iamslashdot #dicemustdie
The main point he's making, I think, is a little hidden: "At least we had a model."
The problem with almost every software development department I've seen so far is that they rely entirely on the abilities of their coders. The few guidelines they have for coding style and documentation can be called something like a "standard", if you are gracious. But that's where it ends. There are few processes above the code level. Many heads of software developments can't answer trivial questions that are perfectly normal in every other industry where stuff is being built or developed - like "how many known problems do you have at the moment?" or "what is your margin of error before you pull the product?" or even just "what's the date of your last QA?".
So don't bother them with anything more complicated, like a development process. They think "process" is another word for "deadline" because that's what the process consists of "ship on this date, or as close as you can manage". That's it.
Assorted stuff I do sometimes: Lemuria.org
From the article:
"Shockingly, most of these errors are not well understood by programmers; their avoidance is not widely taught by computer science programs; and their presence is frequently not tested by organizations developing software for sale."
Shockingly programmers are not all knowing. Programmers are also, oddly, doing very poorly at designing against and testing for things that have not and are still not being identified as major issues within the academic community that produces programmers.
This is a field that has become vital to many businesses in the developed world. It is a field that is very young compared to other scientific and engineering disciplines. It is a field that is undergoing major changes because it isn't working with set rules of nature, but instead is built on top of the changing products of other disciplines.
Indeed.
The reason software is so bad is that the customers absorb the cost of defects. That's a political decision. Cars used to be that way; today, if a car even stalls unexpectedly, that's considered a manufacturing defect. In the US, the manufacturer has to pay for the recall to fix the problem. Cars are far more reliable, and much safer, as a result.
In a few industries, the software developer is financially liable for errors. The gambling industry works that way. The companies that run lotteries pay back a few percent of their revenue as penalties for failures and errors. (And they try very hard not to have expensive errors.)
Back before the Bush administration caved on the Microsoft antitrust case, I proposed the Full Warranty remedy. The FTC took a look at this issue in 2000, but the Bush Administration didn't do anything. It may be time to revisit this.
They aren't to blame. They dont care. That is fine.
Rule number one of being a programmer: nobody but you gives a shit about what you've done. They only care if it works (using *their definition of works, not yours*), it is is fun, and it is easy to use.
This rule is a tough pill to swallow because dammit sometimes you just feel proud of whatever crazy coding stunt you pulled off. But the sooner you learn nobody but you cares *how* something was done the happier you will be. Happy you say? Yes happy. Why? Because maybe you'll refocus your efforts into things that *will* make your users happy instead of tech-crap like shaving .25ms off a database query (one of my favorite jobs). Things like a good interface or fixing a silly but annoying bug will make them way more happy then refactoring your pile of spaghetti code.
Happy users = happy programmer. The reciprocal isn't always true. Sure swapping out the template system for something cooler is fun and makes you happy, but unless if adds something new or fixes something for the user, you've wasted your time.
Anytime you say "If people do blah", the problem isn't with the people, it is with your argument. "If everybody did blah" means "what I want is impossible, so maybe I'm the one who is wrong".
The reactionary forces of the twentieth-century United States finally conceded defeat and shut down the Five-Year Plan Tractor Plants of Detroit, where ridiculous oversized transport was bashed together by semi-literate peasants between fifths of vodka from the nerve gas factory next door, and the Five-Year Plan Software Plants of Redmond, where ridiculous oversized operating systems were bashed together by semi-numerate fresh graduates between fifths of Red Bull.
Hiring in most Microsoft divisions has frozen in the last six months and 30GB Zunes are already on suicide watch. "The workload's impossible to keep up with," said blog technical evangelist Gary M. Stewart. "I've even been answering Slashdot comments on Boycott Novell or Groklaw. It's impossible to keep track of! Anyway, you're just another Twitter sockpuppet. Or Mini-Microsoft. Admit it."
http://rocknerd.co.uk
Several posters have alluded to this, but I blame the Internet. Just follow me here:
- Back in the 'Old Days', productivty software at the time was dominated by WordPerfect, VisiCalc and then 1-2-3, and what else? MS-DOS as the operating system. Everything shipped on diskettes. There was no Internet.
- Fixing a major bug in WordPerfect required shipping diskettes to users, usually under 'warranty'. Expensive, time-consuming, and fraught with uncertainty.
- Fixing bugs in MS-DOS really wasn't done. It was a minor release. Again, diskettes everywhere, and more costs.
- Patch systems were important. Holy wars erupted on development teams over conflicting patch methods, etc. Breaking someone else's code was punished. Features that weren't ready either waited for the next release or cost someone their job.
Today, patches can be delivered 'automatically'. It take how long, seconds, to patch something minor? Internet access is assumed. the 'ship-it-now' mentality is aided by this 'ease' of patching.
If it weren't for Internet distribution, we would see real quality control. It would be a matter of financial survival.
No, Internet distribution is not free. But it's both cheaper, I suspect, than shipping any media, and also less frustrating to a user than waiting at least overnight (more likely 5-7 days) for shipment.
And it leads to the second distortion - Bug fixes as superior service. The BIG LIE.
It is not superior service to post a patch overnight. It is not superior service to respond immediately to an exploit. It is a lie. Having to respond to another buffer overflow exploit after years (YEARS) of this is incompetence, either incompetence by design or incompetence of execution. This afflicts operating systems, software, utilities, nothing is innocent of this.
The next time you marvel just a little bit when Windows or Ubuntu tells you that you were automatically updated, or that udpates are awaiting your mere consent to be installed, remember - they just admitted your software was imperfect, and are asking you to take time to let their process, designed with INEVITABLE errors expected, perform its task and fix what should never have been broken to begin with.
ps- I love Ubuntu. I cut it some slack 'cause you get what you pay for, and many who work on Ubuntu are unpaid, and any rapid response to problems is above expectations. Microsoft, Symantec, Adobe, Red Hat, to name a few, are not in that business. They purport to actually *sell* their products, and make claims to make money. When they fail to deliver excellent products, the lie of superior service is still a lie.
Just the voice of one who remembers when it was different.
pps - EULAs tell it all. I wish I had an alternative. Oh, wait, I do... envermind, lemme get that Ubuntu DVD back out here and... Except at work...
deleting the extra space after periods so i can stay relevant, yeah.
Taking a step back from the coding errors and even a step back from software development errors, there is a fundamental where failure to adhere to it will produce bad results from start to finish. This idea is not unique to software development but I see large software development projects that do not follow it fail on many levels. Problem statement: Automation is required to solve a specific problem. Each and every part of the project has a problem statement (or should). Gratuitous features are gold-plating. Take Microsoft Word, for instance. A large majority of the problem-solving features (WYSIWYG, spell-checking, grammar checking, etc ) were solved years ago. That means that most of what was left to provide had not much to do with solving the basic problem that the tool is designed for: Editing and printing documents. Yet Microsoft has to create an illusion of need so that consumers will be willing to shell out $400 for the next upgrade. Basically, this is gold plating on a huge scale. So, with no problem to solve, the developers have no fundamental rule to follow. Taking Microsoft Word to illustrate what happens with gold plating: Every single person in our company dislikes Office 2007. Microsoft completely changed the interface forcing the user to re-learn the most basic tasks. The code for the new interface functions perfectly. There are no apparent coding errors. The error was made at the top of the decision ladder. After several years of learning, users had no trouble navigating the tools and options. There was no problem to solve. Microsoft needed to feed its illusion machine so it created eye candy at the expense of the users. Microsoft just happened to be the biggest target, but this issue is apparent throughout the industry.
The article link says top 25 errors....
When you were working on those punch cards, using your green screen console (kids these days with color monitors and mice), what were you doing?
Did you ever transcode video and then upload it to some website called Youtube on "the internet"? Did you then play it back in a "web browser" that reads a document format that your grandma could probably learn? Did your mainframe even have "ethernet"? Or is that some modern fad that us kids use but will probably pass and we'll all go back to "real" computers with punch cards.
Did you ever have to contend with botnets, spyware or any of that? And dont say "if we used The Right Way Like When I Was Your Age, we wouldn't have those things because software would be Designed Properly". because if we used "The Right Way" like you, software would take so long to develop and cost so much that we wouldn't even have the fancy systems that even make malware possible.
Old timers crack me up. Ones that are skeptical of object oriented programming. Ones who think you can waterfall a huge project. I'd like just one of them to run a startup and waterfall Version 1.0 of their web-app (which, they wouldn't because the web is a fad, unlike their punch cards).
Sorry to be harsh, but get with the times. Computing these days is vastly more complex then back in the "good old days". Your 386 couldn't even play an mp3 without pegging the CPU, let alone a flash video containing one.
Until they try to bring in new-hires. How long does it take to train somebody who is used to modern office programs to use a DOS program like wordperfect? You think they'll ever get as proficient when what they see isn't what they get (a fad, I bet, right?)
Again, sorry to sound so harsh. You guys crack me up. Dont worry though, soon enough we'll see the errors in our ways and go back to time honored methods like waterfall. We'll abandon "scripting languages" like Ruby or C and use assembler like god intends.
Sheesh.
The worst I have had is the Senior programmers wrote code and then passed it off never to touch it again. It was assumed to be 'good enough' if it came from the Senior programs and then in QA the issues came back and a random method to the junior programs. Some of the Senior programmers could not write anything - 100% error code and never compiled. The poor junior programs typical said nothing and fixed everything. Guess who looks good at the end of project review - Senior guy who was in the PM view worked just the 8 hours a day and produced lots of and lots of code or the junior guy who spent a long time to fix everything and put in lots and lot of overtime. Next guess who got the promotions... Lastly take guess how many of the project turned out as a result of largely having junior guys write (fix) everything. Yeah I am working somewhere else and I brought along with me some of the best team members so we are highly skilled teams that works really well together.
is to blame for this. Once it became clear that computing/technology actually represented the first new "industry" of any scale in a generation, every school in the universe rushed to offer it as a career path and untold numbers of students whose only facility for the material is "I want to make money, so yeah, programming would be good" enrolled.
I was in CS for two years in the late '80s at a top ten department. Our computer science courses were theoretical and heavily mathematical, not tied to any single language, and trafficked in tons of theory, tons of hardware, tons of calculation and proofs, and tons of machine state diagrams.
In the course of two years we worked in C, C++, Pascal, Forth, various assemblers, Scheme, LISP, and a bunch of UNIX tools (sh, awk, perl, etc.) but the language was always merely a tool, not a worldview unto itself.
To this day, I (without a CS degree, even an undergrad one) can routinely solve problems that M.S. C.S. people get befuddled at. I can troubleshoot TCP/IP and routing problems once the network guys are throwing up their hands. They all think I'm a genius. In reality, I simply didn't learn utter shit at my CS department for the brief moment I was there.
Why did I leave? It was too difficult. :-) My grades were falling and I was getting in over my head in physics and math. I went into publishing (English degree) instead, and later into the social sciences.
But I find it constantly frustrating just how much our current society looks like H.G. Wells' time machine society. We have the Magic Machines that nobody (even the experts) really understand. The few people who do understand them are either retired, marginalized, or unemployed because the HR managers don't recognize a worthwhile, serious set of C.S. skills over a "got a degree in programming Java from Local U" resumes.
Geez! For people who are fortunate enough to work in the field they love, some of them sure complain a lot! Y'all sound like a gaggle of old crones kvetching about the new butcher in town.
Nitewing '98
Everything works...in theory.
I really get annoyed by so many people blaming users. At best it is just laziness. At worst is used as a cover for malicious action. As there is no perfect user there is no perfect user interface. Life with perfect users and user interfaces would be dull and unrewarding.
The user trade off that you propose to be at the crux of the problem is unlikely to be relevant. Users face many other trade offs before they ever get a chance to ponder the one you propose.
Blaming the user is a disgraceful habit the MicroSoft has done so much to advance. It is a shame to see others accepting it blindly.
Instead of links to your "funny" monetized blog (which is pretty much the only thing you do on Slashdot, thus the "spammer" label), you should also link to Roy Shitsforwitz' examples of libel and personal smears against Wikipedia users.
he lays the blame on PC developers (read: Microsoft) who kicked the time-honored waterfall model to the curb
The waterfall model is long-discredited and its downfall is nothing to do with Microsoft. Ian Sommerville in his Software Engineering book was discussing this in the early 90s. I recall a diagram of the spiral model which is very much like agile development, although we didn't call it that then.
Luckily Microsoft stepped in and bought the company, and now market the product as X-Box.
But modern software systems are orders of magnitude larger and more complicated than they used to be a few decades ago.
I mean, large software projects will contain millions or even tens of millions of lines of source code, all written a few lines at a time by humans.
Is it any wonder that software isn't perfect?
No matter how you put it. No manufacturer, ever, paid for the expense of risk. Or, rather, no manufacturer that's still in business ever did. Because guess what? If cost outmatches profit, the company goes under eventually.
So what would companies do when facing the risk of having to foot the bill for software faults? Simple, the same the car industry did to stay in your analogy: Assess it, put a price to it and add this to the price of the product. Simple as that.
Nobody takes a risk for free. Risk has a price, and that price has to be paid, and in the end it's the customer that pays it.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Tell the publishers of Software Engineering textbooks (i.e. $70 doorstops) that.
-- I prefer the term "karma escort."
Before you get into the nitty-gritty of the code I think many programmers need to better consider the end user and the user interface in their designs. Nothing is more stressful than interface options that are non-responsive. Limiting mouse clicks and mouse travel also increases user speed and limits the chances of repetitive task injuries.
"They who can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety" Franklin
Define Quality. Define "Secure" and define "Stable".
For extra credit, define them in terms of engineering cost/benefit. I'll wait.
PS: Any student who blames Microsoft will automatically fail the test.
I bought three Mercedes. Two of them got repossessed. Now, the dealers won't finance me when I go to buy another. Clearly, there is a shortage of Mercedes.
Look at your story. You had three programmers. Two quit (Yeah, I know, it wasn't because they were unhappy. Look, no one wants to be known as a malcontent or difficult. They lied to you.) Now, you can't get anyone in to interview who knows what they're doing.
You think maybe it's possible that your company's reputation precedes it? I know of half a dozen places in my town that nobody in their right mind would agree to work for.
Show me a man who says he can't find anyone to hire, and I'll show you a man nobody wants to work for.
Take that same man, triple the wages he's offering and wire a pacifier into his mouth and the ghosts of Ada Lovelace and Alan Turing will fight for the interview.
He put his boots up on the table and made a face. "The sig," he smirked. "You can waste your life in search of the sig."
But you'd be amazed at the blank stares and "what do I need that for?" when you ask some of those "programmers" about ... Big-O notation.
I don't know Big-O notation. Never learned it in school. I'm so ashamed!
No wonder I can't code simple algorithms like the Google PageRank system. Looks like I'm still stuck learning the Towers of Hanoi (recursive) algorithm.
Can we simply outsource the optimizing of complex algorithms to Computer Science interns? ;)
There was never a time honoured waterfall model, I quote Winston Royce that wrote the following under the diagram of the standard waterfall process:
the implementation described above is risky and invites failure ⦠The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed ⦠The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a l00-percent overrun in schedule and/or costs.
read craig lahman's overview of incremental and iterative methods to learn the real history.
Don't be so hard on them, I don't know how to do that either due to the fact that the set of numbers from 0 to 100 is infinite. However, if you meant integers, here it is: x=(100*100)/2
They didn't hate the job, they hated the software. It's a nice place to work and is too small to have a reputation bad enough to drive people away. In fact, I don't know why someone wouldn't want to write software here except that the software itself is mundane and cumbersome. We have no dress code, decent salaries, plenty of paid time off, a boss who is easy to deal with, and a foosball table. I'm beginning to think that our HR person just does a terrible job at finding resumes for me, but it's just a hunch.
...ironically the 16th error is the dreaded "off by 10" error.
"I think his suggestion was to 'build it twice' via prototyping"
;).
;).
They do that already except that they ship and sell the prototypes to the customers too
See the problem with software is:
When the "blueprint" compiles and mostly works, you ship it as version 1.0
When the prototype/"clay model" works, you ship it as version 2.0
When the first production build works, you ship it as version 3.0
After fixing some more bugs you ship 3.1
And why do you ship "blueprints" etc?
Because each step costs about as much, and sometimes the first step costs even more than the subsequent steps.
People often compare software engineering with civil engineering or other stuff, and ask "why can't software be just as good?".
For civil engineering, the cost of making a blueprint is usually a fraction (10%? ) of making the "real thing". In event of concerns/problems the bosses will be more inclined to spend millions to redesign that multibillion dollar skyscraper before actually starting to build it.
In contrast it should be no surprise that bosses are seldom inclined to spend millions to redesign "million dollar" software
The build phase of a skyscraper could involve thousands of labourers, machinery and could cost billions and take years.
Whereas the build phase of software often involves the programmer doing "make all" and going for a coffee break.
Civil engineering:
design cost << build phase cost
Software engineering:
design cost >> build phase cost
the high horse because when they get off they realized their just standing at ass level.
Quack, quack.
If you perform certain types of validation on a routine basis, write a set of common routines to do the work, and reuse them over and over again. Standardize your code. Define standard buffer names, sizes and buffer attributes, and make sure that anyone working on that code is acutely aware of the standards which are already in place.
Reject code that doesn't follow the standard. Even if it works otherwise.
Modular coding isn't rocket science, and one can be very structured and modular in any language. No OO needed. We had an extensive library of common routines, common buffers, etc. back when I wrote Fortran 66 and 77 code at my last major place of employment, and we have the exact same thing here on both the C and Fortran sides of life.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
It's called "coding for job security . . ."
It also comes with a companion use case "coding for future consultancy gigs . . ."
Kevin Smith on Prince
"Blame Microsoft"... the battlecry of losers everywhere.
This may shock and amaze FOSSies, but bad programming is not CAUSED by Microsoft, or Windows. Bad programming has existed as long as programming, and will always be around so long as people are creating software.
Last time I checked, even Teh Lunix was still releasing new versions. Guess that whole "if only they would take the time to code it right" thing only applies to MS, but never to FOSS.
The two books mentioned should be required reading for everyone in the field. I was lucky (or unlucky) enough that these were two of the first I ever read. The "unlucky" branch was spending the following twenty years wondering why almost no other book was as good as these two.
companies/executives/managers ... need to realize that software is simply a snapshot of the current knowledge to solve a problem. the code is an implementation of the combined knowledge of all the people that wrote the code. compiling or interpreting the code essentially takes a snapshot of that knowledge and applies it to the input. if the people that wrote the code have no knowledge, or very little knowledge, of computer science/engineerting, then you get stupid code.
as has been discussed in the comments, the level of knowledge of most "programmers" is abysmal. managers/execs hire flunkies that take a 2 month, "programming" course and set them to writing code. since they have little knowledge, the code is crap.
i've been lucky to work in several groups where the managers/execs understood that good programmers are first and foremost, knowledgeable. so when the code is compiled, that snapshot, executable, has knowledge in it. it's not just a shot in the dark at the problem. in addition, there are very few people in the group. and we're not solving small problems, one group i was with wrote a pcb (board) router and there were only 7 developers.
i've also been in groups were the managers cut corners on hiring. they would hire a few senior developers, then hire a boat load of "certified" coders. what a disaster. as one of the senior developers, i spent all of my time tracking down idiotic mistakes in the code. suffice to say, those projects never made it out the door.
schleprock
"I'm beginning to think that our HR person just does a terrible job at finding resumes for me"
Well, there's your problem...
You sound like a great, amiable guy who'd be a great coworker. HR is screwing that up for you.
Why are you letting HR dictate who you're going to get saddled with? HR doesn't bring you resumes, you should be taking resumes to them. Talk to your friends and acquaintences, guys in the users' group. People that you know can do the job.
"Hey, we need a coder for Project X. Ya want it, or know anybody?"
"Whatcha offering?"
"120K, 30 days vacation, free milk and cookies..."
"See you Monday morning."
.
.
"Hey, we need a coder for Project X. Ya want it, or know anybody?"
"Whatcha offering?"
"$4.25 an hour plus all the stress and scapegoating you can handle..."
"Gee, not really looking myself. Let me see if I can find anyone for you...."
Basically, with unemployment penciled in to hit nine percent next month, you WILL find someone competent to hire. You just have to be offering market rates.
He put his boots up on the table and made a face. "The sig," he smirked. "You can waste your life in search of the sig."
If you were a startup, would you use waterfall your first release? Who is your stakeholders in a startup? Oh wait, you are the stakeholder. That and your users, but since you are a startup on a shoestring budget, you can't afford to do proper usability research yet. Who is the "management"? Oh wait, since you are like programmer #1 or #2, odds are you are pretty much the management.
Go ahead, take your waterfall model that works so well for mission critical things like, well, whatever and apply it to web-anything. Go ahead, design your system The Right Way (tm). Let me know if your 1000 page thick binder containing The Specifications(tm) creates a product customers will buy, even when I'm positive you dont yet know what they will. And if for some reason you actually manage to ship a product before your competition, who aren't using waterfall, let me know how long it takes to ship the next version (or is your Master Specification so perfect you will never need a second version). And if hell freezes over and you IPO, let me know so I can short your stock.
Blah. Whatever. Waterfall probably works for some boring mega-project that needs a million different bureaucrats to sign off on any minute change. I'll stick with something that works in a more lively environment where where the cool stuff happens.
First three entries, and I'm already objecting to the list...
CWE-20: Improper Input Validation
CWE-116: Improper Encoding or Escaping of Output
CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
But CWE-89 is a special case of CWE-116.
So is CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
In the end there is the difference between the quality market and the price market, a different business model and thus a different way to compete. If you compete on quality and not so much on price it's possible to have the right kind of commitment to quality. If time-to-market is dominant (which is most of the time true) than you can expect sloppy development methodologies (like waterfall) and also it will be harder to retain people who are more quality minded. It might sound a little bit black and white, but from my kind of experience it makes all the difference. If been there and done that and than started my own business, I rather focus on quality and have more stamina for the long term. Anyone can compete on price, and most who compete on price in the end will be suffering a shakeout. If you have some passion as a developer and some passion for clients, you rather want to work with high quality developers and people who now how to make a business around great products. Quality means also greater challenges and less tension on idiotic number of features and put stability in the forefront of business.
I think what needs to be said is that ANY model can be driven into the ground by people who don't know what they're doing. Having good managers who can create and follow through with a working strategy is better than having the best laid plan that no one is following.
For the car analogy, you can't say 'well, if the car was better, he wouldn't have crashed' - the driver still neglected to stay on the road.
I have worked for 4 companies so far, and I worked on some projects on my own.
So far, I was able to see that coding is the least problem. Major problem with software are related to poor management i.e. lack of planning.
It is generally accepted that you cannot collect good specs, that user will change his mind in the middle of the project, that some initial design decisions will prove to be bad ones etc. But that is not an excuse for good ol' planning.
As a first, you have to decide what features you want to implement. But I have heard zillion of excuses just to avoid to make a list to start with. Because, if you make a list, then you are responsible for the list, and then someone can ask you about the list. So the solution is not to make a list.
Without feature list, there could be no good and precise architecture. And good architecture is significantly more important than good code.
Finally, once you have to make changes, noone will let you to do refactoring. It is impossible to make any significant changes if you don't change architecture. But refactoring is never calculated and financed. So you get bad product even it had a decent architecture in version 1.0.
Testing is first thing that is reduced if deadlines is approaching. Testers are not paid enough. Often they don't even exist, and programmers are notoriously bad in testing it's own code.
Programming is like shooting a moving target. But it does not mean that you can shoot randomly. Moving target means that you have to shoot more cleverly.
No sig today.
I'm afraid you've entirely missed the point. You may want to re-read your original post and my response.
Any further elaboration would come across as trolling, so I'll simply say good day to you.
It's nice to know that the daily wtf has expanded its negativity to new aspects of our profession.
Food.
That crowd mastered Old School marketing of junk. "Contains 10% RDA vitamin C!" (And nothing else.) Hooray for 4 cents. Now you can charge an extra dollar and market it as Enriched.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
"When did you code your first C application?"
If it was any older than 12 (twelve), I'd reject them. *I* did this, and I don't even consider myself to be a programmer."
So apparently Dennis Ritchie need not apply.
The guy who wrote the link you posted is kind of an idiot but he's also kind of right, at least about the problems with overly-rigid frameworks.
In spite of what he says, the 1970 Royce paper is generally accepted as the earliest mention of the waterfall method (see Wikipedia) even though Royce did not call it that. However, he did diagram it quite clearly in the form that is frequently used today.
I work for a large company that produces lots of software and the waterfall method is still mentioned seriously - something I find astounding as it's been seen as a very poor method since this earliest known mention. However, Joel Spolsky apparently sticks up for it and he often seems to have a clue. However, I suspect he may be working with small waterfall-like steps inside a larger, iterative framework.
None of us wants to bring back the _bad_ part of the old days, but your attitude is really stupid, if it is more complex, it is more important to do it right. I take, from your comments that you think that OO is the answer to a maiden's prayer and that you do not believe in prototyping and bottom-up feasability analysis.
... are crutches for those that wont think. Wordstar may be better for text input than Wordperfect. but nedit, kedit, joe ... would all do the job. I prefer vi (now vim) even on windows.
Simple, functional tools are almost always the best, especially for the non-technical non-specialist. Design patterns, use cases
Finally, the training argument is nonsense. If someone cannot learn the basics of using an editor in a day it or them need changing.
Finally the M$ approach leads to expensive crap, every time I see a document typeset in Word I cringe at the awfulness of it. Troff was better.
I'm not a million years old, but I've been around the block a little. Once upon a time, I used to do stupid programmer shit, but not anymore.
That was me a while ago, but these days I never run beta anything (unless there is a very compelling reason to do so). While I built my computer, I dont even know or care what speed it was or anything, all I care about is that it was high quality "boring" hardware (pretty much pure Intel).
What makes me laugh though is when people, especially tech people, get so god damn cranky and laggard they can't accept anything. I remember working with somebody who had to write some UI stuff in Visual Basic (gag me with a spoon) and he just couldn't get over the fact VB managed all the memory. All the time he'd mumble about how it must be a huge waste of resources and "Microsoft" must be doing something shady under the hood.
The thing is, I think a lot of us "kids" (i.e. under say 40) learned computers when they were just becoming mainstream instead of when they were mysterious things in basements. I think we see them in slightly different ways. Computing going mainstream was huge. Everybody had one and they are to this day so new that none of us really know what the hell we are doing it. We still have a lot to learn, things like usability, "development process" and such are still things we need work at.
Good times. But dammit, anybody who says back in their day code never crashed lies. Shit back then crashed *all the time* for no good reason at all!
But given the number of people on slashdot who seem to think the examples you gave are what we should be doing now, you can probably understand me mis-reading you.
The amount complexity may not have changed, but what is complex has. Is that what you are saying?
I think the point was supposed to be that the challenges in software development have merely changed over time. Software does a lot more than it did 30 years ago, mostly because the tools, languages, and computing resources have gotten a lot bigger/better.
It shouldn't really be all that surprising. Programmers likely aren't a lot better or worse now than they were 30 years ago, they just face a different environment. Good software developers will always expand what they're capable of to the point where they reach the limits of the human brain. That's what we call "complexity".
AccountKiller
I think OO has major flaws that people gloss over. For example, OO doesn't map worth shit to any kind of database. I'm also getting the feeling it doesn't quite map well into the massively parallel future we seem to be headed.
Prototyping? A wise old programmer once said to me "If you can't write it down, you can't pull it off". That applies to the code, the database schema and most important the UI.
Naw. You gotta start somewhere. Design patterns are kind of like the programming equivalent of the Rule of Thirds in photography. You should adhere to it until you are good enough know when and were it doesn't apply.
Posting as "Anonymous Coward" to avoid unpleasant repercussions, although I don't think I'm at all cowardly and I really think the inference is offensive and unwarranted. Regardless ...
I am very pleased that my digital clock, which syncs by radio with NIST time broadcasts, does not crash or exhibit buffer overflow or other "bugs". I'm glad my TV cable box doesn't go on the fritz, not even at the most possibly annoying time (only the delivery service goes on the fritz and at the most annoying times). No one seems to have been able to hack into my fax machine, ever, and I'm so grateful. The little computer that controls "Cruise Control" in my auto has never put either the gas or brake pedals to the floor at the same time (or even independently), and I bet the insurance companies are appreciative of that.
These devices, and innumerable others, just work as expected and refuse to work in unexpected ways. Some are very cheap, others very expensive, but being it that they all have that performance expectation nailed down and trustworthy I'm left wondering how all that testing and debugging (that had to occur before a shipment date) could ever result in inexpensive products that do not misbehave. Perhaps the testing argument as reason for bad design, because the product has to ship someday, is a little overstated. Perhaps the reality is that with misbehaving products insufficient testing is performed, or how it's properly done isn't understood.
It might help if a new product is not announced before it exists in best possible form. I'm going to say this just once. I don't want all these excuses why it's ok that we have to wait for Service Pac X updates before the consumer gets what was paid for, finally, only to find product support then immediately discontinued. I want a product that has a warranty in case it actually breaks, not a warranty that expires as soon as the last update is released to make it work when the product was not physically ever broken to begin with. So shut up with all the excuses and rationalizations for bad software and just write good code with security in mind.
But wouldn't you say the level at which the complexity takes place has also changed? It hasn't shifted to the right or left, but really shifted *up* to higher levels. Yes all the examples you gave are complex, but to be honest none of them solve any usefully problem. They were complex because they systems they were developed on weren't powerful enough to take on that level of complexity for you.
I guess you can make a paralell to farming and industrial revolution. Farming was and still is complex. Back in the day most of humanity was busy doing it. They were all so busy farming they didn't have time to "thing about stuff". It wasn't until farming became a skill that only a small number of people needed to learn that we really started doing cool industrial stuff. Once the chore of collecting food was gone, we created machines and took on new more interesting types of complexity. Then we came up with computers to remove a lot of that complexity and brought on an even different level and type of complexity. Now we have powerful computers who can "solve" that complexity so we are free to invent even new complexity.
Hopefully that analogy makes sense. Basically we "solved" the complexity in your example so we could be free to solve more useful types of complexity.
You forgot to add "whoosh".
I know that doing all the above takes time, often as much as writing the s/ware in the first place, but overall it saves time since the users of software make less mistakes and are more effective.
Poor documentation is, unfortunately, frequent in FLOSS s/ware.
The difference is that most hardware engineers are a pragmatic lot and will work around the bugs as they need to to build a shipping product. The hardware rarely interacts directly with an uncontrolled environment (ie a user) and this makes work-arounds a realistic strategy.
There are even hacks in gcc to work around CPU bugs in various micros.
Engineering is the art of compromise.
I think what a lot of us are forgetting here is the importance of the overall structure of pieces of software. The overall design principles in a piece of software are set very early in its life. The decisions made early on about the general structure of the software echo throughout the life of the code. It may be debugged, it may even be rewritten, but if the early decisions about the general design of a program were poor, then it will have consequences, no matter how much debugging or polishing that goes on.
As for examples: Windows...Win95 was made with little thought of network security or the internet, because the original designers didn't consider the internet important...before 1994, for the home computer, the web didn't really exist. Internet/web functionality was later bolted on to windows, but the insecure foundation echoed through many different iterations of Windows. For windows, network security was largely a kluge.
Contrast this with Unix. Unix was used to run mainframe computers, especially at univerities. Unix was from early on a multi-user system that existed in a networked environment. Out of necessity, it was built to be secure and stable. These mainframe computers had to be able to prevent hacker students from running amok with their acounts. Now, with internet being everywhere, Unix is amongst the most secure systems for running networked computers. I would argue that a main reason for this is that Unix systems, from early on were designed with security in mind.
NeXT computers (which later became OS X) were designed early on with an excellent hardware abstraction layer. Basically, NeXT was designed so that the software could operate with limited knowledge of hardware details. The hardware abstraction layer translates requests from the software into instructions for the hardware. And because the software has limited knowledge of the hardware, the hardware may then be changed with little disruption to the software.
I realize that most OS's do this to some extent, but NeXT's version was so good that Apple was able to port OS X from PowerPC CPU's to Intel chips with no significant disruption, something that would be well nigh impossible with a poorly structured OS such as Windows. I argue that the reason for this portability was that NeXT/OS X was designed elegently from the beginning to be independent of hardware.
I believe that NeXT's structural elegance is the real reason that Apple is able to put out a secure and functional operating system with a tenth the staff of Microsoft. I don't buy for a second the argument that Apple has it easy because it doesn't have to deal with as much diverse hardware as Windows. Apple doesn't need as many programmers because the structure of the operating system is elegant and clear. Windows has an inelegant structure that originates from its beginnings as a hacked together system. Microsoft needs a massive staff because the Windows codebase is an ugly beast that can barely be managed (Vista still has the Registry!!!). This is the real reason why Microsoft can't seem to get it right. This is the real reason why it took so long for Vista, and why Vista was so buggy. It isn't about perfection. It's about elegance.
This and no other is the root from which a tyrant springs; when first he appears as a protector - Plato (423 to 327 BC)
http://www.patentstorm.us/patents/4549302.html
When I started out in the early 80's it was almost possible to know it all. The systems were simply not that complex compared to what we have today. Todays system do more and part of the price is greater complexity, some of the complexity is the price for the way things have been done.
Becuase systems are now more complex that noone really understands the system we have system being changed in part by people who dont understand the whole (the system is very complex) and much worshipping at the shrine of ytilbitapmoc.
Simply evaluating the available tools is impossible for any one person, information overload.
There is also a lot of hype in software development about tools & methodogolies.
Want to make sure there are no bugs?
Make clear interfaces between each code module and test every code path and every branch in the code with a unit test that is part of the code module.
Make sure that every error return is handled and that you can sanely handle garbage passed in as values. Any function that takes a pointer should be able to handle a null without choking.
Another area that people fail in is passing up error returns if your level of code can't handle the error. Your program needs to properly handle or shut down if you get a error from a system call or any of your own functions. If you tried to allocate more memory and it failed you have to property handle that case everywhere.
But marketing experts, and Alexander Graham Bell, will tell you that being first to market often gives you a competitive advantage over your competitor. Most of the existing web services and sites we know and love are the largest in their category largely because they were first, or at least very early, to fill their given niche. It's a matter of weighing trade-offs.
This can be found in biological evolution also: being first in a niche often gives you a leg up, even if it means more initial mutations or quirks.
Commodity services tend to flow overseas where labor is cheaper. The US's comparative advantage is staying ahead of the curve, and this means rushing to be first and taking risks. Our economy depends on economic gambling, for good or bad.
Table-ized A.I.
No offense, but youve been there 5 months. Everyone loves the company the first company they work for after 5 months. You have been probably busting your ass, working 10 hour days. As an example, if you are the current lead developer, try taking some of that paid time off. Take a week off, and see if they a) let you or b) don't just call you every single day. The reason companies give you foosball and catered lunches is at either the expense of your time or money. Nothing is free. It took me quite a few, what I thought were, coushy jobs to realize that. In a year or two you will be burned out, demand more money and they will hire some intern to do exactly what you did to your former co workers.
Ive seen it happen so many times I dont know why they don't teach you that in school!
also you should probably start reviewing your own resumes if you want good people (like craigslist). hr people dont know dick about computers.
As a potential lottery winner, I totally support tax cuts for the wealthy
is having a way to handle error systematically and appreciate customer reports about errors.
Sometimes when errors are reported, they are not fixed until 4 program versions later.
I love the way Alex Wolfe blames shoddy programming on the PC industry, which apparently replaced the waterfall development model with "cramming in as many features as possible before the shipping cut-off date, and then fixing the problems in beta". He then goes on to reference two books, from 1971 and 1975 respectively, which provide wisdom regarding this problem.
They're excellent books - but I wasn't aware that the PC industry was around in 1971. Could it be.. that bad programming practices have always been with us? That the PC isn't to blame?
Next up - Design! Woot, this bit is fun. So we crank up Rose or whatever and get to work. But when do we stop? Well again, that's tough. Because I don't know about you but I can design forever, getting better and better, more and more modular, more and more generic, until the whole thing has flipped itself inside out. So we stop when it's "good enough" - according to who?
Very true!
According to ... whoever makes the decision. Somebody has to make the decision, and stand by it. That somebody should be someone who knows:
(a) what they're talking about, and
(b) is willing and able to take the responsibility for deciding when "good enough" is "good enough."
And there's the rub: when is good enough good enough??
In my experience, this is not a technical question -- there's usually no final answer, no ultimate and complete answer. (Not in a project more complex than "Hello World", anyway.)
"Good enough" is more of an administrative question (how much "good enough" can we afford? ... or, alternately, how much "not good enough" can we not afford?)
Or maybe (if we're lucky) it's an artistic question (this "good enough" is "beautiful enough").
-kgj
need to wisen up. There are no methodologies that work best under all conditions, AND there is nothing more wasteful and demoralizing than implementing formality where none is needed.
Development culture that is. If you do not plan your development, document your system and expand the system incrementally, all with discipline to boot, then you are part of the problem. And Im sure we could all think of more to add to the above. The point is that we can talk about the Waterfall Model, the Spiral Model etc... but the real problem here is the "Cowboy Model". You do not need to staff only "genius" programmers to get a good result. What you need is the discipline to plan accordingly and then force the programmers to adhere to the standard. And if a programmer finds an issue while implementing said system, then the problem is dealt with intelligently.
I work in the embedded systems arena. You would think that aiming to produce a system with uptime in years would provide the motivation necessary to do the above. Well it doesnt. I have just finished reviving a product where millions were lost due to absolutely horrible development practices. This particular system has multiple micro's that need to communicate. I asked for documentation... and people started to inform me verbally and draw diagrams on my whiteboard. No written documentation at all. In fact in the past 9 months I have not seen a shred of written documentation. Everything from incorrect use of watchdog timers to busy waiting all over. I could go on all night.
But the reality is (at least with the place I am currently at) this is what you get when you have some guy who has 7 yrs of "experience" and bestows upon himself the title of "Senior Software Engineer". Then goes to an interview and nobody asks him about asymptotic analysis. Or about computer architecture. Or about databases. Or about network protocols. Or about anything else relevant to designing software to run on a computer in today's world. I have helped conduct interviews for some of the Mechanical and Electrical engineers (since we all work closely together) and I know for a fact that they get grilled after the initial formalities are over with. And you know what? 9 times out of 10, if there is a problem with one of our systems, its the software thats screwed up. I don't believe that is a coincidence.
The simple fact is the development woes could have been alleviated to a large extent if the culture of Software Engineering was better. If the culture of Software Engineering (and I hesitate to call it that at this point in time) became more like that of other engineering fields then I think that things would improve.
I've worked at a place with one full time developer who used to hire one or two contractors. I say "used to" because after my predecessor and my time there, no contracting agency in the city will place staff there.
This was merely from a small company thinking because they all worked weekends and worked their ass off to make their business a "success", that we should too. Tip: Your business, your risks. Same goes for "I choose the risky option" ... "What the hell, it all went wrong, this is your fault!!".
3laws: No freebies, no backsies, GTFO.
Indeed. Look. C is nice. I love playing with pointers. It can produce some fast friggen code that is great for improving performance in critical areas of your system. But damn is it not up to the task of even basic GUI programming. You shouldn't *have* to worry about memory for most things (unless performance is critical). And if the language is going to mandate you worry about it, the damn thing should provide more tools then just a pointer/array thing. It should at least give you a way to figure out the size of the memory block you've allocated (rather then leaving it to you to re-invent). In fact, if it had just centered around pascal strings instead of friggen null terminated ones--that alone would have made it vastly more secure and suited to hostile environments. And yes, sure I can roll my own damn pascal string library, but why didn't the standard library do it for me?
And why the hell is the language so damn stupid that I need to create function declarations so the brain-dead linker can find my stuff? Why can't it just figure that out like every other language on the planet?
Every time I program in C these days, I just get pissed off. I thought I loved you C, but dammit, I've been spoiled by better lovers and I think I've moved on.
Comment removed based on user account deletion
In an article about programming errors, it would be prudent to check the facts to prevent misinformation.
Sans released 25 not 15 as was stated.
One wonders if any of these Microsoft haters read 1980 and see the irony. Two minutes hate indeed.
In some ways, software is getting worse. There are some new problems that have appeared in the last decade. Here are some of them:
These are new problems, on top of the classic ones.
The languages from Niklaus Wirth (Pascal, Modula, Oberon, Component Pascal) adhere to Edsger Dijkstra's Weakest Precondition.
The C/C++ languages do not.
When you write a function you need to specify the weakest precondition on the inputs that will guarantee the post condition of the outputs. These preconditions need to be specified as guards that test the input for satisfaction with the preconditions.
Component Pascal ALWAYS checks array bounds (you can't turn it off) so you never can write to or read from unallocated memory.
It also has garbage collection that completely avoids dangling pointers.
Choose a good language and follow Dijkstra's principles and you code will be much better.
"CWE-20: Improper Input Validation
It's the number one killer of healthy software, so you're just asking for trouble if you don't ensure that your input conforms to expectations...MORE >>
CWE-116: Improper Encoding or Escaping of Output
Computers have a strange habit of doing what you say, not what you mean. Insufficient output encoding is the often-ignored sibling to poor input validation, but it is at the root of most injection-based attacks, which are all the rage these days...MORE >>
CWE-89: Failure to Preserve SQL Query Structure (aka 'SQL Injection')
If attackers can influence the SQL that you use to communicate with your database, then they can...MORE >>
CWE-79: Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
Cross-site scripting (XSS) is one of the most prevalent, obstinate, and dangerous vulnerabilities in web applications...If you're not careful, attackers can...MORE >>
CWE-78: Failure to Preserve OS Command Structure (aka 'OS Command Injection')
When you invoke another program on the operating system, but you allow untrusted inputs to be fed into the command string that you generate for executing the program, then you are inviting attackers...MORE >>
CWE-352: Cross-Site Request Forgery (CSRF)
With cross-site request forgery, the attacker gets the victim to activate a request that goes to your site. Thanks to scripting and the way the web works in general, the victim...MORE >>
CWE-209: Error Message Information Leak
If you use chatty error messages, then they could disclose secrets to any attacker who dares to misuse your software. The secrets could cover a wide range of valuable data...MORE"
EVERY single one of these are simply cases of the first one. All are nothing more than not validating the input.
This thing reads like something written by the Department of Redunancy's Redundancy Department Subdivision of Redundancy....
Apparently the author of TFA is immune to irony, stating that his favorite language is C.
Just ask yourself... do you really want to go back to using only the software of old? Because if that's really what you want, you can you know. So I don't even see the supposed problem. And then look at what he actually says... none of it has any direct bearing on the quality of software today. Not catching errors? Well, I've got news for you: if something goes terribly wrong there usually is no way to fix it. At least an uncaught error gets you a stack trace. OO being underused? Well, I don't know where he works, but OO is pretty standard nowadays. And so on. It's also kind of cute how he goes on about the errors those young wippensnappers make that he never made when he was their age, working the waterfal model in there as if it were a good thing, and complaining no one read the books that a) everyone pretty much read and b) everyone pretty much agrees don't make you a brilliant programmer. How about you get off our lawn Alex Wolfe?
'; DELETE FROM *; Scary
S I'm glad i read it is raised my paranoia about my web apps and cgi. But these are very different from the errors in applications, and are security problems, not bugs per se.
Anyone got good links for the best wrappers or subroutines to check SQL inputs, etc. They belong in this thread, but i didn't see any. If you rembemer to write your code with checked inputs first time, your save yourself a lot of trouble.
Just substituting "<" by "<" in user's input has kept me protected from cross site scripting and other html attacks since years.
I did not find a need to check for anything else like ">" or even interpret the whole string for any occurences of html meta tags.
Is this so simple? Why doesn't everyone do it?
Intersting: I had to write the subject like "s/</&lt;/g" to get it to appear correctly as "s/</</g" in the slashdot preview.
Atari rules... ermm... ruled.
and doing a reply on this changes the reply subject ...
Atari rules... ermm... ruled.
and another reply... and even more of the subject is missing. This is quite fun...
Maybe this "feature" in slashcode needs some correction.
Atari rules... ermm... ruled.
I work in game programming, and I've had similar experiences with interviewing people (to expand the team rather than to replace people who left). It's not that no-one wants to join the company: we had plenty of applications. However, 80% or so failed the initial screening test, which asked them to write code to solve a simple problem. No time pressure, access to all the resources they could possibly need, and people couldn't solve a problem they should have encountered in the second year of the undergraduate course which their CV said they passed with a 2.1.
The problem is not in the development model, not in the development methodology, not in the management, not in the culture. The problem is in the tools.
In mathematics, a function is described by its inputs and outputs. Inputs have specific sets or ranges of values and produce a specific set of outputs. A math function can not be used with a number that is not contained in the input set.
In programming languages, a function is described by inputs and outputs. Inputs have generic sets of values (integers of various bit sizes) and produce generic sets of values (again, integers of various bit sizes). A programming language function can be called with a number that is not contained in the input set.
And that's the fundamental problem in software; until that is fixed, there would be no progress.
In a few words: programming is not math.
I'm only 28 so not part of the old timers really yet. Its not just about project management practices or anything. Yes its partly the ease of which lower end programmers can write and distribute programs but even when looking at larger companies(I've worked in many fortune 100 companies) the problem is that most developers do not think about optimization at all anymore. Its due to the fact hardware is cheaper then software and if the software takes too much up just buy a bigger server! Basically the whole thing is about greed and money as normal in anything you look at. If they can get away with cheaper solutions and make the same money then why bother with anything else.
Software is an artform same as design this is not a grunt work field...if you don't want to constantly learn don't try this.
Computer screens were not practical until you could store the ascii character bit pattern in affordable read-only memory - thats about 2240 bits of memory. A bit of memory cost over a dollar well into the 1960s. Intels second hit product circa 1970 was the half kilobit ROM debuting at about $100 and rapidly falling there after. That meant computer terminal prices feel to a $1000 by 1974.
What ever happened to tools like lint? Why are there no more tools to provide programmers feed back about the software they write?
Does anyone else find it ironic that when I visited this page there was an ad for MS Visual Studio under the article? AG
Non bene pro toto libertas venditur auro
not Oracle!
You better watch out, there may be dogs about . .
Don't forget HTML-encoding the data in form elements... do you have a textarea in your form? What happens if they type </textarea> in the box, and then they come back to edit it later? If your code doesn't HTML-encode the contents when it creates the page, all the HTML following the </textarea> will be injected into the page. Same goes for input elements, but the attack would consist of "> (or '> ) for those.
Alexander Peter Kristopeit bought his basement from his mommy for one dollar.
Food is a bad example, because there is a large segment of society that pays extra for "better than just good enough". They are called foodies, or the organic crowd, or the beer and wine snobs, etc. etc. Budweiser may be good enough for Hardhat Bob, but based on the large choice of "craft beers" available, it seems "good enough" isn't the necessarily the norm. Plus, for something I put into my body, it better be better than good enough. With computers (thanks Microsoft), people have been conditioned to think "good enough" is the gold standard.
PC developers (read: Microsoft)
Strange, I always thought that Asus, Sony, HP etcetera were PC developers... MS is just a software developer, right?
He argues that youthful programmers don't know about error-catching
Funny, because that's almost the first thing I learnt after learning how to program at all.
I am not devoid of humor.
And before you put anything into your computer you'll pay extra to be sure it's better than Good Enough.
I think my analogy stands.
But if you need another example, check out the web hosting industry. Or the big ISP's. Or the Telcos.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine