The other day, I was doing some consulting for a company on their overall design approach toward a solution. I found that one of their engineers wanted to implement a MCU design in an FPGA versus doing a more traditional discrete MCU with the standard support ICs, etc.
The product was never going to go into high volume production and the electronics cost was so small compared to the rest of the system that the effort to move the MCU into an FPGA seemed more of a "fun thing to do" rather than a rational thing to do.
I told the owners of the company that if they went down the MCU/FPGA path, then they would tie themselves into the type of talent needed to support the FPGA MCU rendition of the design versus the more commonly found MCU embedded pool of talent that they could hire.
This is a subtle but important decision as it binds the company to that particular engineer's talents, or they would be faced with hiring a specifically skilled FPGA engineer at a higher cost if they were to 'lose' the original engineer (due to resigning, etc).
The owners/bosses really were excited over my point about tying their system into a too 'niche' type engineering cycle and sole-sourced talent.
A more traditional approach would be advised in this case as there wasn't much of a difference otherwise.
I am sure (pure speculation) that the engineer who wanted to move the MCU into the FPGA fabric was excited about doing so. After all, given the chance to expand one's abilities and add to their repertoire of talents is indeed exciting.
Then I thought about how his boss was going to quash this approach based upon my advice. If indeed this engineer was excited over his approach, I'm sure he was equally disappointed to have to give that up.
As you know, I'm rather wordy, but this brings up a point I learned many years ago, when I was hired to complete a project. The Project Manager told me right up front, that if I tried to code "job security" into the system, he would fire me--"as fast as he could."
I completely understood that, and all of the code I've written [before and] since has been done in a fashion that could be easily picked up by somebody else. (well, most of it was).
During that same statement, by my new boss, it was also pointed out that only a boss who can tell the difference between coding-in job security and doing properly written code, can appreciate and retain programmers [code-monkeys] who code to the benefit of the company, and not themselves; and reward them accordingly! (That was an important point !)
A dilemma with "doing it right" versus "doing it quickly" (where quality suffers) can be that in some situations you, as the software engineer, are the only one there at a company who knows the difference. In such a situation, you can see where your own morals lie.
I'm sure you veteran embedded guys know what I'm talking about, especially when it comes to taking on a project that *somebody else* has started.
This is one reason why I insist on doing the documentation to a project prior to doing the code-monkeying. It is far more difficult to design a project so that "only you" know how it works when you've written the proper set of pre-code documentation on how the system as a whole shall work in plain English.
Coding should flow from such documents and not the other way around.
Tools that generate documentation FROM your code, to me, is worthless.
It totally misses the point. An after-the fact documentation of the code tries to explain the code as written, and that most likely will hide failures of the overall architecture of a design... even hidden simply by saying "Yes, it is documented--see." [Note: it only helps if you have already done the up-front documentation and you can compare the source-to-documents against the master set of documents].
Yet if you are forced to forego the up-front documentation (a decree by one's boss) then the code you write should contain enough information in the way of commenting so that if you died tomorrow, the project can still go on and not be scrapped.
Okay, fine... not 'died' but let's say you found a new job at twice the pay and double the benefits. You quit in two weeks knowing that there is no way in hell anybody else will figure out what you were doing.
That project you half-baked will still haunt you when that hot new job goes belly up for some reason. THEN you'll have to rely on your reputation from the company you left hanging.
A burnt bridge and a stain on your resume'.
</rant>
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA