Become a fan of Slashdot on Facebook


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: Re:Is this really a problem unique to devs?? (Score 1) 347

by bughunter (#49147969) Attached to: The Programmers Who Want To Get Rid of Software Estimates

Oh, I agree, I could have prevented a metric fuckton of shit landing in my lap. I know that now. That's just how i learned it the hard way.

Now, any estimate I give includes plenty of margin. Like the top post says, poor managers get worst-case estimates, plus a healthy margin for the inevitable negotiation that will take place.

The same applies for cost estimates. I learned the hard way the first time I was asked to present an estimated cost to complete forced by an unexpected 16-week delay in critical long lead part from an overseas supplier. I made a diligent effort to present an accurate ETC to the customer. No margin, no padding, just my honest, well-documented estimate of the cost to complete the project.

I was expecting to be dealing with the engineers and project managers I'd been working with all along, who were competent technically and I got along with well. But instead, the customer (major aerospace prime contractor) sent in their best hard-ass negotiator who was an MBA with no understanding of the technical side.

Mr. Hard Ass refused to accept that I wasn't bullshitting him. And the engineers I got along with so well didn't do a thing to back me up. They just sat there looking uncomfortable. After two days of going over the schedule and estimate line by line, and me refusing to cut anything other than the slightest costs, Mr. Hard Ass went over my head to the CEO, who agreed to a 25% percent reduction in the estimate across the board. He just ate the cost.

I got dressed down hard for not padding my numbers, but he was decent enough to understand that the ultimate blame lied with the suppliers who waited until 4 weeks before their agreed delivery date to notify us they'd be 16 weeks late. And it was a lesson I will never forget.

Comment: Re:Is this really a problem unique to devs?? (Score 5, Insightful) 347

by bughunter (#49142015) Attached to: The Programmers Who Want To Get Rid of Software Estimates

No, it's a very common problem in engineering in general, and not unique to software. But the reaction "let's eliminate estimates" appears to be.

As an engineering manager, I learned the hard way many times how estimates turn into deadlines. Your estimate is reported to the manager's manager and so on up the line, and someone uses it in planning their shit.

Your estimate, in which you did not build any schedule margin, then becomes an item in the critical path of someone else's plan, someone who didn't build in any margin either, or —worse— who was pressured to make a completely fictional "plan" which is really just a backwards-calculated paper justification to "prove" that a job could be completed in an impossibly short period of time by assuming nine women can make a baby in one month and things like shipping, reproduction, and quality assurance take place in zero time. This "plan" makes upper management happy. Temporarily.

You, leader of a small team that is working merrily away, accomplishing real work and solving the occasional unexpected problem (OEM pinouts were wrong, widget zeta delayed in shipping, amplifier stage behaving like oscillator, etc.), are asked for a status update. Because of your unexpected problems, your estimated completion date is now two weeks later than your previous estimate.

Now the middle manager, who knew he wasn't going to meet the "plan" he was forced to develop, now has someone to place the blame on. He knows he's going to be in the path of a metric fuckton of shit, but he's placed himself uphill of you.

It's clear even in TFS that the real problem isn't estimation, it's poor program management, lack of requirements management, and often also marketing-driven decision-making.

In other words, the same old shit.

Comment: Re:Molecularly interesting, applications not so mu (Score 1) 64

by Thagg (#49046547) Attached to: Polymers Brighten Hopes For Visible Light Communication

It's not particularly uncommon for an article about a scientific breakthrough to be almost satirically misleading.

If this really works, for instance, it could be a revolution in television design; far better than the quantum dot technology that people are adapting now. But, if the article was about TVs then it the responses would all go in a million directions (comparisons to plasma, talking about energy star ratings, whatever).

Back in the 50's, it was pretty common for scientists doing nuclear weapons research to talk about things that would happen in stars of unconventional configurations; when they were really broadcasting to the USSR that the US scientists had solved problems with hydrogen bombs that put them far ahead.

Comment: Re:Actual Solaris Sysadmin Here - Here's the story (Score 1) 190

> SunOS/Solaris started out lean; when it got bloated, people like me jumped ship. Linux started out lean and it is getting bloated; when it is getting too bloated, I will jump ship again.

FWIW, Linus said that Linux is bloated. That was at LinuxCon in 2009. I don't think that's much of a factor. I'll agree with you that Linux has plenty of life left in it.

Comment: Re:Actual Solaris Sysadmin Here - Here's the story (Score 2) 190

> Wow. How impressive. Oh wait, Linux has had EDAC since 2006. But you keep paying your millions to Oracle. I'm sure its worth it.

Actually, this might be worth an illustration. It was a long time back, so I'm sure I've forgotten a few details, but I'll give you the big picture.

Around 2000, Sun Microsystems had a problem with the L2 cache on their 400mhz CPUs. It seems that IBM misrepresented the error rate on the chips, and they were having bit errors that were much higher than specified. Because of what was supposed to be an incredibly low error rate, they engineered the L2 cache with parity protection. That's enough to detect an error and cause a UE (uncorrectable error) event. So I know that your EDAC functionality in 2006 was in Solaris well before 2000.

After that problem, Sun Microsystems did two things. First, they mirrored the L2 cache. Second, they completely beefed up their handler for CE/UE (correctable errors and uncorrectable errors) along the memory/cache/bus/cpu to bring it up to Enterprise level error handling. You get an Uncorrectable Error in your CPU's L2 cache. Do you panic? I looked over the EDAC documentation and I could be wrong (please correct me, if so) but it looks like that would result in a panic. Or you could just have it log that the UE event happened but take no action.

What would Solaris do differently? It would find the page of virtual memory that had the corresponding error. Has it been modified? If not, just discard the page, log the event, and go on. There is a whole set of rules it goes through to determine the best way to keep the system running when it hits an uncorrectable error. Let's say that the page was modified and that there was an uncorrectable error in the L2 cache. We panic now, right? No. Solaris checks and sees who the page of memory belongs to. If it is a user process, then that process is simply killed (and the event logged) and the OS continues running. Only if it is a dirty page of active kernel memory do we have a panic.

That isn't just recovering from a soft error. That's recovering from a hard error. So, as this story illustrated, there are quite a number of things happening behind the scenes in an enterprise level OS. You picked a good example with Linux EDAC.

Comment: Re:Actual Solaris Sysadmin Here - Here's the story (Score 1) 190

> Why bother? Just shut down that server, replace the memory, restart. If your application can't handle a brief downtime for one of your servers, there is something wrong with the application, and no OS magic can fix that for you.

You know, it is kind of funny. Person A will argue, "See? Linux has all of the cool features of an enterprise class operating system. What makes Solaris on SPARC so special?" When you point out just a fraction of the things that Linux doesn't do, person B will jump in and claim, "OMG that OS is so bloated that people are running away from it for that very reason!"

Hey, Solaris on SPARC certainly has its issues, but let's be real here. People are not running away from it in any significant numbers due to the inclusion of enterprise-class features. The irony to that argument is that you'll find that many of these "bloated" enterprise-class features in Solaris have been working their way into Linux for years. Linux has been making great strides over the past ten years.

I am more bored than you could ever possibly be. Go back to work.