Dev.SN ♥ developers
Sections
Dev.SN
from the lowest-bidders-all-the-way-down dept.
skullz writes:
"I've watched the Affordable Care Act's federal and state website roll-outs with trepidation as one botched IT project crashes and burns after another. As more information is coming out about Minnesota's health insurance exchange, lo and behold, poor communication, lack of fundamentals, and bureaucracy seem to be contributing factors.
From NPR's How A Series Of Mistakes Hobbled Minnesota's Health Exchange we learn that the users were the first to actually test the website:
What Minnesotans did not know is they were testing the site. There wasn't time for consumer testing before the site went live. Michael Krigsman, a consultant who specializes in diagnosing and preventing IT project failures, says testing is key. 'That is so screwed up. You can quote me on that,' he says. 'This is one of these things that's so foundational. It's like why do we need to breathe the air?"
Having been on projects with shifting scope, compressed timeframes, and arbitrary milestones I feel for the developers who worked on these websites and am a little depressed that we are still doing this in 2014. When will the managers learn? Or at least listen?"
(Score: 2, Insightful) by prospectacle on Thursday March 13 2014, @10:11PM
To save time for all non-technical managers, government ministers, etc. Here is a quick guide so you can achieve your IT disaster in an efficient, timely manner, and without having to re-invent the wheel:
1 - Get an estimated timeframe at the start of the project, then promise to stick to that timeframe no matter what. This deadline must be enforced at all levels, with no excuses, because releasing on time matters more than anything.
2 - Testing can be done at any time, so save it till the end, preferably after the product is released, so more users can act as testers.
3 - Choose the contractor who bids the lowest, and pay them as soon as the product is released. This way you'll have money left over, and you'll be on good terms with the contractor. Any future changes or fixes that may be required after you test the product more thoroughly, can be handled by this same contractor, because they're familiar with the product, they're costs are reasonable, and you've got a good relationship with them.
This is basically all you need to know to guarantee your department will make headlines.
If a plan isn't flexible it isn't realistic
(Score: 3, Insightful) by mth on Thursday March 13 2014, @10:31PM
This seems to be what happened here. Instead of admitting it wasn't ready in time, it was deployed without testing. The result is that a large group of people wasted their time trying to use a broken system, instead of a small group of test users finding those same problems.
TFA says the project was managed by people with expertise in health policy, not IT. They might not have known about things such as automated load testing or unit testing. Too many managers (even some with IT expertise) focus only on system testing.
Taking the lowest bid blindly certainly increases the chance of the project failing, but picking a higher bidder is no guarantee for success either. You need to understand software development yourself and be able to test intermediate deliveries: if you trust the contractor to deliver a finished, working product in one delivery on the last day you're in trouble.
(Score: 4, Interesting) by Ethanol-fueled on Thursday March 13 2014, @11:02PM
Shameless reuse of a comment I posted on "the other site:"
There is no Alpha testing. There is no beta testing. Who used to be called "beta testers" are now called "early adopters." Phone don't work when you hold it a certain way? Car catching fire or has a tendency to accelerate during braking? Mandatory and proprietary software update break your entire production floor?
Yep, you paid the most money for that shiny new toy that's much more new than functional, and you paid for software that barely compiled (or, in the physical realm, something that didn't collapse under its own weight), and you paid the price, indeed -- well worth your dollars in memory leaks and ignored exceptions. I for one would be pissed to know that I paid a thousand bucks for a barely-functional piece of shit, when in a few months somebody else is going to pay two-hundred for the exact same thing and get it fully functional right out of the box.