4 ms·

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-mi

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 control, strong interfaces, and a lot of division of responsibility becomes the order of the day. And just figuring out how to build the thing becomes it's own team. For those who are just thinking "so, just slap together some JSON/web services and call it a day" - I invite you to research EDI and then report back here. Assuming you're still alive.

splawn 13y ago
If only there was a way to remove the hundreds of private insurance companies they have to interface with. I assume they each have their own flavor of EDI, greatly adding to the complexity of this thing. (I have had to write interop EDI stuff with some insurance companies a while back and iirc they were snowflakes)
daigoba66 13y ago
Given the complexity of the system, the most shocking thing to me is that how little time they had to actually build it. And from what's been made public there was virtually no time for testing (load testing was certainly absent). It should been "turned on" months before the public go-live to iron out all of these issues.
- spikels 13y ago
  That's one thing I never understood. The law was passed 3.5 years before they had to go live. Seems like they should have had plenty of time but it seems like almost all of the coding was done in the past year with little testing along the way.
mhurron 13y ago
> I invite you to research EDI and then report back here. Assuming you're still alive. 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.
AaronFriel 13y ago
Taking on EDI projects are the the most difficult jobs I've had as a dev or as an admin. Interacting with someone else's database schema is like trying to put yourself in its designer's head, and it's on a good day when you have a standard protocol or database format. I've mostly worked in the auto-industry as end-user support and currently employed by a wholesaler - the connection between parts manufacturers overseas and dealerships, body shops and others. The business is more complicated than that, but the auto industry is one with many standards, lots of vendor lock in, and proprietary formats and coding schemes for everything. With EDI you don't get to dictate standards, you can't demand JSON/web interfaces, you usually have to deal with flat text files (good luck) or schemaless XML (you're doomed) if that. Some vendors just provide XLS files to an FTP endpoint and call it a day. Some vendors send pricing information exclusively in PDF format over email. The manufacturers never maintain a format for more than a month, and downstream consumers of data can never decide how they want it. Finally, you'd think that once you get all of that mess sorted out you're golden. The only problem is that the auto industry is the land that time and UPC codes forgot, and there are multiple inconsistent standards for labeling parts, and data services that claim to have a mapping between them are selling snake oil at prices several orders of magnitude higher than what you'd think fair. Also no one in this industry believes in using software developed in the last ten years and I think I'll be near retirement age before my successors will first receive vendor data in JSON over HTTP/1.0.

splawn 13y ago

If only there was a way to remove the hundreds of private insurance companies they have to interface with. I assume they each have their own flavor of EDI, greatly adding to the complexity of this thing. (I have had to write interop EDI stuff with some insurance companies a while back and iirc they were snowflakes)

daigoba66 13y ago

Given the complexity of the system, the most shocking thing to me is that how little time they had to actually build it. And from what's been made public there was virtually no time for testing (load testing was certainly absent). It should been "turned on" months before the public go-live to iron out all of these issues.

spikels 13y ago
That's one thing I never understood. The law was passed 3.5 years before they had to go live. Seems like they should have had plenty of time but it seems like almost all of the coding was done in the past year with little testing along the way.

mhurron 13y ago

> I invite you to research EDI and then report back here. Assuming you're still alive. 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.

AaronFriel 13y ago

Taking on EDI projects are the the most difficult jobs I've had as a dev or as an admin. Interacting with someone else's database schema is like trying to put yourself in its designer's head, and it's on a good day when you have a standard protocol or database format. I've mostly worked in the auto-industry as end-user support and currently employed by a wholesaler - the connection between parts manufacturers overseas and dealerships, body shops and others. The business is more complicated than that, but the auto industry is one with many standards, lots of vendor lock in, and proprietary formats and coding schemes for everything. With EDI you don't get to dictate standards, you can't demand JSON/web interfaces, you usually have to deal with flat text files (good luck) or schemaless XML (you're doomed) if that. Some vendors just provide XLS files to an FTP endpoint and call it a day. Some vendors send pricing information exclusively in PDF format over email. The manufacturers never maintain a format for more than a month, and downstream consumers of data can never decide how they want it. Finally, you'd think that once you get all of that mess sorted out you're golden. The only problem is that the auto industry is the land that time and UPC codes forgot, and there are multiple inconsistent standards for labeling parts, and data services that claim to have a mapping between them are selling snake oil at prices several orders of magnitude higher than what you'd think fair. Also no one in this industry believes in using software developed in the last ten years and I think I'll be near retirement age before my successors will first receive vendor data in JSON over HTTP/1.0.