"I'm not sure the developer is to blame. It's better to blame the person who defined the project. They specified fast response time as a key requirement of the project. They didn't say the project had to be secure, Birman said"

If one of my coders gave me the "you didn't say it had to be secure" line, they'd be gone in a flash. They're developing an eTrading site FFS! Of course it has to be secure! What tosh.

Its no wonder the anonymous coward won't put his name to his posts.

Look, if the spec says one thing, the coder follows the spec.

If the coder doesn't grok the spec, he asks the architect a question.

Sure a senior developer will grok the problem and would raise the red flag during the development process.

But how many senior developers are there these days? Everyone is hiring / outsourcing to the lowest cost developer. You get what you pay for.

If it were me, I'd have flogged the architect and the person who wrote the functional requirements.

This is why when companies need things done right the first time, they should plan on paying more for the blokes who can get the job done right the first time.

Sure they cost more per hour worked, but it will most likely be less hours and less headaches in the long run.

In many high-profile disasters (like airplane crashes), there are several things that must fail for the disaster to happen. If any one of failures not occured, the disaster would have been prevented. That's what I see happening here. In order for an insecure system to ship, every person who recognized it wasn't secure had to have "drunk the Kool-Aid" and not stand up and say this was a fatal flaw. So the developer should not be let off the hook.

Gumby, not Mr.Coward, is correct. Coders follow specs. They have to, because each coder is rarely given a view of the entire project. They work on their module, and if it meets the spec that's it. I've been reprimanded several times for questioning poor specs rather than just following them. Turns out I was right, but as I wasn't the person in charge I was still reprimanded (the products were flops, BTW, and I don't include them on my CV. Ever.)

It's up to the people who have the overview - the architects and senior developers - to make sure the spec given to coders meets the real requirements. So definitely, hang the architect out to dry.

Although what probably happened is that the customer didn't bother with a qualified systems architect. They took Joe from accounting who has a computer at home and is therefore an expert, had him draw up the spec, which was then forwarded to coders directly.

A 'consultant' gets up on his hind legs and tells a conference crowd an alarming/amusing story about a cock-up between designers and developers. It's all very relevant and wonderfully illustrative. Oh, and because of "client confidentiality", the consultant doesn't have to identify the foolish virgin of a company.

Now, I'm going to be shocked and horrified if that same consultancy doesn't have services to sell that would 'prevent' exactly this scenario from happening again.

Skeptical? Moi?

@ Anonymous Coward

"If one of my coders gave me the "you didn't say it had to be secure" line, they'd be gone in a flash. They're developing an eTrading site FFS! Of course it has to be secure! What tosh."

I think you missed the point,. Given infinite time, YES the dev should say something and try to do it right. Given a spec and limited time you do what you're told (maybe you still raise the issue but if it really is a tight time line you'll probably be ignored).

are all pretty much the same. If everything goes great, then the devs want all the credit "this couldn't have happened without me", "a spec isn't shit without coding", ect... However, when something doesn't work right the devs want to blame everyone else. I, for one, will be extremely excited when code developers are viewed as the mechanics they are and stop trying to be glory hogs. Send it all to India or China and be done with it.

You've obviously never developed anything beyond a Hello World program.

They whole point of the article was that (due to time constraints - usual excuse) the developers (code-monkeys) only had time to follow their given spec. The developers fullfilled the given spec. The problem was that the spec was crap in the first place. These developers (and I'm using the term loosely) were obviously the kind of non-questioning, dumb, code-mechanics that you appear to espouse! Great Job!

You pay peanuts, you'll get monkeys!

In this example the problems were (as I see them) a useless spec; an Architect and Management team either too ignorant or just not bothered to perform any due dilligence and analyse the spec and fix it; And code-monkey developers that were just doing as they were told, instead of standing up and challenging things that don't work - probably because none of them had ever worked on an authentication/Authorization system and thus didn't have a clue of what is right/wrong in such a situation.

@yeah, right.

Developers may have to work on their own Module; however, If I'm slated to work on an Authentication/Authorization module for an application (and I have and it is certainly non-trivial), I had better be qualified, or lead by a team-lead who is qualified!

ANY developer who blindly follows specs is doomed. Unfourtunately, the "Outsource it to India" model does exactly that.

If the business doesn't take the time/effort/money to:

a) Hire the right people;

b) Manage them right - that means empowering the various teams and making them communicate;

c) Allocating the time and paying them according to their knowledge;

then they deserve all the failures that they get - and more.

Do not use a freelancer on any project that requires security. At the end of the day, they go, they have other things to do. And, more to the point, they are quickly ushered out of the door to stop the work hours going up.

You get what you pay for, and if you want to play games with revolving doors and freelancers, your product will suffer. If you treat people like autonomous replaceable robotic parts, then you will get robotic work. (eg "Well yeah I thought it should have been secure too, but you didnt ask")

Outsourcing is a risky business, and apparently in this case no-one at the bank had the know how or inclination to check their work, and once the invoice is paid, its clear your mind, and onto the next job for everybody.

Blame the project managers or whatever those people are called who outline the specs and prioritise the time.

Hey, do you ever find that project managers haven't got the foggiest idea about any of the technology involved? Most of them are barely educated (by that I mean, maybe they have a degree in sociology or something) and have no real passion or aptitude or interest in their specific job, and are as generic a human being as you can get. And often, once the code has left the developers, then the chances of it actually being looked at (aside from a simple [click] "does it work?") are basically zero.

When I lived in the states, my Fleet Boston (now Bank of America) online banking account used my ATM card number as the user ID and my PIN as the password. When I complained a few times to their support desk they told me to stop being so silly because it was all SSL encrypted, therefore completely impervious to any form of attack!

