www.panelsoft.com

 

 

 

Home

Training

Reading

PanelSoft

User Interfaces and Usability for Embedded Systems


Feedback to Murphy's Bookshelf - Murphy's Law, Oct' 2003

return to Murphy's Law

Niall,

You said: "Gray makes many references to engineers getting the opportunity to build something that didn't have a military objective. Many of these engineers spent their careers designing jets for the U.S. military and, therefore, were much more motivated to build something with a more altruistic goal."

Don't most engineers believe that the defense of America is beneficial (benefits others)? Living in San Francisco I am bombarded with this kind of thinking -- that work done in defense of the nation is a low form of work. I think it is the highest!

Altruism = "devotion to the welfare of others" Let's drop our defenses and see what happens to the condition of our welfare!

Cheers,
Del Hatch

Niall's response: Thanks for your feedback, and I appreciate that your opinion on military work differs from mine. Part of the quote y0ou refer to was motivated by a point in the book where Harrison is trying to recruit an old friend and he says "They are going to let us build something that does not have guns on it." (I do not have the book to hand here so my quote may not be exact). Anyways, I was trying to reflect that feeling from the book that struck a chord with me - so I was trying to reflect a message from the book as distinct from expressing my own opinions. Having said that my own slant would be also fairly anti-military.

Bear in mind that I live in a neutral country, Ireland, so from my point of view the "defence of America" generally means one country holding a lot of power over smaller countries. While most Americans believe that they are entitled to develop any and every sort of technology in their own defence, they deny that right to other countries - you may say that some of those countries are run by nutters, but the engineers in those countries think Bush is a nutter, so working on Iraqi defence weapons is just as honourable a goal as working on US weapons. For my own part I would not choose to work on "defence" or military projects for any country, including my own- I figure if you have lots of bombs around, some of them are bound to go off, and bombs going off is, on average, a bad thing for someone.

I lived in San Fran briefly myself, and I see your point that opinions there are very different to the rest of the US - however if you lived outside of the US, you would find that the opinions in SF are more similar to those in the rest of the world. The US used to receive a certain amount of respect as the "policeman of the world", but Bush has lost that respect, and it will take decades to fix the damage.

Sorry if all this makes me sound like a pinko-commie-surrender-monkey. I generally avoid this topic in my columns, since it is a forum for technical, rather than political, discussion, but on this one I let my colors show.


Dear Niall,

In the "Murphy's Bookshelf" section when reviewing "The Code Book" you said: "...One of Alan Turing's greatest achievements was the cracking of the German Enigma machine during World War II..." I would like strongly object to your comment as it discrimantes the historical achievements of polish cryptoanalysts that actually cracked the Enigma Code in the 1932!!! Turing merely was given the chance to continue their work and contributed in a very limited way.

Or maybe Turing invented "Reverse Polish Notation" as well? Why not, lets go and rewrite the whole history again... Best regards,

Adam Czaplinski Senior Embedded Software Engineer

Niall's response: You make a fair point and history will always be written with a slant towards one's one. In fairness to "The Code Book" it does give a lot of attention to the Polish work on Enigma, though I did not refer to this in my article.


 

Hello, I enjoyed your article from 09/04/03 on embedded.com

I am aware of the effect you are talking about and illustrated with your seaweed example.

quote:

"I have had to struggle with this issue on many occasions in my career and have come to the conclusion that new techniques can fail if they are hard to debug."

Nowadays, I use C and C++ everyday with nice source level debuggers that have a lot of shared knowledge about what the compiler has created but I remember the pain of adopting C early or C++ early and (in the case of C) stepping through code that was both hard to follow but painfull to witness as a natural born optimizer.

The Standard Template Library, is a counter example. In this case, I cannot avoid using the STL just because it is a huge pain to debug, because the productivity benefits are amazing. I eagerly await debugging technology to catch up.

Now, I have a jaundiced eye not because of the 'seaweed effect' but because I know that newer techniques (especially ones grown in-house) can carry large burdens when put into practice. Our company has recently returned to C++ from an 1 1/2 year excursion into Python. Not only was Python much more difficult to debug, its performance really became an issue.

Our company recently went down the road of interface based architecture. Similar to COM or CORBA we now have a unified system of defining interfaces using an Interface Description Language (IDL). The problem is, the system as designed adds layers(s) of abstraction around every object and call. The IDL we are using has only encompasses a fraction of C++. Every object now requires dynamic casting through every return value because the IDL only supports a few simple types. We now have this self perpetuating mess seeping into every aspect of our work. It's increddibly difficult to debug because the debugger has no way to know to what a pointer is pointing. It makes gratutitous use of templates and thus is harder to debug than the STL but with almost no benefit that I can determine.

But because I am afraid that I just "don't get it" and am like the people of Aran, I don't want to completely write off a new technique. I certainly dislike this system because of the difficulty with debugging.

So, I in summary, often in the rush to more productive methods, the debug cycle is overlooked. It should be an important part of the design and no techique should be considered finished until debugging is fully addressed. I don't know if/where this fits in with the seaweed anology...

David Galloway
Senior Programmer
Humongous Entertainment
Bothell
Washington

[PanelSoft Home | Training Courses ]