We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
So I'm looking through my 'old code' and I came across some code that is clear and concise. The ingredients of good codemonkeying. But I cannot help but to think that the 'next guy' who may have picked up my work wouldn't understand it. It is a complex system in VHDL. It used about 70+% of the fabric in the only FPGA chip that would fit within the physical design parameters.
Anybody picking it up would be forced to use my code, because to 're-invent' that wheel, they had better be good at VHDL and know the requirements really well.
Otherwise they would also have to redesign the hardware, and shoot the R&D cost back up again. My gut feeling is that *they* would try to work with my code until they got fustrated and decided to re-write it. A re-write would then force them into a larger FPGA, thus changing the hardware.
Knowing this, I see my 'fabulous' code being a total waste of time. It is ever so clear in the code itself. But any new guy picking it up would have to be savvy: yet even "the big brain on Brad" won't get any kudos from management for taking over the project (using my work). Leaving him\her with feeling dissatisfied with the project.
It just makes me fustrated knowing that IP can be so easily lost when *they* lose the people they relied upon to do the R&D effort.
I guess this is another rant at stupid management people: penny-wise and pound foolish. "They" invested alot of R&D to get that widget running, and without my help I'm sure they are stagnated. If not, they spent plenty acquiring the talent needed to pick up where I left it.
I am sure that you veterans have been-there-done-that too. No matter how much you document a design, there will always be IP that didn't get written down that is critical to the project. Part of that missing IP is my fault, but I can easily defer that to management's *need* to reduce cost and time by not allowing me to re-annotate the entire project after it was successful: leaving that "for another day." (which never came while I was there).
That re-annotation of the design documents is critical to solidifying the IP investment and save many-many man-hours in reworking a 'cutting edge' R&D design.
My warning to you managers (I've been one myself, so I know the position well) is to ensure a full loop-closure is done after the widget has been successfully deployed and capture all of the details needed to 'swap' engineers and still maintain the large investement made during the initial R&D phases. Budget for it!
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
I am sure that you veterans have been-there-done-that too. No matter how much you document a design, there will always be IP that didn't get written down that is critical to the project.
Ah, yes. Software archaeology. Been there, done that.
In my case, the code was 20-something years old, some parts in 68k assembly, some parts written in completely custom assembly for a customized, very quirky ASIC. And the deadline was "we want to ship it in 6 months".
In the end, I decided on figuring out _what_ the code did, and reimplemented that (with some modifications) on the new hardware.
Ouch. Twenty years old code! An ASIC in 6 months? That must have been some pressure for sure.
What burns me up is when 'they' hold the contract for three months and then suddenly 'they' say "You know that nine month plan you had? Well, we have six months to do it in."
I hope that second rendition wasn't as quirky.
Ouch. Twenty years old code! An ASIC in 6 months?
Fortunately, the "new device" did not require an ASIC anymore. Microcontroller technology had advanced enough that an off-the-shelf uC could perform all the tasks without breaking a sweat.
At least the code is now written in C, so that the whoever develops the successor to this device in 20 years won't need to learn exotic or arachic assembly dialect. (However, I must admit that learning enough 68k assembly to analyze the old code was quite interesting, and it made me regret not getting into assembly programming in my younger days, 25 years ago.)
it made me regret not getting into assembly programming in my younger days, 25 years ago
I came from the EE world into codemonkeying 30 years ago, and Assembly was my choice (I didn't have a "C" cross-compiler back then). I re-wrote the CP/M MP/M bios so many times, I finally realized that it was waste of time to dink with a tool, as I wanted to use a computer for embedded uC development. I think that is why I have zero interest in Linux. I don't want to spend my time dinking with an OS to get a tool running. Since I started in assembly (via toggle switches on an S-100 IMSAI 8080), I have a perspective on the efficiencies of "C" and I always look at the resulting assembly code just to make sure its 'optimized.' Now-a-days, Keil and others are very optimized. I rarely delve into assembly as my source code. I do when I want or know that certain time-lines need to be met. Generally, I have no problem starting a project in either "C" or Assembly, just as long as the governing documentation is in place: it doesn't matter [to me] what language is used. That is unless "portability" is at stake. But that would be vetted prior to starting the project.
I do feel fortunate to have come from "the bottom up" vs from a high-level language down into assembly. Lance Leventhal's books were invaluable back in the day... and Leor Zolman's BDS "C" too!
But today, with the efficiencies of Keil IDE tools, I have little need for assembly and do most (if not all) of my stuff in "C" (for the '51 and ARM). (with Ti DSPs I do get into assembly for the loop-closure mathematics). Even HDL is analogous to assembly because one can do it via schematic, but I'm a control freak, so I do that in VHDL.
My OP was spawned due to knowing how much money got lost due to a failure of capturing all of the nuances of the project. Hence a total waste of time and the loss of my own IP development. It just made me mad.
Extraordinary code requires extraordinary comments.