Balls. This is what happens when you de-skill people at the bottom end of the chain. In this case developers, but it applies equally to nurses in the NHS and so on.

The best defence against this sort of bad practice in software engineering is to have engineers who are able to question and whose experience and judgement is valued. Basically, what Yousef said.

I'm not an engineer by the way - I was but now I'm a consultant who is more than happy to walk around on my hind legs.

Jesus, it's really very simple - if you don't stick to the spec you're given your little bit of the project WON'T OPERATE WITH THE REST OF IT. Get it? If you decide "hey, this function should only accept encrypted data" but Bill working on code that relies on yours doesn't know you're throwing the spec out of the window the program ain't gonna work.

Yes the spec might be shit, and yes you might even pass your feelings up the line, but if the project manager/board don't want to hear it then that's their problem.

This is exactly the reason big projects fail so spectacularly so often - people go around with the "yes I know what I said but that's not what I meant" attitude and others take the "I know what he said but that's not what he meant" line. Then nobody knows wtf is happening anywhere else in the project. If everything was black and white it'd be a lot bloody easier and cheaper.

</rant>

I agree with you i bet the reason no developer raised any objections was because they are outsource workers in India. Having had direct experience of using offshore developers ( actually what you get is new "graduate" programmers with zero experience who disappear to another job ever three months) i find the local indian managers push for stuff to be finished as soon as possible and will ignore bugs, basic methodical design or any type of testing or QA as long as they can hand you the "completed" code as soon as possible. Good luck trying to get them to fix it once they hand it off, as they will flat out deny there are any problems, and even try to blame you !

Of course your managment will totally ignore anything you say about problems, as they all toe the line that offshore outsourcing is wonderful.

My advice is get out as soon and leave the management idiots to solve the problem, it is only fair cos they caused it.

No, you pay people according to the contract they signed. If they sign a contract to work then they should be giving 100% of their skills. The quickest way to find a new job for one of our developers is for them to say something along the lines of "I'm only being paid xx, so this is all I'm going to do." That is a terrible work ethic and this attitude seems to be growing.

Caveat : I am a developer.

And I have worked on rather big projects. And when you work on big projects, you have powerful people giving the green light on them. And these people generally do not like to hear that they "missed" something. Nor do they have any actual IT experience or even a clue. If you're lucky, they _do_ know what they want.

So what happens is they spend a few days in meetings - except they don't have the time so they let a subcommittee take care of drafting the details - then they waltz in and have every sycophant blabber about how complete the specs are.

So the project goes ahead. And it's urgent of course, and not enough days have been allotted to do it properly because nobody has the money to do things the right way.

So it's up to the coder to shoulder the difference, with his "experience". After all, they always hire "experts" for these jobs, right ? Except that, after 30 years of developing code, it's still up to a junior analyst to estimate how many days a given functionality will take to develop.

So the developer doesn't have the time to do the job, the time for testing is always ignored in favor of a rushed-out "beta" that goes into production almost before the "testers" have plonked their keyboards for a quarter of an hour and called in if they can't log on to the application.

And most of the time, if the developer calls into question any part of the specs, he'll get the "deal with it" look or worse, he'll be shouldered out of the project for "being a troublemaker".

Yeah, the developer really has a lot of power these days. I don't know what happened to the "diva" mentality, but I haven't seen much of that. I've seen a whole lot of nuthin' if it works, and even more whiplash if it doesn't. Yeah, that I see.

But diva ? Nope, got none of that around here.

For the sake of conversation let's go with the assumption that the original specs were crap (which the article doesn't mention btw) and that the big question is 'should the coders have done something about it or not'.

Now, if everything from the specs to the finished (and I use the term loosely) code is done in-house, the coders can and *should have* raised the point of general spec-crapiness. You do what you're asked to do, but it doesn't take a genius to figure out that if you're coding crap, you're bound to have to recode it at some point and in the meantime Bad Things can happen to your website and your company - especially where security's involved.

If however you use an outside firm (be they in India or the building down the road), the specs become part of a contract between two companies, and as such the coders will have absolutely no say in the matter, even if they wanted to. It's not even a question of good or bad developers - from the moment the contract is signed specifying which specs will be coded for what price and in what time, the only way it's going to change is if you can convince the account manager there's more money to be made (and for that to happen, he has to convince the client to fork up extra dough).

Oh, and @Ed, the obvious answer is never EVER pay until you're completely satisfied with the code...

The worst online security that I've seen is with Smile.

They use the account number, sorting code and 4-digit number (not your pin code) as the first level of login security.

The system then asks for "secure personal information", such as a memorable date, first school attended, last school attended, etc. This is COMPLETELY STUPID and breaks the first rule of network security.

I've told them this, and they made noises that there was no plan on changing it.

If you have ever had the 'fun' being on the end of an Indian call where they are @to be making a decision' you wait 20 minutes until all the 'Actors' are gathered then they contradict each other for about 45 minutes. Thereafter they ask you what you think.

I DONT blame the Architect or PM, I blame their bosses for making them work with this dross, if a plumber tyurned up to fix your bathroom with a wooden screwdriver is it his fault all costs have been cut, is it surprising that the jo you paid for is crap, and if you complain the plumber gets it.

Its now about time those near the top of the chain felt some heat, my Advice is to hold onto every cost cutting e-mail and your replies that the team your working with is as fineley tuned as sloppy dog turds, then when the 'Problem' Surfaces point out that you were given a wooden screwdriver and a short timeframe.

And no PM's never understand Technology, why should they.... They manage projects..Architects understand design.,...coders understand code... if one element of the chain is below par...its dead...

I know this from bitter experience and now refuse to work with the sandal brigade, has done me nothing but good :).