Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror

Comment Re:The Free Market at Work (Score 1) 250

What if being pecked by a chicken has different risk & diseases than being pecked by a turkey? And if the difference is not tracked, how will anyone know the risk is different?

The code could "require" a parameter which is the animal type, but then each typist will enter it differently, making statistical analysis more difficult. One will enter "chicken", another "poultry", another "rooster", etc.

Specificity by itself is not necessarily bad. Although, accurate encoding may require quite a bit of time from doctors, clerks, and patients. The trick is either finding a happy medium or improving encoding assistance/UI technology,.

(Farm animal injuries are probably fairly common in rural areas. Us suburban folk may overlook the frequency.)

Comment Re:The Free Market at Work (Score 3, Interesting) 250

Tired meme. Venezuela failed because they married their economy to oil. Narrow product focus can also mess up capitalism. In fact, Adam Smith's "Comparative Advantage" encourages putting too many eggs in too few baskets. It can be quite profitable in the shorter term, but bite hard later. Focusing on "big ticket" manufacturing slammed the USA "rust belt", for example, because it stopped being their comparative advantage.

Comment Re:The Free Market at Work (Score 1) 250

Personnel are not even so much the problem...It's more about the total opaqueness of all pricing: nobody knows what anything costs.

There was a push to codify all billable medical expenses for better billing and cross-org comparing, but many in the industry complained about the complexity and learning curve of the systems. There's either too darn many treatments to categorize, or the categorization method/philosophy(s) needs a rethink.

Comment Rogue Apps [Re:Hybrid professional career...] (Score 2) 124

People like you are the bane of my existence... when your undocumented, unsupportable [bleep] is causing *my team* to field support calls at 2 AM on a Sunday morning.

That's a common problem. "Semi" IT people "in the field" get something practical up and going, but it's a potentially huge maintenance headache down the road.

The snag is that the "central" IT office usually doesn't have the resources to "do it right" from the start. They get more requests than they can handle, in part because many requests are bogus, but it takes analysis to know that.

And when the rogue app breaks, SOMEBODY has to try to fix it, and that somebody is often the central IT people when the lone-wolf builder is on vacation or leaves the org.

But one advantage of this is that the lone-wolf builder has the domain knowledge and direct contacts to make the customers/user happy, at least while it all works. They are doing much of the analysis, prototyping work, and proof of concept. If and when a formal project is started, much of the domain-study foot-work is already done.

One guy at our org cranked out bunches of apps in MS-Access that users loved. But he retired, and database file corruption issues and lack of documentation created problems for those trying to fill his shoes. However, his apps road-tested his concepts and many were ported to formal apps when the time came.

The "panic fixes", like your 2am call is still a friggen bummer, though. I don't know of a good solution. Perhaps a compromise can be made whereby the lone-wolf dev is required BY POLICY to answer a series of questions about support and do basic documentation. The questions and requirements may also encourage them to consider maintenance issues. Example questions:

Is this project critical to the organization?

What are likely problems if it stops functioning correctly?

Are you the only one who knows how to fix it?

Is there a "manual" alternative procedure in case the automated one fails?

Is there app documentation? If so, where?

Are there regular backups of the software and data? If so, where?

Comment Re:Auto company death spiral (Score 1) 122

The liability will be too great. Every accident will be the "car's fault" and result in litigation.

I suspect self-driving cars will be on average more reliable than human drivers once the kinks are worked out. Humans drivers are often inattentive, emotional, hyper, and/or drunk. I've seen way too much crap.

Thus, there's an overall insurance savings to be had. The hard part is the politics and business side of distributing the savings. Thus, it's probably more of a "social" issue than a technical issue.

Comment Re:The Free Market at Work (Score 1) 250

We don't have a free market medical system. We have a cronyist monopoly enforced by laws written by hospitals and pharma company. If the medical system produced computers, a PC would cost about the same as a Lamborghini.

Explains Microsoft Windows: the complexity of a Lamborghini but the performance of a Yugo.

Monopolies and oligopolies almost always end up sucking. Newly arrived x-opolies may be okay, but over time they grow sloppy, evil, slow, and/or anti-competitive due their size (influence power) and lack of competition.

The problem is that medical services may require economies-of-scale such that having say 7 competitors in a given market, especially rural areas, is just not realistic. Medical services are just not the same market profile as manufacturing light-bulbs.

There are so many liver specialists within driving distance. Having 7 liver specialists for 7 different insurance companies within driving distance for rural areas probably means many liver specialists would be sitting idol (or trolling slashdot). Sure, fewer could contract out to share their services, but they'd probably be able to charge high or be lackluster because they are just about the only game in town. Thus, lack of competition comes right back into play. The problem of lack of competition hasn't been solved even with 7 insurance co's.

Slashdot Top Deals

Don't tell me how hard you work. Tell me how much you get done. -- James J. Ling

Working...