Please create an account to participate in the Slashdot moderation system


Forgot your password?

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).


Comment: The black box is a trap (Score 1) 139

by msobkow (#49151699) Attached to: Invented-Here Syndrome

The problem with black-box programming is that it's a trap. Far more often than anyone cares to admit, the black box implements functionality in an unreliable or inefficient manner. When you're dealing with code that you wrote yourself, you can correct that behaviour of the "grey" box. But with a third-party black box, all you can do is file a bug report and hope that someone can not only replicate the problem, but that they'll give it high enough priority to fix it before you retire or your project is cancelled.

The worst culprit for black box problems are frameworks of all kinds. Some say you're not a "real programmer" until you've written your own framework. I firmly believe that's true, because what is a reusable code base on a large project except a custom framework?

The difference between a custom framework and an off-the-shelf one is that your custom framework is designed and coded with your project in mind, to service the bulk of your project's needs while maintaining enough flexibility to deal with the exceptional cases of your project. A third party black box framework is pretty much never designed that way. It was designed to serve the needs of someone else's conceptual or real project, then tweaked and adapted to serve needs it wasn't originally designed for, and finally unleashed on an unsuspecting world as "the next big thing."

A pox upon frameworks, I say. Design a solid object model, code to it, use it, and get over the fact that you're going to have to write some code.

At least if you wrote the code, you can fix it. Without worrying about whether some upstream integrator will deign to consider your "fix" worthy of integration to the mainstream code. Without having to wait for someone else to replicate, analyze, prioritize, schedule, implement, and test a fix for your problem.

Realistically, any half decent custom framework isn't going to be more than 10% of your total code base anyhow. "Framework" is just a fancy term for what was called for decades "application library."

Comment: Was it ever alive? (Score 1) 113

by msobkow (#49151621) Attached to: Can the Guitar Games Market Be Resurrected?

I knew a lot of people who had the controllers for those types of games over the years, which they'd either bought along with their consoles in bundles, or been given by relatives. But not once in my life did I ever see anyone actually play games like "Guitar Hero." Not once.

Yet I knew over a dozen people who had the controllers.

I wonder what percentage of those overpriced components sat gathering dust, never to be used after the novelty wore off in the first couple of weeks?

Comment: The *first* thing I uninstall is McAfee (Score 2) 131

by msobkow (#49150231) Attached to: Lenovo Saying Goodbye To Bloatware

The first thing I uninstall is McAfee. That piece of crap wedges in a VB script interpreter that breaks many of the software installers I have to put on my machines to make them useful. THE worst anti-virus product ever.

It also claims that SAP/Sybase ASE is infected, and deletes critical files from the install.

Comment: Re:Genius. (Score 3, Informative) 131

by swillden (#49150045) Attached to: Lenovo Saying Goodbye To Bloatware

Genius executive: Maybe we should promise not to do stuff like that anymore.

Super-genius executive: Maybe we should promise not to do stuff like that any more, but exempt "security software and Lenovo applications". That way we can continue getting paid by McAfee and others to continue loading their stuff, as long as they don't mind us slapping our logo on it.

Comment: "Mr. Spock" is everywhere today (Score 3, Insightful) 336

by msobkow (#49149645) Attached to: Leonard Nimoy Dies At 83

I find it gratifying to see that Mr. Nimoy is being remembered on every website and feed that I've visited today. And not merely remembered, but remembered by more people than I've ever seen pay tribute at the same time. Even the passing of Robin Williams wasn't marked with as many posts and comments.

RIP, Leonard.

Comment: Re:... Driverless cars? (Score 1) 249

So... you still have nothing to cite.

Just the fact that you're trying to pretend that this all stopped in the 1930s means I have no more patience for this tangent.

I said no such thing. You were the one who brought up the 30s, I just used your era.

And I really have no dog in this fight, and would be interested to hear about examples of the Teamsters behaving badly in recent years. So I asked if you had any evidence that they still behave this way. You apparently don't.

Comment: Re:... Driverless cars? (Score 2) 249

They are drivers not coders. We can build a metric to rank them. (Packages/hour - (SafetyWeight * accidents/year)) would work for drivers with similar routes.

At UPS they incent performance for drivers in ways that don't interfere with the seniority system.

Accident handling is pretty simple: If you have one, barring really, really clear evidence that it's not only not your fault but there is no possible way you could have avoided it, you're fired. The Teamsters lawyer will fight to get you a decent severance package, but that's it. Even with said evidence, you'd better not ever have another.

As for packages/per hour, UPS has a system that calculates the time required for a given route, including driving and deliveries. Drivers get paid max(route_time, actual_time), so if they can get the route done in less than the estimated time they get to go home early without losing pay. Experienced drivers can always beat the estimated time, usually by large margins, and even in the event of breakdowns, etc.

Further, habitually beating your route time gives you the opportunity to take on longer routes. So, many good UPS drivers habitually do 12-hour routes in 7 hours, which means they get paid for 14 hours (the last four of the 12 are time and a half) for working 7. Meanwhile, drivers who habitually take longer than their estimated times get assigned shorter and shorter routes, and, of course, there is a point at which drivers are taking so much longer than the estimate, that they can be fired for cause.

BTW, if you have the perception that UPS drivers are well-paid, you're both wrong and right. Their nominal hourly wages are decent, maxing out at around $20 per hour or a bit above, but those who work hard can easily earn lots of "fake" overtime, as in my example of 14 hours' pay for 7 hours' work. That plus massive amounts of real overtime around the holidays means that UPS drivers' incomes can approach six figures -- but only if they work hard.

Comment: Estimates are fine if.... (Score 1) 323

by mark-t (#49147141) Attached to: The Programmers Who Want To Get Rid of Software Estimates

... the functional requirements are clear, and do not change during the development lifecycle.

Except what usually happens is that a feature change will come along *AFTER* the design phase has already started, or else the requirements weren't unambiguous enough in the first place. Oh... and in the real world, at least in my experience, a developer isn't often in the position of being able to say "we can't do that", unless the developer is also very amenable to finding a different employer in the extremely near future.

This usually puts the programmer in the position of having to be a sort of prognosticator, and anticipating what the most likely types of design changes are going to be while doing development, and designing software that will be robust enough to accommodate such changes with only a modest increase in time spent, without losing any work on design that has already been completed. Sometimes, particularly with an experienced programmer, or one who really knows the people who are likely to make design change requests, and so may be able to predict what they are liable to really want beyond what was stated in the functional requirements documentation, this kind of forecasting is within the grasp of a human being to accomplish But it's never easy.

Comment: Re:Get ready for metered service (Score 1) 607

by mark-t (#49146675) Attached to: FCC Approves Net Neutrality Rules

I kind of picked that up.... my point is that a land-line telephone doesn't ordinarily have any "per use' charges in addition to the flat rate unless you are making long-distance calls.... and even then, at least for residential lines, you can often get plans that allow unlimited long distance at a rate that is quite attractive if one is in the position of making many of those calls in a month.

So sure... while there's precedent for utilities being metered from water, power, and gas... there's also no lack of precedent for utilities being flat-rate, such as telephone... or cable, for that matter.

An adequate bootstrap is a contradiction in terms.