Hacker News Reader

Comment by nightski | Hacker News Reader

Did he take his own advice? Also regarding the rewrite of HealthCare.gov - I don't know the specifics but aren't re-writes always way cheaper and far easier than the initial implementation? Is it really a fair comparison?

View on HN

The main problem with the original healthcare.gov was that it was built by contractors under the old contracting model of "fill as many seats with bodies as you can, win the contract, and charge by the hour". That business model creates a perverse economic incentive that doesn't leave a lot of room for creativity, and certainly doesn't do anything to create trust between the federal agency that requires software and the team that ends up building it. I would also say that the hiring bar for contractors, compared to 18F, the USDS, etc, is, frankly, pitiful.

> "fill as many seats with bodies as you can, win the contract, and charge by the hour"

THIS MAN knows what he's talking about. I wish more people would be aware of this.

What's even more perverse? When contracts are awarded based on the above while factoring in "diversity points" - different minorities count for different numbers of points. I will leave it as an exercise to the reader to figure out what perversity follows.

Oh, you mean the preference for women, minorities, and veterans? Yeah, that's an interesting issue. It's great in theory, but in practice ends with quite a bit of additional bench stuffing to increase preference. And then to start a company and compete for contracts, even if you're a rockstar engineer who just happens to be white and a man, good luck competing against an 8A. It's hard to complain, because I see the value, but at the same time, UGH.

Quite honestly, it creates a class of "tokens". They nominally have jobs, but their real job (for the sake of the company being awarded the contract) is to simply be a token. Certain minorities count for more than others.

I definitely wouldn't go that far in describing the problem, but yes, there are issues with the model.

The conventional wisdom is that rewrites usually fail:

  https://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_second-system_effect

  http://www.joelonsoftware.com/articles/fog0000000069.html

This article has some specifics on the rewrite of healthcare.gov:

http://www.fastcodesign.com/3047856/innovation-by-design/mee...

I too am curious if Sam will take his own advice and do a tour.

I would like to someday. Very busy with YC for the foreseeable future.

too busy to serve your country? when duty calls, we should answer. ;)

generating new companies and helping them bring ideas to light is also an asset to our country/world/society.

> aren't re-writes always way cheaper and far easier than the initial implementation

No, definitely not "always." There are many examples of big enterprise systems being rewritten that take forever and ultimately fail -- to the point where the old system is put back in place.

I suspect there's a fair amount of survivor bias there too; initial implementations that aren't cheap and relatively easy don't tend to survive long enough to get rewritten!

I'm afraid Sam Altman could be the sign of rot setting into YCombinator.

Remember Sam described Ellen Pao as doing a good job when in fact she did a terrible job and had to resign from Reddit.

Now he wants developers to go on a "tour of duty"? Makes a mockery of combat veterans who come back with horrific injuries and mental scars.

If you dig that deep for things to criticize, you'll find them anywhere.

Some of the other comments refer to rewrites where the intention was to expand scope / technology / scale / etc. The Healthcare.gov rewrite was simply to make a functional system. If you have a system that does A, it is absolutely easy (relative to greenfield) to rewrite another system to do A. The problem is that most rewrites don't just set out to do A, but to also incorporate B, C, D and E, with an easy framework that enables F, G and H, and...

Reply on news.ycombinator.com