Collaborate or Isolate? Find the balance⚖️.

How often do you end up working on a problem you’ve never solved before?

When you do, do you put your head down and fight it until you’ve won?

Or do you get a couple friends in the room and work through it together?

I don’t think either option is wrong.

But exclusively sticking to one or the other is probably sub-optimal.

I try (and sometimes succeed 😉) to find the balance. 

If you’re on the path of a solution, can see the end, and just need to do the work, it’s probably best to wait to share until you’re done.

However, if you’re stumbling around in the fog, I’m almost always happy with the results when I share it with a colleague. We usually both walk away understanding things better, and I’ve got a better grasp on the issue at hand.

I think the key to all this is to pay attention, and make conscious decisions about how and when to isolate and collaborate.

-Brian Schoolcraft

🔍 Trust, but Test Early!

We’re in the middle of a prototype build for a client at the moment.

It’s roughly targeted at Concept Validation level maturity.

If it meets the business goals they’re expecting, we’ll probably build more.

But if it doesn’t make much money, it could be a one off.

To avoid reinventing the wheel, and keep costs down until we’ve validated the idea, we’re including an off the shelf component to accomplish a key function.

There isn’t great documentation available for it, but the vendor assured us it would meet our needs.

Obviously, we wanted to trust the vendor. They know their product, and know what it can do.

But we’re using it a little differently than most applications, which adds a bit of risk.

Instead of putting it on a shelf and waiting for the rest of the project to be ready for it, we did a quick mockup.

And it didn’t work 😬

Our application was different in just the wrong way. The vendor had never seen the problem before.

But since we tested it as soon as we could, we had time to recover.

It turned out that the small design change required to make it work actually improved a couple other features. Win Win!

Test early!

-Brian Schoolcraft

Sometimes more wrong is more right 🤔

“All models are wrong, some are useful”

-George Box

Have you ever simulated anything? Built an analytical model of your system?

If so, you’ve made many choices.

One of the most important comes near the beginning:

What level of abstraction will best give me the answers I need?

Say we’re modeling a three phase motor drive circuit.

We could approach the problem at at least three different levels of abstraction:

Low Abstraction: 

Calculate each MOSFET switching time down to the microsecond.

Medium Abstraction: 

Ignore the PWM stuff, and just feed the motor with a set of clean sine waves.

High Abstraction: 

Treat the motor as a DC torque source and flatten the AC waveforms to their RMS values.

How do we choose?

It depends on the questions you’re expecting your model to answer, and how much detail is included in the inputs:

High Detail: 

Does your firmware have timing errors that may cause H-Bridge shoot through or reverse polarity?

Medium Detail: 

Does your field oriented control code work? Do you get the torque you’re asking for?

Low Detail: 

How does my vehicle’s drive cycle impact energy consumption over the course of a typical day?

Typically, you want to decrease model abstraction as your question’s detail level increases.

But why don’t we just run the Low Abstraction model all the time? It’s more accurate right?

That accuracy comes at a cost, which is typically longer run times. Low Abstraction models often run slower (sometimes much slower) than real time, so modeling a whole day’s worth of data could take a week.

But that same analysis could be run on a High Abstraction model in seconds.

The High Abstraction model is “more wrong” - but it’s much more useful for the low detail question.

However, It’s completely useless for a high detail question, so we’re forced to use the slower, more accurate Low Abstraction model.

-Brian Schoolcraft