|
The obamacare website debacle is NOT the fault of the programmers. It is the fault of MANAGEMENT! Bringing in the "best and brightest" won't help unless they're qualified project managers. Bringing in the best and brightest will not work unless they follow proper SDLC practices. More importantly, bringing in the "best and brightest" won't help unless they start over (using the fore-mentioned SDLC practices).
Going with the cheapest bid is NOT what you want to do with a project of this scope. You want the contractor with the best pool of talent working on it, not a contractor that undercuts everyone else's bid under the assumption that they can gather a reasonable talent pool after they win the bidding war.
Until the government realizes this, they will continue to get piss poor software delivered late and way over budget, and then wonder what the f*ck happened.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
 you can bid for government contracts on renta coder?
Every day, thousands of innocent plants are killed by vegetarians.
Help end the violence EAT BACON
|
|
|
|
|
I wish our management had the insight to see this at our office. We are always in trouble, even when it's management / the testing department's fault 
|
|
|
|
|
We go through complete SDLC processes for point releases, as well as major revisions. Everybody associated with the project sits in on all the design meetings, including testers. We have three levels of test (dev, SIT, and UAT), and everybody has to sign off on each progression through the cycle. Even with all the processes in place, employee vacations, holidays, and small delays), we manage to release on time with maybe one or two obscure bugs after release to manufacturing.
We're currently in the SIT phase of the latest three-week sprint for a point release, and the next sprint is already mostly through the functional spec/test case development phase. By the time we go to UAT, we'll be writing code for the next sprint.
Yes, the work is hard, but we rarely have to revisit old code unless a new feature demands it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
That sounds very well organized 
We are lucky to get anything more than a verbal spec. Even the boss jokes about it when he actually scribbles something down on paper or the whiteboard.
There's no proper SDLC and it shows. We often have to redo stuff as the 'spec' changes and then get blamed for taking too long and it costs the company more development time.
We (developers) are trying hard to make management see this and change things...
|
|
|
|
|
I'm afraid this is the way things are done at far too many, perhaps most, places. And, of course, it is never the fault of management if the product is late and/or buggy. 
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Yup.
We try our best, but without a spec it's almost impossible to get all the business rules right...
|
|
|
|
|
I have found it really is hard to get the rules right when they don't tell you all the rules and make last minute changes to some of the rules.  
Just because the code works, it doesn't mean that it is good code.
|
|
|
|
|
Is this standard, or only because you are working for DoD (or maybe you are not anymore and I missed last episode) ?
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
I no longer work for a defense contractor, and I hope I never have to resort to it again.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Because not interesting or because of all the PITA restrictions and constraints of all sorts ?
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
The work is interesting, but yeah, it's a pain in the ass to get anything done, especially if you're on-site working on a government network. The crap you have to go through is nightmarish. If you feel the need to step outside the original statement of work (the requirements/functional specs), it requires that the government go through the bidding process all over again (at least that's what I've been told by a government contract manager). The red tape is mind-blowing, and that's probably why the current healthcare site sucks so badly.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I had an ex-colleague who changed employer and wrote parts of the software embedded into military helicopters as a new job : he could not change a line of the specifications, even if they seemed silly, and the implementation was quite complicated, since they sliced the software in tiny bits so that the developers could not understand which part they were programming for ! So the whole thing was completely bloated due to the lack of context and communication possibilities, quite an nightmare as well.
~RaGE();
I think words like 'destiny' are a way of trying to find order where none exists. - Christian Graus
Do not feed the troll ! - Common proverb
|
|
|
|
|
envy you 
We need a process to explain process so that they (team) can process the process.
Thanks,
Milind
|
|
|
|
|
Designing software that's fit for use is paramount. UK governments swept aside criticisms about their IT contracts in the 90s and noughties. The NATS air traffic control system was delivered on time but nobody ensured it was fit for purpose. Another £450m was thrown at it until it was. The NAO was brushed aside when the then, independent Customs, refused to use a new system that was so complicated to use that it was scrapped after only two transactions. The total cost of the system escapes me but it was something like £500m+. One pensions system was written off after £1.5bn was thrown at it but I don't know what the IT component was at it included hardware as well. As long as we pay our taxes, government will use it wisely. 
All of this is peanuts compared to what the US will do. Best of luck to you/him/her/them.
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
|
|
|
|
|
Sounds like a typical IT project to me.
Regards,
Rob Philpott.
|
|
|
|
|
With all the controversy around Obamacare you would have thought they would have at least spent some money to do it right. Now, it's just more ammo for those against Obamacare.
But don't worry. Now that everyone has "affordable health care" there will be plenty of money to spend on making it right.
There are only 10 types of people in the world, those who understand binary and those who don't.
|
|
|
|
|
The controversy was a major part of the problem. A lot more states than expected opted to have the feds run their exchange (most of the state run ones are in decent shape) instead of doing it themselves resulting in massive scope growth; while the lawfare in DC greatly delayed getting the requirements needed to build the bulk of the site defined.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, waging all things in the balance of reason?
Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful?
--Zachris Topelius
Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies.
-- Sarah Hoyt
|
|
|
|
|
I've personally seen a large government contract for a foreign country(not UK) go to the completely wrong bidder.
Much of the time it seems that there are political undercurrents at work involving the executives - this then leads to decisions which the poor project managers and then developers have to fix after being given impossible deadlines
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
That's the free market for you!
=========================================================
I'm an optoholic - my glass is always half full of vodka.
=========================================================
|
|
|
|
|
I have attempted to apply for some of the Fed Web site projects and all of the rates have always been abysmally low. Don't know about this one, however, but I am betting it was equally cheaply done as well.
|
|
|
|
|
..you're suggesting to look beyond the price-difference. That way it sounds like work, and that's not tolerated in those environments.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
We recently launched a 250 million dollar software package at my place of employment.
The thing is a total nightmare.
The problem is that I think people are wanting the computers to do too much.
Every time they add a new requirement the complexity goes up exponentially.
How do you code a website to handle thousands of pages of health care law, and more importantly, how can you ever hope to maintain it?
|
|
|
|
|
It would probably be working better had they gone with the cheapest bid. In reality, they went with dozens of companies who are best at bribing the government, several of which have a long history of disastrous projects. The latter is the most puzzling; when hiring someone, you typically pick someone who has a positive history of successful projects, not failures. Instead, they apparently did what my town did when repaving the main boulevard--gone with a buddy who paid the best bribes.
|
|
|
|
|
John Simmons / outlaw programmer wrote: they will continue to get piss poor software delivered late and way over budget, and then wonder what the f*ck happened.
I disagree that it's not the fault of programmers. I've seen many programmers drive a project into the ground because they're over-optimistic, terrible at planning, and don't communicate with management (or amongst themselves.)
And the sad thing is, this isn't just rare instances. I've seen this in every company I've worked for in 30 years, and I've been a participant of some of those failure as well.
Marc
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
