"There are quite a few designers who would cut and try rather than analyse the problem. Even worse and I find that in embedded software more often, the design documentation is done after everything works."

That's for sure!

My development habits now are close to the same as they were when I was a "captive employee" and had a boss (now my clients/customers are my bosses). Anyway, I always spent a lot of time up front in the design phase, which created much grief for those bosses that wanted to see something now (presumably, even if it was wrong). Others around me would hack-test/hack-hack-test/test-hack-hack-hack-test... -- you get the picture. When they said they were "done", their stuff still didn't work. More often than not, when some deliverable of mine finally popped out after all that (documented) design, it just worked. I used to tell my bosses (somewhat tongue-in-cheek and with all due respect, of course) that "I test to verify that my design works, not to see if it works!". Try that sometime, but don't say where you heard it. ;-)

Regarding that "deliverable finally popping out" comment, don't get the wrong idea, deliverables in the form of design mock-ups, prototypes with test user interfaces, etc., are good to get out in the open up front, but what goes on "under the covers" gets designed in, not hacked in.

The bosses who recognize and appreciate good design principles are successful clients and friends to this day (hehe, and those to whom I could get away with saying that "verify that it works" phrase); those who don't have that appreciation... well, who cares? Those good bosses that cheerfully insulate you the engineer/designer from the Sales/Marketing weasels are "the good guys in white hats". Fix their computer, take them fishing, give them 1/4 of your elk -- they are your best ally and one of the best assets to the company!

The delicate balance is to not be a hero for fast delivery of something that doesn't work, but to be a hero for delivering something that did make the market window, and is documented, but that you never see again (beware, no instant gratification following this path). That is, no SPRs, bug fixes, Customer Support Rep faces in your cubicle, and the next time you deal with that (by now legacy) design is for feature enhancements 5, 10, 15 years down the road after your company has saved substantially on buying bushels of parts masked with your firmware.