31–40 of 58 posts
$293M.... I'm just consistently angry over how much this cost. There are so many moving pieces, and while I understand that, $293M for one piece. Half a billion for a website. Christ.
At least they didn't use windows/.net stack this time.
"I can tell that this system consists of a JBoss Application Server with data access components and RESTful web services developed using Java. Given my prior experience with JBoss and Java, although they are great for middleware development, they’re known to be a bit slow." I always had this non founded impression that something running on the JVM would be slow ... this author also. Anyone with data to back this impr…
It has nothing to do with "running on the JVM". The JVM is about as fast as you'll get any VM offering GC and running an IR like Java bytecode. It's only slow compared to compiled, native code (and even then nowhere near as relatively slow as it used to be), which no competing tech stack would be doing. It's much faster than Ruby, Python, etc. That said, my experiences with JBoss haven't left me enamoured of it, and…
$293M.... I'm just consistently angry over how much this cost. There are so many moving pieces, and while I understand that, $293M for one piece. Half a billion for a website. Christ.
Or is google just a website? Is yahoo.com just a website? Did you look at the infograph?
How much do you think it will take to talk to 5 agencies and 300 insurance providers that have 4500+ health plans, and get them to agree/adhere, understand their EXISTING system and build a site?
I'm not justifying the expense, but let's not trivialize the task at hand and call it just a website.
At least they didn't use windows/.net stack this time.
At least they didn't use windows/.net stack this time.
What makes you say that? Having built systems in this space with very large number of users using the .net platform, I wonder why you stated this. I am a supporter of open and non-MS software but I don't think we can blame it on the technology this time. In my experience so far a well engineered system, will perform regardless of the technology stack picked. Picking technology X or Y will not compensate for bad archi…
People appear to be missing the point that _the website_ is literally the smallest part of the project. While it's easy for people to crap on things like js-minifying, cache control, etc - the hard reality is the stuff that is the hardest is so hard that most people have never done anything even remotely close. Having worked on 10m+ loc codebases, life gets very hard. Dynamic languages tend to be unworkable. Module c…
People appear to be missing the point that _the website_ is literally the smallest part of the project. While it's easy for people to crap on things like js-minifying, cache control, etc - the hard reality is the stuff that is the hardest is so hard that most people have never done anything even remotely close. Having worked on 10m+ loc codebases, life gets very hard. Dynamic languages tend to be unworkable. Module c…
People appear to be missing the point that _the website_ is literally the smallest part of the project. While it's easy for people to crap on things like js-minifying, cache control, etc - the hard reality is the stuff that is the hardest is so hard that most people have never done anything even remotely close. Having worked on 10m+ loc codebases, life gets very hard. Dynamic languages tend to be unworkable. Module c…
Which EDI standar ... ohhh I see what you're getting at.
When you look at it like a single point aggregating all this information from all these separate insurance companies, it's amazing it works at all.
When you look at the website failing the way it is though, you can't help but ask 'did they even test this thing' even when you know better.
When you look at it from a user point of view, it's too bad it appears to not work at all.