Don't give 100 percent

[swatts]

Hello Lovelies,

Listen to your manager or spend 5 minutes on LinkedIn and you will finding yourself striving to give 100% or sometimes even 110%. I've even seen times where 110% is not enough and you have to give 200%.

As well as being mathematically impossible and stupid this maximising of effort is actually bad engineering and even worse design.

Here's some examples of where 100% is just wrong.

What's the earliest this will be delivered?

As I've described in my articles on risk here and here there are correct and incorrect ways to answer this. 1st you can give the 100% answer - If everything goes well the earliest we can deliver will be......

This is called the nano-point and it's when you have a 0.000000001% chance of finishing. Statistics are against you here. So that means you have a 99.99999999% chance of failing.

The correct answer is when do we have a >50% chance of finishing and what are the likely margins to that figure.

CPU

As a programmer (any language) there are multiple ways of using 100% CPU and high CPU will result in lots of weird bug reports and general peculiar behaviour. This is more common than you would think.

From my observations high CPU is most commonly caused by...

1. Inadequate waits in loops - common bug in all software, wire up an indicator to the loop index and look for large numbers.
2. Updating stuff unnecessarily fast (eyeballs think 10x a second is responsive, anything faster is a waste of effort)
3. Calculating stuff where it isn't required - For a lot of acquires you don't need to calculate at the same time, post-process it.
4. Make your program stateful, It then only needs to handle the requirements for that particular state.
5. Defer Updates

Another top tip is to develop on crap computers. If your GeekMaster2000 laptop is 10x faster than your customers CheapCrap 2000 you will be setting yourself up for problems.

Anything over 20% and I get twitchy!

Hardware (Channels)

For our type of system design work we're generally making the first of something. The engineering price pressure is to stuff as much functionality into the minimum system that will do the job. I've seen this mistake made often.

We like cRIO and one of the reasons is that you always have a route where you can engineer yourself out of trouble. We always over-specify, so if they want 4 cards we specify an 8 slot system. I hate having no spare capacity.

Obviously you then specify the 4 slot system for any additional systems.

So here anything over 75% and I get worried.

100% LabVIEW

To be a good programmer you need some tools in your toolkit. LabVIEW is just one of those tools. To solve problems you will be very disappointed if you open your toolkit and you only have LabVIEW in it.

For me I'm at 

45% LabVIEW, 25% Design, 10% Database, 5% Linux, 15% Misc other stuff.

Life

Oh and don't give 100% to your work, spare some time for yourself, you'll be better for it.

At college I had a teacher who would only ever give me a maximum of 65%, when I confronted him about this his response was that was about the amount of effort I put into his lessons. Personally I think he was about 25% too kind to me. I aspire to make average look easy.

Lots of Love

Steve