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."

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?

Easy the us constitution forbids states interfering with interstate commerce. Therefore the FCC has the right

Verizon's arguments about controlling content are absolute red herrings. A content creator like a newspaper gets to determine the content and articles they publish or promote. The manufacturer of the paper it's printed on has no say.

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.

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.

It's absolutely sickening how many trolls have responded to this topic with comments about people "just wanting attention" or the world being better off without them, and other such tripe.

The absolute cruelty and judgementalism of people who've never dealt with chronic depression or mental illness is just shameful.

This is the "intelligent" commentary of slashdot nowadays?

Man has this place ever gone down hill. How I long for the days of harmless "trolls" posting comments about Natalie Portman and hot grits, which did nothing more than annoy instead of being outright mean, spiteful, and hurtful.

I'm with you there... never mind the story, this layout sucks!

Btw: if you include something to this effect in the subject line, it'll show up in comment pages more often / earlier.

It is ridiculous of course. It is also a common attitude among PI's toward their postdocs and students, especially in high-profile, high-pressure labs.

This letter from a PI to a worker made the rounds a few years ago. The PI claimed later it was a joke. It doesn't read like a joke, and the exact same attidude is not uncommon at all:

http://www.chemistry-blog.com/...

My experience has been that management comes to the developers for estimates. They provide those estimates to the end users. The end users bitch, whine, and complain that they need it to be done in half that time.

Management then comes back to the dev team and tells them they've agreed to get the project done in half the time that was estimated.

Then both management and the user community bitch when their "estimates/targets" aren't met, and who is blamed for the issue?

The developers.

The developers always are to blame for computer problems, never the bad specs, the conflicting specs, the unknown variables, the use of "new technology" that some vendor flim-flammed onto the department/team, or anything or anyone else.

Screw 'em. Now that I'm retired, I'll never have to give anything more than the most vague ballpark estimate of how long it will take me to do something ever again. Instead, on my pet project, I just bullet point some of the things I intend to work on next -- and even that is subject to change. The lack of stress and the freedom to live my life according to my own whims and needs has proven an invaluable source of improvement in my "quality of life."

What a shame I've never encountered a job that would let you do that.

The creators of the printed ravioli were very enthusiastic about their product. "It's almost as good as Chef Boyardee!", they exclaimed. :P

*Blech*

Exactly. Lets not go back to that. Last thing we want is a webkit monoculture.

You now have min, max, and average times for a maze of that size/complexity

Estimating the size/complexity of a software project is exactly where all the error lies. The original quote was correct that it's like solving a maze, you just assumed they were talking about mazes on paper that you could estimate size and complexity at a glance. No, this is a full sized maze that you walk through and have no idea how deep and complex it is.