Hello, I was browsing through older posts that deal with the painful issue of portability (http://www.keil.com/forum/docs/thread8109.asp). I was (and still am) a big advocate of programming as much as possible conforming to the C standard, and having a layered structure that allowed "plugging-in" other hardware. But I have come to change my mind recently. I am reading the "ARM system developer's guide" (excellent book by the way. I'm reading it because I want to port some C167 code to an ARM9 environment) in which chapter 5 discusses writing efficient C code for an ARM. The point is, and it is fairly demonstrated, that even common, innocent looking C code can either be efficient of very inefficient on an ARM depending on specific choices made, let alone another processor used! So, if we are talking about squeezing every clock cycle out of a microcontroller - I do not believe that portability without ultimately littering the code is possible!
Several heated debates, but no real "wrong" opinions.
I think the three (?) debates in this thread can be milled down to something like the following:
...
Per, You nailed it. (...and so did erik, Jack, Tamir, Johnathan, kalib, Dan, David, Paul, Christoph, and that other guy who started to click 'reply' but didn't).
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
I feel for you. Political decisions can be even worse tha uninformed decisions made by developers.
When "management" makes a political decisions, a number of people who know the problems will then have to "make do" and try to make the best of the situation.
Wow, that reminds me of a horror story...
[WARNING: OFF-TOPIC RAMBLING]
Years ago, I worked on an electro-mechanical project which was bid on by a manager who was NOT a systems, mechanical, electrical, or software engineer. He once programmed a PIC to read an ADC and UART it out. I think he once slept at a Holiday Inn Express too. Which obviously made him qualified to be the engineering manager.
Unlike all other managers at the company, he didn't consult any of his staff of highly qualified expert engineers, and submitted this bid solo. The multi-million dollar bid was accepted, and contracts signed.
Due to his total incompetence, he under-bid the contract by half. AND THEN he realized that software would ALSO be required to control the system... the project was based upon the fact that it was The First Computer Controlled System of Its Kind... so it's no wonder he forgot to bid the software.
It was then up to 'us' to make it happen. I was responsible for the control electronics and the system's software. I quoted 12 months for the software alone. He freaked out: "it had to be more like 3 or 4 months!" (to coincide with the completion of the control electronics: see a conflict? Sherlock didn't)
After I got the control electronics up and limping, the first software task was the Serial Communications link. I quoted one month to complete it; with 11 more to go. Being the genius he was, he just changed the Gantt chart duration from 20 [work] days to 5 and thought that would fix his schedule problem. Looked good on paper! AND the logic cuts a 12-month schedule by 4 to bring it in line his 3 month development schedule. It's elementary my dear Watson.
On day six, he yelled at me for it not being completed. He continued to do that until I got the comm finished. It took me four weeks. And only one day longer than the 20 days I estimated.
My clear failure to meet his schedule infuriated him, so he took me off the project and handed the job to another engineer. This action was done in retribution to me because it was supposed to be embarrassing to be kicked off a project. <sarcasm>I was SO embarrassed</sarcasm>.
The 'other' guy was more experienced in the contract-required language than I was. (If I was the project manager, this other guy would have been my first choice, and not me).
That 'other' engineer then had to provide a quote on how long it would take. After a week of analysis, the new and improved schedule estimated by the 'other' engineer took "Eleven Months." Curiously, it was just one month short of my quote, now that Serial Communications link was completed.
After that Mr. Genius did a couple things: 1) he de-scoped the functionality of the system, and 2) during telecons, he made us lie to the customer on schedule status items. "We didn't lie," we 'just' evaded the truth.
Q: "So where are you on the schedule?" A: "I don't have the schedule with me now, you'll have to contact Mr. Genius to get an accurate fix on that."
The customer started to figure out that our answers were being evasive, and they happened to be smart enough to know that we were being forced to be that way.
Note: A funny thing was that this project was recently on a TV program on -uh- 'cool stuff' and they touted "This is the only one in the world" as if that fact was something special. It was the only one because of Mr. Genius. I guess the customer was still re-evaluating the follow-on production units.
The Lesson: When managers don't take the advice of an engineer on an engineering project, everybody suffers. My advice is to let the powers-that-be know that you have "serious concerns with the errant manager decision(s). That idiot manager will eventually be looking for a scape-goat, so get it on record before he looks around at his herd of potentials. (no, I wasn't the scape-goat on that project, but I had to live with the wrath of the idiot).
Give those concerns in writing, and keep a copy. When the superiors ask about "anomalies," make a harmless reference to your initial concerns like, "at first I didn't think it was possible, then I had a brief glimmer of hope, and now I'm back where I thought it was... nothing has changed since I gave you that list of concerns I have."
This should remind them that you were on the Correct Side of the problem as it compounds itself... but don't hammer the "I told you so" too much. You'll look like The Grumpy One; ripe for a scape-goat slaughtering.
By the way, that "just lie to the customer" edict wasn't phrased that way. It was stealthy and he just required that we "didn't reveal the actual status of the schedule." This way he didn't have to tell us "You guys need to lie about the schedule." (We had weekly telecons on status an issues).
When I confronted him with the "But what if they ask about it directly?" He responded with "change the topic or tell them you don't have all the information yet, or that you'll follow up with that later."
If this happens to you, keep challenging the edict until it is forced into the light: "So, you need us to lie to the customer?"
This guy was directly opposite to what our company's reputation and what we stood for.. His shenanigans were not in view of his bosses and peers. Mr. Genius was not typical. He was eventually "removed from the position he held" when one of his peers witnessed him 'in action.' That brief period of 'evasiveness' caused much fall-out and consternation within the company. Don't ever let one of those deviants alter your code of ethics. Ever.
Per Westermark wrote: Foolish developers who make bad decisions because they don't read documentation or plan their design in advance will at least have to suffer the consequences themselves.
It is a totally different feeling when you do it to yourself versus when somebody else does it to you. (oops, off topic again).
My advice is to let the powers-that-be know .... That idiot manager will eventually be looking for a scape-goat, so get it on record before he looks around at his herd of potentials. I once made a machine control system that was to be bilingual. I documented that I did not speak spanish and had inserted other messages to test the code. A salesman requested the prototype for a demo and again I documented that it was not ready and he could not have it.
Of course, being a marketeer, he went in one night and took the unit and went to the customer with it.
Imagine his furor when he found out that 'exit' in "Spanish" was "F... Off".
Having everything documented, I could not be made the scapegoat.
Erik
Vince, Thanks for sharing your experiences with us. Your previous manager was an unprofessional lier - others, like the one that dictated me today to "finish it or the machine isn't shipped" are not much better. I didn't have the courage to deliberately damage something in protest (see Erik's story - very funny by the way) since lives may be at risk, but I actually delivered an incomplete sub-system: key safety features are not implemented because I didn't get test time ("don't worry, we always have time to work on the software." ya right, I have to go abroad for that instead of doing it in the lab!) and the little time that I did get was not enough. management does not seem to be engaged by either software safety concerns, schedules, software quality, nothing. it all does not matter as long as profits are made.
management does not seem to be engaged by either software safety concerns, schedules, software quality, nothing. it all does not matter as long as profits are made.
I'm sure some people think that "Human Safety Factors" means they've Factored in the cost of Human Safety, and it will still be profitable to ship without fully testing the unit.
erik, Funny! Justice can be sweet. But, imagine if you didn't document those things that you did. How different the outcome would have been.