On reverse biasing LED subject -  standard LEDs (GaN and GaAs types) are not designed for reverse biasing and if we give continuous reverse bias, in a long run with high humidity conditions, silver electro migration in LED die will happen causing LED to fail. In the automotive world, LEDs will never be subjected to reverse bias and there are lot of lessons learned in auto industry on Ag migration. For small home projects, reverse biasing technique might be OK but for high volume and nasty environment conditions it is not advisable.

I witnessed colleagues doing that. It worked for them and it is hard to argue against something that works. It was in a situation where the relationship between them and the manager that demanded the schedule was dysfunctional. I still don't like this because it is a cover up of the real problem to avoid escalating the issue.

When getting asked for a planing I often asked the manager to what level of detail he wanted in the planning. And they always requested less detail than I was willing to give. But they always wanted it fast, sometimes directly on the spot in a meeting.

Engineers often don't think like a manager in such situations. I have learned to first think about what the manager wants to achieve.
Sometimes it is just about the decision to choose option A or Plan B. In this situation just stating the effort relation between the two ("A is much more effort than B") is all the manager needs.

Other times the manager thinks about a deadline. So the real question is probably can we finish this before the Event that is coming up. Here again answering that question will be better than detail planning of each step for all possible variations. ("we might have a demo for A in 3 weeks, but nothing to show if we go with B")

A detailed plan is a way to communicate the work packages in the process and the estimated size of the packages. Managers might only think with half a brain and only inside their tiny box, but they are not dumb. Most managers know how to weight the estimates coming from their engineers.
Therefore the inflation that the engineer puts in might just as well be cut out by the manager knowing that this engineer always inflates that much.

Then if a manager cuts the estimate and the engineer then fails to achieve the new estimate isn't that a "told you so" moment. Whereas if the engineer is able to achieve the new deadline, then the manager was right to cut the estimate, right?

In the end everybody needs to be truthful to oneself. Estimates can be wrong. We are doing stuff we never did before (otherwise we would reuse the code) therefore we never know for sure how much effort there will be. And in the end it is still the job of the manager to motivate his engineers to work harder,...

I really enjoyed your article on honesty in scheduling.  I fought that as an engineer and engineering manager my entire career.  My most significant experienced with that was when DOD-STD-2167a had just been released.  I was group leader on a project for the Air Force to develop an automated test machine.  Our company won the contract and we began to develop the system.  My engineers and I developed a very complete work breakdown, task assignments and fully develop the schedule.  Our final analysis was nearly 1200 pages, totaling approximately $10 million, a staff varying from 8 to 32 people and a total just less than 4 years.  The Air Force did the same analysis independently with nearly the same results.  They arrived at nearly the same results.

When I presented that to my management, they immediately said that we would develop it in 1 year.  Since this was a cost plus contract, they did not question the dollar amount, although they cautioned me that the program would be audited and therefore we should be very careful to justify every expense.  Additionally, I was advised that we would not be hiring that many people.  They naturally assumed that I had padded the project to make sure I would get it done.  This practice was common for many military contractors in those days.  Schedules, costs and manpower was padded a little so management could cut it to some pre-defined number that was somehow in their mind.

We built the system and delivered it to the Air Force in approximately 40 months, just less than 4 years.  My people hit the target cost within $10K.  I staffed with full-time engineers in my group, engineers from other departments as needed and as many as 20 contract software developers.  The product met 100% of the design goals.  Our documentation, developed in full compliance with DOD-STD-2167a.  The software integration, testing and verification was the easiest I ever encountered in over 40 professional career years.

The up-front work was very difficult and the learning curve was tough, but since it was a requirement for the contract, in retrospect, I wish I had been able to force the issue on all future developments.  I keep telling myself I should do this in my personal (hobby) work as well since I am still actively developing products for my own benefit.  However, I don't do it.  I'm probably too lazy, even though I know better.

I just wanted to affirm what you were discussing.  It's been going on for years and if we all would learn to be more honest about the development and structured about our development process and our managers would learn to trust their developers, I think we would all do a better job with less failures, lower cost and fewer ulcers.

Thanks for the good reminder in "Honesty in Scheduling."  I whole-heartedly agree with you.  I'll even go a bit further and assert that Engineers that lie or guess schedules are part of the problem.  As a consequence, not only to be ethical but part of the solution, we *must* capture each estimate and how we computed it.  That way we can catch invalid assumptions soonest and help our managers do their jobs, and we can learn to do better estimates. 

It's been a couple of decades since I've done any embedded systems development (other than for my own curiosity and personal use), but I've never been blessed with upper level management that dealt with the truth about schedules. My immediate managers, sure, but they were engineers, and they always lied to upper management.

As team lead at the last embedded design job I had, I was required to attend the weekly status meetings where we dealt with the after effects of management's decisions from the previous status meeting. At one point, I pointed out that this was the third or fourth week in a row they'd decided to deal with an emergency by putting the same engineer on the problem for the next three or four months, and they'd committed about 700% of his time already.

The problem was fixed by informing me that my presence was no longer required at the weekly status meetings.

Not so surprisingly, this company no longer exists.

'Honesty in Scheduling' is great, reinforces the obligation engineers have to be honest with their bosses, and should be oft-repeated and always followed, however in my experience of twenty-five years as a developer, every single manager's response to an honest schedule breakdown with detailed task analysis, was to threaten the developers. Most managers lied and said they would at least advocate for additional resources (time) if the engineers provided a detailed task analysis, however when such an analysis was presented, they would say the analysis wasn't persuasive, and then, we would be further in the hole due to the time spent doing the task analysis. If someone out there has an actual management structure that responds ethically to developer schedule concerns, they should value that management very high (scarcity).

My experience as a hospital nurse is that there is something of a similar self-defeating work ethic:  Working off the clock.  It's not unusual at all for there to be more work to do than can be accomplished in the shift. Sadly, many RNs exacerbate the situation by clocking-out and then continuing to chart, or worse, do patient related tasks. Why is this a "bad" practice?  First, there is no real record of how many person-hours of care were actually required to accomplish the requisite tasks, so management gets to continue with the fantasy that staffing and tasks have been appropriately allocated.  Second, this work is not compensated.  Third, here in California, the umbrella liability/malpractice coverage for the employee disappears the moment they clock-out. There have been cases of malpractice charged against RNs who worked off the clock.

As with engineering (I did software for some 15+ years before entering nursing), deluding ones self, or management about the actual effort and time required is self-destructive. Further, in healthcare, there can be some deadly or financially devastating outcomes.  I always told my students, as well as coworkers: Don't Do That!