3 ms·

As much as I hate Oracle / IBM contracted software (my alma mater paid Oracle more than $600 millions to replace our university portal, and half of what they di

by yeukhon 12y ago

As much as I hate Oracle / IBM contracted software (my alma mater paid Oracle more than $600 millions to replace our university portal, and half of what they did was customize existing ecommerce system to fit our need), compare to this project, I feel much better about the new portal Oracle delivered to my alma mater. Look, I am okay with the contractor subcontracts to 34 other contractors. I will take that as hiring consultants from 34 other consulting agencies. But I can bet with my life they were all working in vacuum and in a full water fall model. No doubt we need to start with analysis, and propose a possible solution like database schema and migration, but one can still work with other parts of the project iteratively, e.g. front-end and some other micro-services. I also suspect contractors hire offshore which can further complicate the development process as one has to deal with language barrier (kind of a minor issue) and timezone difference. FYI I do work with offshore day-to-day and the one I work with are excellent. Like healtcare.gov, and the fictional (but based on real life stories) Phoenix Project, there was little to no human resource and IT capacity planning, and management oversight is completely broken with 35 contractors involved. I cannot underestimate the complexity involved in migrating old data, but I bet if we gather a bunch of database professors they can probably come up with a pretty good database migration plan and a new database schema design.

zaroth 12y ago
Just like healthcare.gov, the reality is you start with an absolutely trivial problem and turn it into a nightmare. CRUD is CRUD. The complexity is imposed by project managers and engineers that can't help themselves or simply don't know better. Seen it happen over and over, and often just the effort to stop the madness is more work than a fully working sane implementation. More than once I've seen stealth mode side-projects run on a single engineer's own time out-deliver and out-perform the fully funded project because the standard approach is to take absolutely trivial problems and heap on absurd layers of complexity which of course are full of bugs and utterly fail in the field. I wonder if taxpayers have ever tried to sue for damages, but I'm sure it's impossible.
- x0x0 12y ago
  governments -- essentially taxpayers -- often sue eg oregon is suing oracle over their failed implementation of the state obamacare site http://www.reuters.com/article/2014/08/22/us-usa-oregon-oracle-idUSKBN0GM21V20140822 http://www.reuters.com/article/2014/08/22/us-usa-oregon-orac...
- HillRat 12y ago
  Just like healthcare.gov, the reality is you start with an absolutely trivial problem and turn it into a nightmare. I wouldn't call hc.gov "trivial" -- it started with all the fun of a massive-scale website, added X12 EDI workflow, then finished up with real-time communications with high-security government systems never meant to be interoperated with and at least a few of which probably can't communicate over red-black networks. Then they started adding complexity to it. Admittedly, some of those added complexities caused major headache, such as the requirement to use ORCL IDM (which, if the hotwashes are correct, proved a constant Achilles' heel to the ops side -- who the hell put that requirement in the spec?), but the project started out high-risk. The problem with government projects by the way, isn't with "project managers and engineers;" it's with the dozens of agency stakeholders, half of whom are political appointees and the other half of whom are waging bureaucratic turf wars against everyone else. With high-profile projects like hc.gov, you also get politicians involved, so everyone starts freaking out about things like the fear that some illegal immigrant working in a Kansas poultry slaughterhouse could accidentally qualify for health insurance and end up as the lead story on FOX News. And, of course, even though the seventh floor (and, in this case, the Oval Office!) gives lip service about how critical it is that the tech works perfectly, you'll never see an appointee or an SES employee actually try to keep the ship upright. After that, add in large-scale government contractors that operate on a high-risk version of waterfall that requires every single piece to come together perfectly, on time, without errors, and for the internal specs and contracts to not shift at all -- well, it's a recipe for a massive clusterfuck, every single time. There's a reason Medicare is still running on mainframes and FERS has never gotten off paper -- the risks of failure are just overwhelming.
  - zaroth 12y ago
    You sound really knowledgeable about hc.gov back-end implementation, and I think everything you are saying has just proved my point. :-/

by yeukhon 12y ago

zaroth 12y ago

Just like healthcare.gov, the reality is you start with an absolutely trivial problem and turn it into a nightmare. CRUD is CRUD. The complexity is imposed by project managers and engineers that can't help themselves or simply don't know better. Seen it happen over and over, and often just the effort to stop the madness is more work than a fully working sane implementation. More than once I've seen stealth mode side-projects run on a single engineer's own time out-deliver and out-perform the fully funded project because the standard approach is to take absolutely trivial problems and heap on absurd layers of complexity which of course are full of bugs and utterly fail in the field. I wonder if taxpayers have ever tried to sue for damages, but I'm sure it's impossible.

x0x0 12y ago
governments -- essentially taxpayers -- often sue eg oregon is suing oracle over their failed implementation of the state obamacare site http://www.reuters.com/article/2014/08/22/us-usa-oregon-oracle-idUSKBN0GM21V20140822 http://www.reuters.com/article/2014/08/22/us-usa-oregon-orac...
HillRat 12y ago
Just like healthcare.gov, the reality is you start with an absolutely trivial problem and turn it into a nightmare. I wouldn't call hc.gov "trivial" -- it started with all the fun of a massive-scale website, added X12 EDI workflow, then finished up with real-time communications with high-security government systems never meant to be interoperated with and at least a few of which probably can't communicate over red-black networks. Then they started adding complexity to it. Admittedly, some of those added complexities caused major headache, such as the requirement to use ORCL IDM (which, if the hotwashes are correct, proved a constant Achilles' heel to the ops side -- who the hell put that requirement in the spec?), but the project started out high-risk. The problem with government projects by the way, isn't with "project managers and engineers;" it's with the dozens of agency stakeholders, half of whom are political appointees and the other half of whom are waging bureaucratic turf wars against everyone else. With high-profile projects like hc.gov, you also get politicians involved, so everyone starts freaking out about things like the fear that some illegal immigrant working in a Kansas poultry slaughterhouse could accidentally qualify for health insurance and end up as the lead story on FOX News. And, of course, even though the seventh floor (and, in this case, the Oval Office!) gives lip service about how critical it is that the tech works perfectly, you'll never see an appointee or an SES employee actually try to keep the ship upright. After that, add in large-scale government contractors that operate on a high-risk version of waterfall that requires every single piece to come together perfectly, on time, without errors, and for the internal specs and contracts to not shift at all -- well, it's a recipe for a massive clusterfuck, every single time. There's a reason Medicare is still running on mainframes and FERS has never gotten off paper -- the risks of failure are just overwhelming.
- zaroth 12y ago
  You sound really knowledgeable about hc.gov back-end implementation, and I think everything you are saying has just proved my point. :-/