Hacker News Reader

Comment by vinhboy | Hacker News Reader

The other day I was having a discussion with some other programmers about how our profession is slowly becoming a production line... pretty soon knowing how to program will be like working on a production line putting together a car. Only a couple of smart people need to design the specs, and the rest just repeat the steps.

It's interesting to me that by combining the health care industry, doctors are also becoming assembly line workers.

Go to the second floor for heart, third floor for feet, etc...

I have not decided if I like this or not.

View on HN

"The other day I was having a discussion with some other programmers about how our profession is slowly becoming a production line..."

People have been saying that for sixty years. It's less true than ever, at least for good programmers, as more and more of the accidental (in Fred Brook's sense of the term) gets automated away, leaving ever-more-refined essential behind.

If you really want to make me laugh, why don't you go design the language+framework+environment that will complete the task of making programming assembly line work. You can call it "5GL". (Google it.)

I would expect doctoring to go the same route over the next 30 years. More routine may be shoved onto checklists and perhaps even robots, but that will just make the non-routine something that becomes an even larger part of a given doctor's time.

Although we may end up having more technicians and fewer doctors. Arguably computer programming has gone this way too.

I think it is increasingly true over time. The amount of software use is increasing and the quality of programmers required to solve problems with software is declining. There's a lot of open source out there, so you can see the code and see that it isn't that great a lot of times, but it gets proliferated with marketing, much like factory goods.

Imagine the furniture artisans from the 1800's looking at the quality of furniture sold in the stores today... shoddy materials, weak joints, poor finishing. It's almost the same today in software -- or at least the trend is in that direction.

You can still get quality furniture today with solid wood, great finishes, and sturdy construction, but you have to pay 10x or 20x the price of something from IKEA. Same is true of software. So you could say it is less true for "good" programmers, but it's also less true for good furniture makers. If it is true that abundance creates scarcity, the abundance of bad software and programmers has created a scarcity of good software and programmers, just like every other industry.

Besides, saying it isn't true for good programmers is a like the No True Scotsman fallacy. What is a good programmer? Is a good programmer someone for whom it isn't true? Can you quantify what it is that makes a good programmer? Can software users tell the difference? I don't think they can.

"Besides, saying it isn't true for good programmers is a like the No True Scotsman fallacy."

No, because I can point to the people I'm referring to. In 1960, we did not have a lot of dedicated QA staff, dedicated sysadmins and IT, dedicated server farms, and so on and so on. Programmers have grown up auxiliary support personnel around them. The same has been true of doctors for a long time ("nurses") and will be more true, but the core doctors will actually be dealing with less and less of the routine.

The problem with your "software is getting crappier like furniture" theses is that it's flat-out wrong. If software was today as crappy as it was in 1980, the Internet would not work. We can't have the same bug-count-per-feature we had back then, we've got a crapload more features for bugs to be in! What is true is that we've got frameworks and libraries of a quality the programmers of the 1980s could only dream of, and a programmer can take these and trade technical quality for speed of development, and while the result can still be quite messy it is simply an option that didn't exist in 1980. On the whole though, software is radically better now than it was then; the alternative is not even technically feasible, it wouldn't even begin to work.

Seriously, if you think I'm on crack, go back and find the oldest source code you can. What you remember as a shining example of bug-free code will be revealed to be code that by modern standards is barely holding together and fails to exhibit bugs only because the task it takes on is so small there's hardly any room to trick it into doing something wrong. Not a viable path going forward.

You are looking at the past through gilded eyes and if you were an adult back in those times you would have a different viewpoint. I suffered the same thing. Romanticizing TV shows from the 80s. They looked larger then life because I was just a kid. But now when I watch them, I hear crappy dialog, poor acting, weak plots, and cheap special effects. Things you couldn't get away with today. Some people see programming the same way. Programmers back then had to rely on tricks because the hardware wasn't up to snuff. Those same tricks also make problems as the software goes.

Also, I just built my kitchen out of IKEA. If anything IKEA kitchens are the closest equivalent to todays software. Different, but interchangeable parts that fit a standard (the API). The cabinets that were replaced were 30 years old. And what you see is what you got. A little bit of rot meant the whole thing had to be torn out. If I needed to replace a door I would have to have one custom made; same for the drawers.

Now, not all IKEA is great. I had a cheap IKEA office cabinet and compared to the kitchen cabinet of the same dimensions it was 1/3 the weight. But the price reflected the quality of the goods and sometimes all you want is a cheap office cabinet, other times you want a sturdy kitchen cabinet with a 25 year warranty.

For health care as a "customer", I think I like it. I'd rather have some assembly-line style automatons applying empirically validated flow-chart medicine than old-style generalist doctors going off their gut instinct. Sure, sometimes you really need some critical thinking, but 95%+ of medicine is routine, and more liable to be screwed-up than helped by someone going off-script.

Going even further, I'd be happy to see computers do more routine medical work. It's been 35 years since the system MYCIN beat most physicians in its (admittedly narrow) area of competence, and yet we still have huge amounts of automatable stuff being done by fallible humans attempting to recall something out of a med-school textbook.

I think technology is taking diagnosis from doctors , but not in the way thought by MYCIN ( diagnose using a list of symptoms).

A better way to diagnose is using improved molecular tests, and new imaging methods. those have a few benefits: 1. Higher accuracy. 2. Sometimes you can diagnose in a very early stage of the disease , with no apparent symptoms(i.e. screening) 3. You can diagnose by the cause , not by the symptoms. when you have the exact cause you can give much better treatment.

Molecular methods probably have easier acceptance by doctors vs expert systems , probably because they don't seem as a direct competition.

In the mainframe days thats how it was. They were called computer operators. Some mathematician or scientists would give them the design spec and they would enter it into the mainframe. It wasn't production work, but it wasn't high-level programming either. Unlike today, a good percentage of them were women since it was treated as secretarial work.

I think the best way to work , is dependent by the type of knowledge has about a specific disease , and the quality of the doctor.

When the knowledge(and tools) on how to diagnose and treat a certain condition gives better results then the average doctor , it's best for the patient that the doctor would follow protocols.

But there are areas in medicine we don't know enough on best diagnostics and treatments. here we need the best doctors thinking, collaborating , experimenting and innovating both as part of giving best care , and as part of advancing medicine.

And when talking about surgeries , moving the treatment to an "assembly line" type of work, with the surgical team doing the same surgery in the millionth time , is even more important , since it can give much better results.

There are parts of the industry that have been assembly lines for years. COBOL wasn't the height of intellectual attainment, and people were doing that in 1980.

Doesn't mean the whole industry has. It has just gotten much larger, and does obviously now include some assembly line type places.

Isn't that the way it is now? Consider open source. One or two programmers build the open source package, then potentially millions of people install it and build a site. They don't even have to be programmers.

Sure, but there will always be people who want or need a great site not just a site (or even a pretty good site), and the former will probably always be much harder than the latter and demand some amount of skill no matter how good frameworks get.

Reply on news.ycombinator.com