Messiest I saw: a heavily cookbook based design, for a module with a few more requirements than a cookbook design method can reasonably support.
When we got the prototypes in, I did a seemingly simple test: sweep DC input voltage over the rated range (8 to 80V -- this was an automotive related project).
It went through no less than three hysteresis loops (with respect to input current or output voltage, I forget what). I was impressed. Nevermind unintended behavior, this was emergent behavior above and beyond what the designer, or reviewer (me), expected!
(Those quirks were easily fixed, but the final design was still way more expensive, and under performing, versus what the customer needed.
)
To be more specific, the block diagram was this: PMOS for reverse polarity protection on input; overvoltage detector + switched pre-regulator (80V max input, 20V output); uModule 8-30V input, 12V output, main regulator; overcurrent detect and disable; and I forget if there were some voltage monitor, temperature limit, enable or other logic around. Input and output also had MOVs attached, which I don't think actually did anything because MOV clamping voltages are stupid to begin with, but particularly bad at low voltages.
The hysteresis arose from the switched preregulator and various quirky logic. It was very much an illustration of what goes wrong when you focus on individual points in an operating space (limiting your thinking to "I need this function at this voltage"), without making any consideration whatsoever for how it will go between points, both in the transfer function and in the time domain. (You can put a MOSFET bypass across a preregulator, sure, but how long is it going to take to turn on and off? Is it fast enough to deal with a surge or swell condition? Much of the logic was resistors, zeners and logic level MOSFETs -- probably not!)
The uModule alone was an easy enough design choice (80V maximum input requirement aside), but it's one of those decisions that has consequences. That one part was half the customer's desired BOM cost already. It was extremely noisy, throwing off low ~ns pulses from both sides (it was an H-bridge "flying inductor" or buck-boost topology), and that was after my best efforts in the layout.
And by sticking to that decision early in the design process, it dictated a two stage conversion, and all the other ugly logic. The logic at least would've been avoidable with some insight (a buck regulator that can deliver 100% duty cycle is its own bypass, no need for logic), but that wasn't done.
For my part, I suggested a single stage SEPIC, as well as various improvements and tweaks to the design as it was. Mostly left on the table in the name of schedule.
The moral is, go for the easy solution (often, a cookbook approach) when the problem is easy. If your early attempts are turning up lots of conflicting issues, don't try to force fit it. Take a step back, think wider about the problem, read about similar problems and their solutions, then go back in for some solutions. Read datasheets and see if you can find chips that will handle part or all of your functional blocks. If worse comes to worse, a discrete design is still perfectly doable today, but it may miss cost or size targets, and definitely requires more expertise to synthesize. Don't shy away from diagramming an RTL-equivalent* diagram, it's helpful towards understanding the system!
*In digital logic, RTL = Register Transfer Level, i.e., a schematic which consists of registers and function blocks (gates, muxes, adders, multipliers, state machines, RAM..), connected with wires and buses. The analog equivalent is using op-amps and functions and such. Fully implementing op-amps wouldn't be a fruitful exercise, but implementing a system with op-amps and such, is.
I suppose the other moral is to work quickly, on a high level. Understand the problem in the abstract. Use the simplest possible solution, no simpler (to paraphrase Einstein). Then dig down into each block, layer by layer, understanding the implementation of your abstraction. If you can't see the trees for the forest -- if you can't take a look up from the low level and see the abstraction -- you're going to spend far too much time resolving those minutiae, trapping yourself in a local minima that isn't a very good minima globally.
Maybe that's too much to ask for, I have no idea. I honestly have no idea. You can't simply ask someone to "just think smarter!" A person only has what logic and inference they do. At least, I've seen little evidence that it's something one can learn, and asking that of someone just makes them frustrated, or angry. It would fit the data just as well that they could, but don't want to, because asking is seen as offensive. One can certainly practice thought, or be given the tools necessary to harness it, more quickly and powerfully. But moving into a whole other order of magnitude, no, that doesn't seem to happen. Where is this going, other than rambling? I guess it leads to a contradiction against the cultural staple of "you can be anything you set your mind to", or "The American Dream(TM)", or however you like to put it. You should be ambitious, yes, but getting yourself into a position well above your capability is probably not a good idea in the long run; and in some fields, people die that way. So definitely don't do that.
Well, anyway.
Tim