Earlier quoted context omitted.
IBM is best at writing iron clad contracts that mean precisely that -- no matter the outcome, they get paid.
IBM: You can buy better, but you can't pay more.
Incredible
Billing
Machine
IBM's reputation at risk in wake of census bungle
41–50 of 91 posts
Re: IBM's reputation at risk in wake of census bungle
#42Earlier quoted context omitted.
IBM is best at writing iron clad contracts that mean precisely that -- no matter the outcome, they get paid.
Until eventually their past customers get smart and stop working with them. Because of lowest bid contracts, the gov't will be an exception unfortunately.
> Because of lowest bid contracts, the gov't will be an exception unfortunately.
The problem is not lowest bid (which few government contracts are any more, AFAIK), but the fact that government contracting is its own domain of expertise (actually, often a separate domain for each state plus the federal government, and even many local governments) separate from the kind of work actually being contracted for, and there are in any field a very small number of players (compared to the field as a whole) that have developed expertise in the "winning government contracts" domain (and, in IT, IBM is one of them, at essentially every level of government.)
Re: IBM's reputation at risk in wake of census bungle
#43No one ever got fired for buying IBM!
Too soon?
Re: IBM's reputation at risk in wake of census bungle
#44Where is Watson when you really need it. I would be much more impressed by "Watson successfully saves an IT project screwed up by IBM management" than an article about how Watson diagnoses cancer.
Re: IBM's reputation at risk in wake of census bungle
#45A few years ago I worked on a project where my company was contracted to build a small piece of a much larger system by IBM. IBM was managing many different contractors. We needed a way to "securely" show a picture, aka not using the pre-installed image showing app. So IBM spent tens of thousands of dollars to build a new Android app that displayed a picture passed to it via an intent. I told our product guy that I c…
Presumably that kind of process rigor is necessary in massive, high-scope projects, and the fallout we see is chiefly from the inability to apply a more lightweight process for tiny projects?
I'd buy that logic if it produced low defect rates and high uptime, but it doesn't. When we used SilverPop earlier this year it was down about 5% of the time and wrong 5% of the time, and even the basic way the interfaces we had to integrate with worked was a mess.
I don't think their process is heavy because it's rigorous, I think it's heavy because it's a reflection of their corporate structure (which is large).
Re: IBM's reputation at risk in wake of census bungle
#46A few years ago I worked on a project where my company was contracted to build a small piece of a much larger system by IBM. IBM was managing many different contractors. We needed a way to "securely" show a picture, aka not using the pre-installed image showing app. So IBM spent tens of thousands of dollars to build a new Android app that displayed a picture passed to it via an intent. I told our product guy that I c…
Presumably that kind of process rigor is necessary in massive, high-scope projects, and the fallout we see is chiefly from the inability to apply a more lightweight process for tiny projects?
I'd call it process theater rather than process rigor.
Re: IBM's reputation at risk in wake of census bungle
#47IBM's reputation is utterly nonsensical. I've worked for a company bought by IBM and for companies that used IBM's products/services and they've never been anything other than mediocre, sometimes outright bad, with costs that are astronomical. My recommendation is that if you ever think about using an IBM product, hire a developer instead. You'll pay less money for a developer than you would pay for an IBM product, a…
IBM is older, larger, and has better insurance.
Re: IBM's reputation at risk in wake of census bungle
#48Not long ago there was a thread about IBM PhotoStore system from 67, a Terabit of storage on photographic film: http://www.computer-history.info/Page4.dir/pages/Photostore....
I miss this IBM.
Re: IBM's reputation at risk in wake of census bungle
#49IBM's reputation is utterly nonsensical. I've worked for a company bought by IBM and for companies that used IBM's products/services and they've never been anything other than mediocre, sometimes outright bad, with costs that are astronomical. My recommendation is that if you ever think about using an IBM product, hire a developer instead. You'll pay less money for a developer than you would pay for an IBM product, a…
I've seen it firsthand several times, if you want a mess, call IBM.
The only "problem" with developers is they usually don't throw golf days for their best customers :)
Re: IBM's reputation at risk in wake of census bungle
#50Earlier quoted context omitted.
> that barely seems like enough to pay for the hardware to deal with 10+ million visitors in one evening. Really? The specs: The online census form was a pretty simple client side app. I'm going to say, I could whack something together in much less than 200k of JS. For each household the site needs to: 1. Serve the client side app. The app had no images beside the ABS header. I'll be generous and say 200k of static a…
Was it a single form with no support for save & come back later to finish?
Even if it supported saving and coming back later, that barely complicates things. The form itself would need the ability to redisplay with fields pre-populated, which you'd want anyway if you've got any server-side validation or to handle submit errors with an option to retry.
For the database, you'd want to use caching. When the form is submitted you write the data locally and queue it for replication to a central server. To redisplay you'd try to read it locally and if you don't find it you'd read from the central server. You'd probably want to use the household's code for sharding so that you're going to the same local database each time.
I can't imagine it'd be necessary to spread the load out geographically. I'd have a single datacenter / cloud equivalent set up with load-balanced machines for the front end and the database tier, a full fail-over backup in case of critical failure of the main datacenter, and a separate database server for the master which the others replicate to and clone from.
This is a six-figure project, for sure, except maybe for time spent dealing with governmental red-tape.