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
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!
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.
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,
If people refused to use and pay for buggy applications, they would either get fixed or die off.
Combination - fun iPhone puzzling
of.
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").
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.
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. ;-)
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.
I think refusing to hire someone solely because of their age is naive. Is there some magical event at the age of 30 that bestows knowledge of linkers to the aging programmer? Give me a break. You are making bad assumptions. Your first bad assumption is that just because of your anecdotal experience dealing with one individual, that all schools no longer teach anything about linkers. Your second bad assumption is that even if that was true, no programmer would learn that information on their own, as if no one is generally interested in learning comp sci any more outside of the classroom.
Abaddon: An Xbox 360 Indie game
You must be under 30.
comments like yours are precisely why people my own age embraced sayings like "never trust anyone over the age of 30". you're right, though; a sweeping generalization is way better than admitting that Sturgeon's Law is the norm in every generation, and you ALWAYS have to work hard to separate the wheat from the chaff.
i am a loser geek, crazy with an evil streak, yes i do believe there is a violent thing inside of me.
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.
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.
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.
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."
Don't you think that part of your job as a more experience programmer is to share your knowledge with juniors/graduates?
Universities are mostly interested in who can pay,. I'm 24 and I've got a computer science degree - real comp sci with maths and algorithms, i wrote a compiler, studied language theory you name it. Now I'm doing a masters degree (at one of the top universities in Australia) and as part of it I've worked with guys who couldn't write software. I've also met a bunch of really talent and smart guys all in their early 20s.
But I've also worked with guys who have been around for years with no idea on how to write software either and churned out crap code without even a single unit test in sight. Point is - there are bad developers of all ages and you shouldn't discount an entire group because of one idiot who didn't know what a linker does.
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."
You are absolutely right. I don't care about age, height, skin color, gender, etc.. What I care about is flexibility and skill.
That said, from my own personal experience (which undoubtedly varies wildly from other people's experience), a candidate that learned how to program by writing Java code fails. When faced with a new programming task, the first thing they do is fire up Google.
Those people tend to be under the age of 30.
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
You know, once you GET to 30, you do immediately understand why you should never trust anyone over 30.
It's because we know how fulla shit people under 30 are. Don't worry, you'll agree before ya know it, champ.
1. I'm not a programmer
2. If you remember how you wrote that compiler, you know what a linker is
3. I discount an entire group that has very few good programmers in it to save myself quite a giant lot of time.
And you know what time is.
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.
Unless you're writing a compiler, how much does a person need about linkers besides that .c files get compiled into .o files and .o files get linked into an executable?
Many people only know what they have needed to know so far in their lives/careers, but it doesn't mean they're incapable of learning, nor does it mean that Compilers is a required course for a Masters' degree.
Being a computer scientist means you tell people how computers should work, not that you know how they actually work.
...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
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.
No bestowing is ever done, cause the age limit goes up by 1 every year :)
"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."
Bingo. You can really tell the modders in this thread are under 30...which makes sense when you think about it, since really they're the only ones who would be offended by my statement.
Yet another reason to not hire them. They're still too damn sensitive. There's no crying in computer programming!
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.
Heavens to Betsy, I've seen this happen so many times it's insane. There was even this one time when someone on my team was working on a problem, and the guy picked up a book. That's right, a fucking BOOK. I cringed, but that's just how some people were made.
After seeing that I wrote out my resignation on vellum, sealed it with wax, and left it for my boss. If that's the kind of shop they wanted to run, they could do it without me.
Not necessarily. I'm well over 30, and I agree with him. Programming is a talent that people have or they don't, and age doesn't seem to be a big factor either way. Skill (as opposed to talent) can be acquired with age, but I'd rather have a 22 year old with great talent and instinct than a 40 year old stick-in-the-mud who's been dragging down his teams for the last 18 years. I'd even more rather have a 40 year old with great talent and instinct, but you take what you can get.
Or to put it another way--just because the schools often seem to miss out on teaching certain useful skills, that doesn't mean that someone fresh out of school can't have acquired them by other means. For example, a kid might know what a linker is because she's been hacking her dad's Linux box since she was in grade school. (I have strong hopes that this will end up being a valid description of at least one of my nieces.) The 22 year old just might have more real-world practical experience hacking Debian than the 40 year old who spent years doing nothing but generating reports with RPG, Access and VB "programming".
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')
No, you have look over 30. Three words: Long-ass beard. Look at these guys. They must be some of the best programmers in the world.
Well, there's spam egg sausage and spam, that's not got much spam in it.
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 will never work for you. Age bigots are no better than race bigots or gender bigot. Those who assume that they can know exactly the qualities that they will find based on an arbitrary trait are not people that I like to work for. Besides, I am 31.
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.
A resignation carved in hand-chipped stone is more durable, leaves a lasting impression, and can be used as a handy paperweight or doorstop after the dust settles.
To fill in the between-the-lines reading: The folks I'm referring to start with Google (or a book) and stop right there. They search for a solution that already exists (which is good) but, if it doesn't exist, one of two things happen:
You have a good point in that a wheel shouldn't be invented twice. But if a 'wheel' doesn't exist then by all means invent it, don't try to shoehorn a square block of wood in there. My goal is to find those people who are able invent that wheel and, perhaps just as importantly, know when it needs to be invented. In my personal experience, the "Java mentality" doesn't seem to extend to that second bit.
It's nice to know that the daily wtf has expanded its negativity to new aspects of our profession.
Well, only someone under 30 would be offended by your statement, but most people would find it really damned stupid. Competence is not caused by age, and you would do well to hire the greenest programmer around if that person is willing and able to be taught, and has basic competence at the job. Hire based on where you think they'll go, not where they are right now.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
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.
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)
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
At GMU even Computer Engineering (a field closer to Electrical Engineering than Software Engineering or Computer Science) undergrads learn all about the linking process, strong symbols, weak symbols, all that good stuff. You just had a bad candidate.
This game will waste your life. Don't clicky!
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?
Fine. Find me a 25+ year old modem across which people ran zmodem. It's not at all surprising Hayes would patent it. They pretty much invented the modem.
Wait a minute. I HAVE a 25 year old modem... the one that started it all (for RS232 anyway)... a Hayes Smartmodem 300. I've used zmodem across it (don't recommend it; a rat dragging a floppy disk is faster.) And it doesn't f'ing hang up.
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
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 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.
The other thing is that, to be honest, the vast majority of computer programmers are not, and do not need to be, computer scientists.
It's important to know what dynamic libraries are, why you would use them, and how to invoke the linker for the language you're working on, if necessary. It's not necessarily true that you need to know exactly how the linker works, or even that it's called a linker.
This information can be useful, and you should certainly be able to find out the information(I double checked my recollection was right with a 30 second google search), but not knowing it doesn't make you a lousy programmer(maybe you're not a good fit for working on a compiler implementation though).
The nuts and bolts which older folks spent years having to know like the backs of their hands are all pretty well implemented these days. The linkers, compilers, etc pretty much just work, and knowing their insides is sort of specialized knowledge.
I work in health care, and I know more about the HL7 specification than probably 95% of the folks on slashdot, but that doesn't make me a better programmer, it just makes me a programmer who works in health care.
"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 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.
"Competence is not caused by age"
I never claimed it was. It's caused instead by experience, and experience and age are not mutually exclusive.
And why the bloody hell would I want to waste time and money teaching someone their job? I do not run a school, buddy. You have to pay to go to those, and there's a reason for that. It's expensive to pack knowledge into the heads of future programmers and engineers.
Though now that I'm thinking about it, I suppose if someone were to offer to pay me to give them a position for which they are in no way qualified, so that they can learn to be qualified, I'd probably say something along the lines of "yeah, ok."
"Not necessarily. I'm well over 30, and I agree with him."
Then you'd be a terrible hiring manager.
"I'd even more rather have a 40 year old with great talent and instinct, but you take what you can get."
These people are everywhere, and a lot of them are out of work right now. If you're not finding them, you're not looking hard enough.
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.
You have a good point in that a wheel shouldn't be invented twice. But if a 'wheel' doesn't exist then by all means invent it, don't try to shoehorn a square block of wood in there. My goal is to find those people who are able invent that wheel and, perhaps just as importantly, know when it needs to be invented. In my personal experience, the "Java mentality" doesn't seem to extend to that second bit.
Is this mentality exclusive to Java? Would .NET (as an example) not see similar problems?
Just wondering why you singled out Java specifically, rather than any number of buzzword-compliant languages.
I'm 26. I got a Master's Degree in CS without knowing about the specifics of linkers. In the past year I've had to learn about them due to the need to maintain a set of linker scripts for an embedded project.
Now, I'm not sure what linker programs the original post was talking about, but the one that I'm working with is "ld". From what I've seen, it's default options do a pretty good job of arranging the memory/sections of the final executable without any user intervention and when this isn't enough it provides a highly capable system that lets you feed it a customized script with the options you want. However, learning the cryptic markings that control the flow of the customized linker script was one of the harder GNU-based projects to understand because of poor documentation and once I really got going with the customized script platform it took about 5 minutes for me to discover that there's no way to feed any sort of variable into the linker file at buildtime, a feature that I'd have thought would be extremely nice to have.
But anyway, I think the real gripe of the original post was that few programmers truly understand how to setup and configure the tools that comprise their applications "build system", and that is for good reason. The customizations within a "build system" are crucial to "just work" and should be maintained by an expert who truly understands what changing small details will do so that all the rest of the developers on the project can get away with "just clicking the build button". I think Brooks called this role the "Architect", though its been a while since I've read Mythical Man Month. Anyway, expecting students who are fresh out of school to understand these details that they can get by without needing is kind of a joke. As much as you'd like to assess people based on knowledge of these minor details, the details aren't the big picture and an inexperienced programmer should only be expected to know "Big Picture" things (which I'd include Big-O Notion referenced in the summary as a part of).
Support the 30 Hour Work Week!!!
And why the bloody hell would I want to waste time and money teaching someone their job?
How nice for you that we have employers with clearer vision than you. If no one gives the new guys so much as a chance, where the hell do you expect your experienced guys to come from?
Your position is extremely short-sighted, and only works out for you because most people grasp the flaw in it. If they didn't, you'd be SOL.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
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.
Give them their 7th place trophy and they'll be fine.
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 . .
Oh yes the linker elves.
I have discovered a truly remarkable sig which this post is too small to contain.
Then you'd be a terrible hiring manager.
Why? Because I try to judge people by their skills and talent rather than their age? If that would make me a terrible hiring manager, I'd be proud to be one! I've worked with too many people, young and old, who were amazing at software development (and too many people, young and old, who were terrible at it) to think that age is really any sort of factor in this field. There is a skill-and-experience factor, but it generally tends to be dwarfed by differences in sheer talent.
If you think I should overlook a brilliant youngster and hire a plodding old fart just because he's old, then I think it's more likely you that would make a terrible hiring manager. That's almost as bad as the idiots who refuse to hire anyone over 30 because they think us old farts can't keep up with the changes in the field.
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.
"If you think I should overlook a brilliant youngster and hire a plodding old fart just because he's old"
I don't, and you need to take a logic class.
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