Read the following two statements, and think about which one more closely represents the way you work — and what you believe, if that's not the same thing.
- Perfection is the enemy of good enough.
- Good enough is the enemy of perfection.
Chances are that you have quoted or have been quoted one of these. The conflict facing many engineers is that, though their manager will want them to do (and/or spend) no more than is needed to meet the spec, they themselves will want at least to learn some new technique during the work, perhaps push some figure-of-merit boundary a little bit, and feel proud of what they've achieved at the completion of the project.
As a result, the manager's view of design paradigms, and vendor approaches to delivering them, might differ significantly from the engineer's view. The relevance to the integration debate is obvious. Fixed-function integration — for instance, combining all the blocks needed to create a multichannel ultrasound front end on one chip — is the electronics industry ecosystem's way of saying, “Look, buddy, this function has gone mainstream, so henceforth it's a waste of your valuable time to design it yourself. We've taken good enough and put it in a box for you.”
That's a rather disappointing response if you're the kind of engineer who relishes the challenge of designing an ultrasonic front end that's just a bit better than your competitor's. Some people just prefer to be at the leading/bleeding edge. It's the part of the tool that wears out the fastest, but it also does the most useful work.
Metaphors aside, there is a more serious concern about reliance on someone else's assessment of what is needed to do the job. Meeting the spec is all very well, until someone realizes that the spec was flawed. Earlier in my career, I spent the best part of two years getting a device to work to its spec, only to find that the spec could never have met the market requirements.
Once the level of integration has reached good-enough-in-a-box status, there is a risk that management might infer a reduced need for broader analog skills. Naturally, I'm biased, but the reduction in the availability of those people with a nose for when things are going awry in the signal path represents a clear reduction in organizational resilience.
Reconfigurable devices, which take blocks normally deployed as external components and integrate them into a fabric where they can be connected up and programmed in many different ways, still offer plenty of scope for the analog systems engineer. I'll return to distinctions between fixed-function and reconfigurable integration in later blogs. But there's still a substantial overlap, and the programmable SoC products I work with do find many uses that require little more than a drag-drop-compile design process.
And this ease of design can lull management into thinking that engineering skill is less necessary. I discovered that just this week. I was showing a customer some sensor conditioning done on our latest simple programmable system-on-chip devices. We left some stuff out to serve more economical applications. In the front-end differential stage required for a bridge transducer, I needed to use some external resistors to set the gain, because we haven't fitted an internal resistor network this time. “No good,” the customer said. “If it needs external resistors, it needs an analog engineer, and that costs me more than an ordinary engineer.” Actually, he said it in Japanese, but that was my colleague's translation.
I found it a bit depressing that the customer didn't think an ordinary engineer would be able to calculate three resistor values and tell the layout guy where to place them. These were basically the only external components. OK, I put small caps across the feedback resistors (to be in control of the bandwidth), but are we really teaching our new engineers so little? That's another blog topic in itself. Tell me what you think.