John Larkin does like simple stuff. The sort of complicated gear where you have to think hard about what it is actually doing, and how best to impleme nt the details of doing it are outside his comfort zone.
That's John Larkin's comfort zone.
Clients' thinking gets a lot clearer after you've explored the implications of what they are asking, which isn't always what they actually need.
-- Bill Sloman, Sydney
The UK version of this is "we never have time to do it right, so we always have to find time to do it again".
It's not a great environment even if all you care about is your paycheck, b ecause the paychecks have a nasty habit of stopping suddenly.
-- Bill Sloman, Sydney
That's basically how we designed MCUs (and mainframes before that). The architecture document was used in everything from the design, to simulation/verification, test, and much of it ended up, redacted, as the databook. There was no project until the architecture document was done.
Actually, it's a very nice environment to work in, if your work product is learning how to design a product. When the customer spec comes in, we have a good idea what the best way to proceed is because we've done it a number of ways already.
Once a gadget is in production, we change a resistor by releasing an ECO. The ECO must explain why the resistor was changed, as well as direct the change itself.
-- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
Of course it will get changed by the time the product is shipped. But a preliminary manual should have specs, interface protocols, application examples, versions and accessories, pretty much everything a final manual should have, except actual pictures and boilerplate.
We define BIST and its error report early on; of course that will change as the hardware is implemented. We don't always know how many power rails or temperature sensors it will ultimately have, or what certain parties might change in design reviews.
Yes, unless the really tricky stuff is not, never going to be, in the public manual. I handle that with a separate design doc, or put it in the private manual and later strip it from the public one. Either way, the tricky stuff gets archived.
The idea remains: document it before you design it.
-- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
We expect rev A, first PCB etch, to work and be sellable. Some of our products sell as rev A for years. Just slow down and do it right.
-- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
The more expensive it is to change, the more people will work to get it right the first pass. Compare bridges to Windows apps.
7 nm ICs will cost hundreds of millions of dollars for the design and mask set. I suspect there will be some care taken.-- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
t.
Yeah, I saw the ECO coming. We had this guy who wanted ECO's. I started doing that.. more paper work. At some point I found out that this guy, was making changes w/o eco's or my OK, (more important!) Anyway we are small enough that I take changes to the few other people building stuff. We mark-up/change the production doc's. Silk screen changes go into the next pcb order. And we'll mark up the pcb's on hand.
If there's stock with the "wrong" part that get's pulled and reworked.
In lots of ways circuits are the least of my worries. Yesterday we had a batch of metal/glass adhesive that didn't work... Don't ask me why, new stuff, and now several diffraction grating's have gunk on the back.
George H.
It's kinda important for everyone to be on the same page when the design team numbers well into the hundreds, on a half-dozen sites on three continents, too.
Errata still happens.
I "prototype in foil" so *don't* expect the first layout to be sellable. Rather, I expect it to be reproducible (so I don't have to "hand build" each development prototype -- particularly for the "shake-and-bake" guys).
Ages ago, an employer clued me in on calling these "rev X" (eXperimental?) and the convention stuck.
When you settle on a design (one of the X(i)'s), you've already had a first pass at the layout have fitted it to the enclosure to resolve mechanical interference problems, have a good idea what manufacturing concerns will be as well as some preliminary numbers on reliability forecasts and failure modes (from which you justify your warranty overhead).
[Cuz you -- or any "concerned department" in your organization -- can build another lot of "prototypes" identical to the ones you're using!]The problem with "evolutionary design" (i.e., guys who can't seem to make up their mind what they *do* want -- but know immediately what they DON'T want -- after they have SEEN IT) is that people start thinking you're "almost done". Sales people start dropping by for dog-and-ponies (or should that be dogs-and-ponies?). Purchasing starts wanting to buy the long-lead items. People leave the company/project (cuz it never feels like they're "almost done, just stick with it for a little longer...") etc.
And, NONE of them hear your disclaimers that the software is nowhere near complete, the motor driver catches fire twice a week, the enclosure only fits because someone took a Dremel to it, etc.
When I started doing contract work, friends (in the business) initially cautioned me to take everything as T&M. I *quickly* tired of that approach as it gives the client carte blanche to drag a project on indefinitely ("No, I *don't* want to spend my life watching you change your mind each day; there are other, interesting projects that I'd like to be working on instead of rehashing THIS one, *again*!")
[I opted "no bid" on the last T&M project I looked at, some decades ago, when *my* estimate crested $250K and that was BEFORE knowing how much the client would vacillate during the project. The fellow who took the job -- lowballing at $70K -- never finished; the client pulled the plug when their out of pocket crossed the 100K figure... with NOTHING to show for it! Gee, *I* could have told you that $100K ago (and, in essence, *did*!)]Instead, I would offer clients a fixed cost quote -- BUT, they had to decide what they wanted. Anything left unspecified was entirely at my discretion. It made for some interesting "fact-finding" interviews: "What do you want to happen when the user does ______" "Oh, I don't care..." (/sotto voce/) "When the user does _____, the device should catch fire and spew molten components in all directions..." "WHHAAATTT??!!! Don't be absurd!!!" "Ah, then you *do* care what happens!"
IME, this was a win as it let both of us know there was an "end" to the project. Client knew what the extent of their "investment" would be as well as the approximate time frame. *I* knew when I could start to transition to another project (No, I won't be staying around to work on Version II! I've learned most of what I wanted to learn from Version I; time to move on to something else!)
A surprising number of companies can survive, like this, "despite themselves". So, there's no respite. No one learns (so the "practice" never changes) because they never pay a *noticeable* price for this behavior.
I've seen firms drop $1M into a project -- and then start work on its
*successor* (without even attempting to commercialize the original project) because they "discovered" it wasn't a desireable, cost-effective product (it took you all this time "tinkering" to come to that conclusion?)And, while the folks who worked on the project were paid for their time, none were happy to see their efforts essentially *discarded*!
You don't need to "build something" to do that. You need a client who is willing to *think* about what he wants (though "think" isn't a strong enough word). If he can't *imagine* his product, then you're in for a tedious, unrewarding experience dealing with his frustrations as he fumbles along.
*Brides* spend more time thinking about what they want at their wedding (down to the color of the napkins!) than most clients spend thinking about what they want as a product offering!
The document *is* the design. All that remains is the "busywork" of actually *doing* it.
And don't take on anything complicated.
-- Bill Sloman, Sydney
Oh god yes. I've often had them specify their solution, without specifying their problem. Often when the problem is elicited, there is a much simpler solution.
"Knowledge elicitation" is an important and underrated discipline.
I've successfully done that in cases where the customer is an expert in their subject matter. Not all customers are like that.
The worst cases tend to be "we need an updated version of X", where they don't really know what X does because it has evolved like Topsy. The best response is to run away!
I've seen companies get bogged down in "paralysis by analysis". Evolutionary design is a valid response to that problem, but naturally it has a different set of problems.
That's unfair.
There are things that are externally simple but internally complex. Working on such things can be very rewarding, financially and intellectually.
Of course, many things are externally complex and internally conceptually simple - but the external complexity makes the internals messy.
And a very good comfort zone it is too :)
Not all problems are amenable to that. Running away from such messes is perfectly respectable.
But it would be stupid to presume that everything can be reduced to a simple problem+solution.
Yes indeed.
Yes. Softies typically blanche when you impose a constraint that any errors will take 3 months to detect and 10 years salaries to correct. (Figures from a 2um semi-custom design a third of a century ago).
Novel bridge designs still come unstuck sometimes even today.
And in the US old ones fall down due to inadequate maintenance regimes.
Software simulations and layout rule checking tools playing a large part in ensuring that no detectable errors get past first base.
Chips with detectable errors still get through. The original 8087 FPU had a few that lay undetected until Cyrix used formal methods to reverse engineer its functionality and found them.
Other FPU implementations have been known to be dodgy since, likewise instruction decoding.
-- Regards, Martin Brown
you have to think hard about what it is actually doing, and how best to imp lement the details of doing it are outside his comfort zone.
More unkind than unfair.
Naturally. Hiding the internal complexity from the user is a necessary part of the design.
Example? In general, if the internals are simple, you can and should reflec t that in the user interface.
And unprofitable.
ions of what they are asking, which isn't always what they actually need.
-- Bill Sloman, Sydney
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.