TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

“The real problems are with the back end of the software”

125 点作者 wwilson超过 11 年前

29 条评论

jroseattle超过 11 年前
&quot;The front end technology is not the problem here.&quot;<p>Let me fix that statement: &quot;The front end technology is not the <i>worst</i> problem here.&quot;<p>Looking at the resources loaded for the sign-in page, I counted 58 separate Javascript files. Including one that implied by name was minified, which on inspection clearly was not. I didn&#x27;t bother counting CSS or image resources. I returned to the page two days ago, which indicated it is down for scheduled maintenance. It remains in this state.<p>CGI obviously borked this project. The government deserves its own special classification of criticism, but poor planning, change management, etc. from the government is no excuse for CGI not building an architecturally sound web site.<p>The contract was $350 million? Good grief, they overpaid. Nonetheless, if we could go back in time AND assuming we needed to spend this budget, here&#x27;s what I would have done:<p>1. We make investments of $15 million in 20 different startups, and tell them to implement the initial phase -- let&#x27;s say we call it the &quot;minimum viable product&quot; or MVP. Each startup has the same deadline for delivery.<p>2. On the delivery date, all companies meet with us to review their MVP. We call it a &quot;demo day&quot; and view all 20 demos.<p>3. Through some set of criteria, we create a short list of five companies from the 20 demos. Those five companies receive an additional $5 million investment, and another delivery deadline.<p>4. The companies iterate on their MVP and come back for another demo, this time with a deep dive.<p>5. We pick a winner from those five. The winner gets another $25 million investment and is responsible for any additional work to be completed.<p>TechStars for government, essentially.
评论 #6622481 未加载
评论 #6622548 未加载
评论 #6622269 未加载
评论 #6622416 未加载
评论 #6622442 未加载
评论 #6623010 未加载
评论 #6622414 未加载
评论 #6622982 未加载
评论 #6622561 未加载
评论 #6625430 未加载
waterside81超过 11 年前
Hyperbole aside (&quot;... an act which would border on criminal negligence if it was done in the private sector and someone was harmed ...&quot; - what does that even mean? So all of us who have shipped buggy software for our customers are borderline criminals?) - this doesn&#x27;t surprise me in having dealt with the VA. They have legacy upon legacy upon legacy, with all sorts of fun limitations like not being able to have a &quot;\t&quot; in your content because that&#x27;ll screw up their backend which relies on tab-delimited data. Health care in the US is playing catch up technology wise to almost every industry. And not for lack of technology, but for lack of political will power.<p>My favourite example of this was trying to deploy an app within the VA that was written in Django. I was told &quot;Python is not on the list of acceptable languages.&quot; So we came back to them and said, &quot;Good news everyone, we ported it to Java.&quot; Of course, it was just Jython, but that&#x27;s the sort of stuff you encounter.<p>Multiply this by the complexity involved in trying to herd all these cats into one backend like healthcare.gov and it was doomed to fail.
评论 #6622392 未加载
评论 #6622510 未加载
评论 #6622719 未加载
评论 #6622444 未加载
ams6110超过 11 年前
Slow, legacy backend systems are not an intractable problem. You can do things such as copy the data to a faster cache, or you use some kind of queuing system so that queries are processed only as fast as the backend can handle (of course the frontend needs to be able to &quot;check back later&quot; for the results).<p>This does support the widely held disbelief that this system will be fixed anytime soon. Clearly the management of the project and the design of the architecture are&#x2F;were fundamentally flawed, and its very unlikely that it can be fixed in 30 days or whatever at this point.
评论 #6622220 未加载
评论 #6622190 未加载
critium超过 11 年前
I&#x27;ve worked in and out of the public sector for the last 10 years and unfortunately, this actually _PAR FOR THE COURSE_.<p>This is not the contractors fault. Its the government. Before I left to work with a startup, I was abhorred by the lack of ownership on the client&#x27;s side. Everybody is looking to shuffle responsibility, keep the lowest profile, and do the least amount of work.<p>It doesnt matter who&#x27;s writing the code, unless they find somebody competent and passionate on the government side, large projects are destined to fail and better left off to be written by the public sector. This is government waste at its best.<p>I&#x27;m neither republican or democrat but just to add, if my rinky dink app I was working on for the Dept. Of Commerce gets shown to the president when its in &#x27;ALPHA&#x27; state, there is no way the most informed person in the world didnt know that the site was going to fail from the get-go.
评论 #6622223 未加载
评论 #6622612 未加载
greenyoda超过 11 年前
&quot;<i>There are no easy fixes for the fact that a 30 year old mainframe can not handle thousands of simultaneous queries. And upgrading all the back-end systems is a bigger job than the web site itself. Some of those systems are still there because attempts to upgrade them failed in the past. Too much legacy software, too many other co-reliant systems, etc.</i>&quot;<p>30 year old (1983) mainframes and databases were designed to handle large transaction loads. For example, airline reservation systems and banking systems were built on them.<p>And upgrading a mainframe (at least an IBM mainframe) to a faster mainframe isn&#x27;t such a daunting task, since all the code from 30 years ago (or even from the 1960s) is still object-code compatible with the new machines - you can make it run even if you&#x27;ve lost your source code. There&#x27;s still lots of 30 year old (and older) Cobol code running on mainframes today.<p>I agree that re-writing the 30 year old software would be hard, but simply getting it to run faster could probably be done just by spending money on the latest mainframes and disk drives. But if nobody ever did a load test on the site, they wouldn&#x27;t have known that they had to do this. They probably just thought: &quot;Oh, we have to write a web site that talks to a bunch of databases, how hard could that be?&quot; (By the way, they could have written test code to do a load test on those legacy systems without even having a web site running. In retrospect, that&#x27;s the <i>first</i> thing they should have done, and it would have shown them that their critical path wasn&#x27;t the user interface.)
评论 #6622622 未加载
评论 #6623145 未加载
评论 #6622526 未加载
digikata超过 11 年前
&quot;Failure isn’t rare for government IT projects – it’s the norm. Over 90% of them fail to deliver on time&quot; Is this really much different than the success rate of startup culture where VC&#x27;s count themselves successful if 10% of their investments yield a return? The startup environment has the &quot;success rate advantage&quot; that if the venture really isn&#x27;t getting traction, you can walk away from it, or change directions a do something related, but not your original objective.<p>Government projects like the healthcare exchange don&#x27;t have that degree of freedom - if they go down the wrong track, the only choice is put in more resources until it&#x27;s back on track. Giving up or changing objectives isn&#x27;t a decision under the control of the project - it&#x27;s a legislative or budgetary question.
JulianMorrison超过 11 年前
The answer is that you can&#x27;t structure the transaction as a realtime query. You have to structure it as something that&#x27;s sent and gives you a ticket, and the reply associated with that ticket will come back in its own time.<p>Stick the processing pipeline in Twitter Storm (which can retry any step until the whole pipeline is done) and structure the requests as nearly-idempotent (so a repeated reply is harmless, and the first arrival associated with the ticket wins). Finally, you have an &quot;inbox&quot; where people can wait for and see their answer, with optional SMS and email notification.
评论 #6622761 未加载
bhauer超过 11 年前
I have not followed the development of this news closely, but skimming these updates has been amusing. I do have a couple very basic questions. If these are stupid, I apologize ahead of time.<p>My understanding from previous coverage is that some of the state exchange sites, such as California&#x27;s, are performing acceptably. If that is true, do those state sites also connect to and query the same legacy systems as the federal site? If so, why doesn&#x27;t the federal government simply ask for or take that code? Surely it&#x27;s been made available to them? If not, are the legal requirements for the states&#x27; exchanges somehow different than the federal site? That seems unlikely since my understanding is the federal site is simply standing in for states that elected to not create exchange sites. I don&#x27;t see why it would be subject to extra requirements.<p>What am I missing here?
评论 #6622399 未加载
taternuts超过 11 年前
&gt; Amazingly, none of this was tested until a week or two before the rollout, and the tests failed.<p>This is absolutely incredible.... two weeks?! Dealing with these legacy systems should have been the absolute first thing tested, is it not the most likely point of failure&#x2F;bottleneck? Someone on the team had to have been screaming about this and ignored, all the while shitting their pants waiting for go live for the whole thing to crumble.
patja超过 11 年前
I&#x27;m wondering why states were allowed to build their own systems and opt out of the federal site. From the Washington state site we get passwords emailed in clear text, a failure to even allow people to enter all components of their income (resulting in inflated tax credit decisions), using monthly income figures where annual ones should be used (again, more incorrectly inflated tax credits). In Oregon they say they can&#x27;t even log in or get through the application. Each of these state-specific sites cost tens of millions, each resulting in their own unique set of defects on launch, to implement a federal program.<p>The press seems very focused on the obvious availability and performance problems as well as the errors that come up within the sites that prevent someone from completing their application. There are a whole slew of second-order defects that make it appear your application was successful and correct but were based on incorrect calculations, incomplete data, or other bugs that are not obvious to the user at the time they complete the process.
评论 #6622349 未加载
fauigerzigerk超过 11 年前
Focusing on the performance or scalability of these ancient backend systems is beside the point. It&#x27;s simply not a great idea to connect a significant number of backend systems run by different organizations in one synchronous online transaction. The overall probability of failure may simply be too high, irrespective of any scalability issues.
snowwrestler超过 11 年前
I think the easiest fix at this point is to simply design around the known delay in synchronizing all the 3rd party data calls.<p>Have people enter their info, then show them a screen that says &quot;your quote will be emailed to you in 24 hours.&quot; Then the integration system has 24 hours to retry any failed data pulls, match up all the data, and generate a quote.
评论 #6622681 未加载
snorkel超过 11 年前
I don&#x27;t know how much of this is true, but I bet the truth is no less hilarious. It wouldn&#x27;t surprise me if this system has no concept of usability and offline processing queues. No matter how complex it is to process an application it&#x27;s common sense to just give the user immediate feedback &quot;Thank you for your order. We&#x27;ll contact you by email within N days to followup and report your application status.&quot; Do these people expect Amazon to process orders in realtime and fling physical goods at their door in minutes? Should buying health coverage be zero conf one click instantaneous?
评论 #6622321 未加载
ape4超过 11 年前
The frontend assumed the backend was fast enough. That&#x27;s the problem. If the frontend was made to handle really slow responses from the backend it would look different. It would not make people wait while transactions occurred. Or if might have a page that that displayed your progress: in other to do this for you we need to contact 10 databases - here is the progress of each:<p><pre><code> Database One: [=======----------] Database Two: [============-----] Database Three: [==---------------]</code></pre>
评论 #6622536 未加载
seivan超过 11 年前
I don&#x27;t believe in this anymore<p>&quot;Everyone outsources large portions of their IT, and they should. It’s called specialization and division of labor. If FedEx’s core competence is not in IT, they should outsource their IT to people who know what they are doing.&quot;<p>These days I believe each department of government that needs an iPhone application would do better to hire an iOS developer full time to maintain and polish the fuck out of it, continually.
评论 #6622316 未加载
评论 #6622534 未加载
评论 #6622385 未加载
评论 #6622352 未加载
malandrew超过 11 年前
Strangely, based on the title I thought this was going to be about future startup trends. i.e. For the last 6 years or so we&#x27;ve seen a revolution in interface design as a competitive advantage when creating a new startup, but as the low hanging fruit opportunities are used up, as lot of the really meaty opportunities are going to be in software where there is a significant backend component performing a lot of heavy lifting and magic.<p>I&#x27;m not in the least bit surprised to see that a lot of the work and resulting problems with healthcare.gov are on the backend.<p>I just wish the government realized that we have all these amazing developers over in the Bay Area that can do a better job than the majority of those developers currently writing software for government contracts. I&#x27;m shocked no one in government has said to themselves &quot;What do we have to do to make our software problems accessible to the types of engineers working at the Googles and Dropboxes of the world.
评论 #6622440 未加载
评论 #6622527 未加载
natural219超过 11 年前
&quot;Unless it is enjoyable or educational in and of itself, interaction is an essentially negative aspect of information software. There is a net positive benefit if it significantly expands the range of questions the user can ask, or improves the ease of locating answers, but there may be other roads to that benefit. As suggested by the above redesigns of the train timetable, bookstore, and movie listings, many questions can be answered simply through clever, information-rich graphic design. Interaction should be used judiciously and sparingly, only when the environment and history provide insufficient context to construct an acceptable graphic.&quot;<p>&quot;Interaction considered harmful&quot;, by Bret Victor <a href="http://worrydream.com/MagicInk/" rel="nofollow">http:&#x2F;&#x2F;worrydream.com&#x2F;MagicInk&#x2F;</a>
USNetizen超过 11 年前
The issue I see here is the author of this article has marginal experience with federal contracting. &quot;The people who wrote the code for these systems are long gone...they are prone to transaction timeouts&quot; ... wrong, wrong and wrong. There are plenty of coders still around maintaining these systems, even with the obscure technologies like MUMPS and all and they are running on rather robust hardware in huge datacenters.<p>Second of all, the government should NEVER outsource integration - the systems integrator requires an authority to manage other contractors that only the government is capable of holding.
评论 #6623902 未加载
erichocean超过 11 年前
As an aside, when I hear about the problems they&#x27;re having understanding the legacy data formats, it makes me wonder how far you could get with a high-powered, big data NLP system to &quot;parse&quot; the data. Sort of like how Google translate works.<p>There <i>are</i> rules, after all, they&#x27;re just not written down. Why not let the computer figure them out, with continuous training from people until the computer&#x27;s accuracy is high enough?<p>I suspect instead they tried to write parsers and trusted &quot;the spec&quot;, which was never even right the day it was written down. :)
colomon超过 11 年前
Can anyone verify this info? I was a bit surprised to see it wasn&#x27;t better sourced than the comments of a previous Marginal Revolution post. (Nothing against MR, but this seems like huge news if true.)
评论 #6622733 未加载
whistlerbrk超过 11 年前
&quot;Or IBM, which has become little more than an IT service provider to other companies?&quot; Come now, that&#x27;s absurd. Incredible things happen at IBM research.
chernevik超过 11 年前
Yes, and the problems are probably still worse than this.<p>Because integration means integrating _requirements_, leading to determination and priority of requirements. The current organizational structure doesn&#x27;t seem to have anyone responsible for even coordinating that. But even if there were, they would need terrific knowledge of each agency&#x27;s internal systems and legal requirements to determine what is and isn&#x27;t necessary. And enormous authority, meaning both credibility and power to dictate, to get their determinations to stick.<p>Absent someone looking over the process, each agency will just &quot;require&quot; everything they might need or want. Leaving something out is risky, unless you know a lot about what you are doing and what will happen next and trust your management. Even if they had all those latter characteristics, bureaucracies don&#x27;t do risk.<p>We all know how complexity grows exponentially. I bet the requirements document for this thing doesn&#x27;t exist, and if it did it would be a clusterfuck of epic proportions.<p>Here is my wild theory: The possibility this could succeed died the day Tom Daschle withdrew his nomination for Secretary of HHS. Not that Daschle himself is special, though he is pretty bright. But he was slated for an unusual joint role, running HHS and a White House appointment running the health care effort. A position like that might have had access to the specialized knowledge to know what needed doing and the Presidential delegation of power to get it done. If IRS says &quot;we must have X&quot; and Daschle KNOWS they don&#x27;t because a real expert knows they don&#x27;t, he can get them in line or they can explain the problem to the President&#x27;s chief of staff.<p>Here is the wild part. Daschle was canned, inexplicably, over a truly stupid tax issue (didn&#x27;t declare a car service as income), while others had far more serious issues waived (Geithner lied about CASH income despite instruction to declare it). Why? I speculate, precisely because the role he designed for himself was remarkably powerful, and effectively outside any review because of the complexity and specialization of its task. Wouldn&#x27;t the President want someone with the power and knowledge to implement his most important policy? Yes, but not someone beyond his control. Politicians are about power. JFK didn&#x27;t use the legislative skill of Johnson because he feared Johnson would serve Johnson&#x27;s interest, not Kennedy&#x27;s. Once Obama and his people realized that Daschle could become effective President, and Obama something of a titular head of state, they shivved him.<p>It&#x27;s all speculation. But it is all plausible enough to suggest why government doesn&#x27;t work. Massively complicated projects like Google work because its people are, by and large, working for a common purpose on tasks that are commonly understood under common accountability. Government and bureaucracy are fundamentally divided in purpose and understanding. The components can be united by power and knowledge, but by its very nature the system resists establishment of such power and knowledge.
评论 #6622368 未加载
评论 #6623026 未加载
vpeters25超过 11 年前
&quot;... for some inexplicable reason the administration decided to make the Center for Medicare and Medicaid services the integration lead for a massive IT project despite the fact that CMS has no experience managing large IT projects&quot;<p>Time Magazine&#x27;s &quot;Bitter Pill&quot; article stated Medicare had an IT system that made them more efficient than private health insurance providers. Isn&#x27;t such a system large enough?
评论 #6622466 未加载
devx超过 11 年前
I just hope that when this whole mess of a project goes online, and is hacked to death, NSA &amp; friends won&#x27;t be using this an opportunity to tell us that &quot;see, this is why you need to give us bigger funds and spy on everyon - to protect you against those hackers (offensively)!&quot; - even though the whole issue would be the bad programming and security of the system.
robomartin超过 11 年前
...and the website is not the worst part of the ACA ride we are now on.<p>Part of me has been ignoring a lot of the chatter around the ACA as potential right wing fabricated drama. Too much noise and bilateral bullshit being thrown about these days.<p>That was until a few days ago, when I would learn our insurance has both more than doubled in cost and is also scheduled for cancellation. Doubled and cancelled. All as a direct result of the ACA. Brilliant! To say this was shocking is an understatement. Our annual cost will go well past $15K.<p>There&#x27;s a tragedy of unintended consequences, side effects and direct effects, being played out in the background that hasn&#x27;t completely come to the surface yet. We certainly can&#x27;t be the last family to get news of this kind. That means in the coming months it is likely hundreds of thousands, if not millions, of additional individuals and families are going to receive these dreaded letters. Apparently hundreds of thousands already have. Last week was our turn.<p>At one point this and other issues will be difficult to ignore. And they will dwarf the IT issues. The website, as much of a disaster as it is, is likely to pale in comparison to all of the other, non IT, issues.<p>Some of what&#x27;s happening is related to the incredible disconnect between Washington and technology. All you need to do is listen to some of these folks talk about the website issue to see how little they understand. I heard one senator say something akin to &quot;they just have to re-enter a list of five million codes&quot;. In other words, the term &quot;code&quot; to some of these guys means &quot;numbers&quot; and that someone made a data entry error in copying &quot;codes&quot; into the website.<p>BSS (Balaji Srinivasan) covered some of this in his excellent Startup School talk:<p><a href="http://www.youtube.com/watch?v=cOubCHLXT6A" rel="nofollow">http:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=cOubCHLXT6A</a><p>A talk which, he comments, has been mutated into something far different from what he said by the modern equivalent of the &quot;broken telephone&quot; game.<p><a href="https://news.ycombinator.com/item?id=6619068" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=6619068</a><p>I agree very much with his suggestion that an &quot;exit&quot; is required. Not meaning that we ought to pull-up roots and go, but rather that the tech community ought to almost ignore the dinosaurs and go ahead and evolve a society more aligned to modern realities. In his talk he gives examples of various US cities that have been &quot;exited&quot; to some extent through technologies developed in the free market.<p>To some extent, it&#x27;s an Innovator&#x27;s Dilemma kind of a problem.<p><a href="http://www.amazon.com/The-Innovators-Dilemma-Revolutionary-Business/dp/0062060244" rel="nofollow">http:&#x2F;&#x2F;www.amazon.com&#x2F;The-Innovators-Dilemma-Revolutionary-B...</a><p>The only way to make step changes is to do it well outside of the organization looking after the status quo, because that&#x27;s all they know and that&#x27;s all they can focus on.
评论 #6622599 未加载
评论 #6623090 未加载
narrator超过 11 年前
Only supports 200 simultaneous transactions ay? Well just put a big ol&#x27; queue on the front of it with a hard thread limit and tell people they&#x27;ll get an email when it&#x27;s ready.
评论 #6622904 未加载
pessimizer超过 11 年前
The real problem is with the weird indirection of the US government providing payment to doctors&#x2F;hospitals&#x2F;pharma through subsidies, tax breaks, and tax penalties granted to or extracted from citizens that can only be spent at private insurance companies or mitigated by spending at private insurance companies who then, in turn, pay for your healthcare.<p>The sheer complexity of this rent-seeking indirection makes keeping track of the millions of distinct participant-instances that can play out in hundreds of different ways, involving integrating tens of massive legacy systems with new, flexible business logic (for a law in flux), impractical.<p>With single-payer, they could have scrapped the vast majority of this complexity.
dreamdu5t超过 11 年前
The problem is government contracting. CGI will continue to get contracts.<p>The problem is a system where if you don&#x27;t deliver you get paid millions of dollars and still get jobs.
microcolonel超过 11 年前
Since when have they even been good enough at this to critique?<p>They&#x27;re going to continue to suck royally, as royalty does.