I don't mean to support any ageism and would be happy to withdraw my age reference. What that may leave is decision makers who don't always have a high enough level of digital or technical literacy. Folks who are not competent in technology decisions and implementations being in positions of decision making and spending is the point I was trying to make.
Ever heard of the Peter principle ( https://en.wikipedia.org/wiki/Peter_principle ) ?
Haha, have heard of that principle but not what it was called.
This guy gets it. Development is literally the simplest part of the problem set. The intersection of domain expertise, contracting/procurement creativity, and technical evaluation is the tough part to wrangle. Getting to the point where development can start is 95% of the battle in my experience. Not to trivialize the actual development portion of the project, but most missteps happen early, dooming projects before a…
> Development is literally the simplest part of the problem set. This is the single most important and insightful sentence that a lot of HN-ers are going to read today, and they don't even know it.
It makes me wonder what the heck they do at their day jobs. Requirements gathering is the impossible part.
This guy gets it. Development is literally the simplest part of the problem set. The intersection of domain expertise, contracting/procurement creativity, and technical evaluation is the tough part to wrangle. Getting to the point where development can start is 95% of the battle in my experience. Not to trivialize the actual development portion of the project, but most missteps happen early, dooming projects before a…
Now think of the problem in reverse, from the government's side. Why are they contracting it out when all of the most difficult aspects involve integrating with government systems, policies and personnel - things that government already knows how to do? "Because we don't have the expertise to do software development." The comments in this thread, which I fully agree with by the way, just cement my belief that if gove…
Ha, I'm currently a federal government program manager, so I am thinking about it from the government's side right now.
I've also been a consultant cog in a mega-corp and run my own small consulting business, so I've seen it from both sides.
Tech folks underestimate non tech challenges (basically anything outside of their domain), and clients don't actually know what they want. It's an age old problem in lots of industries.
This guy gets it. Development is literally the simplest part of the problem set. The intersection of domain expertise, contracting/procurement creativity, and technical evaluation is the tough part to wrangle. Getting to the point where development can start is 95% of the battle in my experience. Not to trivialize the actual development portion of the project, but most missteps happen early, dooming projects before a…
Now think of the problem in reverse, from the government's side. Why are they contracting it out when all of the most difficult aspects involve integrating with government systems, policies and personnel - things that government already knows how to do? "Because we don't have the expertise to do software development." The comments in this thread, which I fully agree with by the way, just cement my belief that if gove…
Exactly. The UK in-housed their entire website IT team, and it's one of the best set of government websites I've seen worldwide, UX-wise and performance-wise.
I have worked with Deloitte on two projects (on clients' side, I would never willingly work for Deloitte). Generally expect them to do absolute minimum necessary to meet the contract. The code was obfuscated to ensure support contract. The people employed to write it were not interested in the quality in the slightest but were interested a lot in specifics of the contract.
Serious question: why doesn't the government have its own internal software development department at this point? One that's familiar with all the regulatory and bureaoucratic hurdles and the legacy systems, but doesn't have the incentive to grift. For the amount of money they spend on these contracts surely they could afford to pay competitive salaries?
Generally, it's much better for the government to outsource. More competency and reduce corruption.
I came from a country where government tries to do all these things in house. It was bad. Paying premium isn't a big problem.
This guy gets it. Development is literally the simplest part of the problem set. The intersection of domain expertise, contracting/procurement creativity, and technical evaluation is the tough part to wrangle. Getting to the point where development can start is 95% of the battle in my experience. Not to trivialize the actual development portion of the project, but most missteps happen early, dooming projects before a…
> Development is literally the simplest part of the problem set. This is the single most important and insightful sentence that a lot of HN-ers are going to read today, and they don't even know it.
> most missteps happen early, dooming projects before anyone sits down to code
This one is more insightful (in the big non-tech enterprise / government spaces). Because the takeaway for most HN developers who flip between projects should be: (1) learn how to recognize one of these projects & (2) stay away / find a new job when you do.
I just don't understand these software deals, the price is so high. At 44 million, you can hire 146 engineers each paid 300k for a full year. Trust me, you need much less to build something like this, and there's no excuse for it to suck so bad. I'm also curious, anyone know where the development actually happened? Did Deloitte further subcontracted out? Was it outsourced?
These contracts are generally bloated, but if you've never seen how a $10M+ contract for things like this works you're probably thinking about it wrong. The actual development piece is a pretty small portion of the overall work. The bulk of it is figuring out all the requirements, wrangling legacy systems and data into some kind of shape that can either be interfaced with or imported, documentation, support (includin…
From the article it seems that they don't provide tech support neither to doctors, nor patients. And wrangling legacy systems in the field still may be worked out for much less money.
The real problem is that requirements are written in such a way that very few (in this particular case just ONE) companies can satisfy, so essentially there's no competition - exactly a kind of situation which lets to pump up prices.
And if you asking yourself are those requirements really benefit users, or specifically created for money to go to, you know, "right hands" - you're probably asking the right question.
I just don't understand these software deals, the price is so high. At 44 million, you can hire 146 engineers each paid 300k for a full year. Trust me, you need much less to build something like this, and there's no excuse for it to suck so bad. I'm also curious, anyone know where the development actually happened? Did Deloitte further subcontracted out? Was it outsourced?
From time to time I am trying to crawl government procurement portals for projects, and dropping the idea after a couple of hours again and again: only proposal, initial negotiation and documentation will probably require several people full time, this is even before any project movements..
Mind that, this it's the system where you're bidding for months for a project, and even if you have won and was good at delivery, you will be doing all the rounds for the next one again. So governments, sort of meaning to drive the price down via tenders, in reality are paying for all the losing bids too, and paying a lot.
This is not a 'software engineering' thing. If you look at it from a software development POV, then the issue is more of not having 'product managers' whose job it is to - understand the requirements, write the specs, basically champion the POV of the end user (after actually identifying the correct end user). Examples a) The article talked about the software not working on Internet Explorer (IE). Older people still…
Internet Explorer has less than a 2% market share in the US, so under normal circumstances (given the sacrifices you’d have to make everywhere else) not bothering to support is is often a sensible decision. When it’s an access to healthcare issue though you can’t really exclude 2% of users. That said, building something that works well on mobile (re your point b) but also works on internet explorer is a pretty tough…
> Internet Explorer has less than a 2% market share in the US
This is true but if you are a Government agency in a Country of 300M+ people, that 2% is still several hundred thousands users, who are calling your tech support etc. etc.
If this was a private app then it would be different, IMHO Government websites have accessibility concerns that the rest of us can ignore.