Successful Endeavours - Electronics Designs That Work!

Engineering Humour


Technology Humour

This is a follow on from Some Engineering Humour which you are likely to also enjoy. For this post I have tried to find videos that show some aspect of the use of technology that also has a humourous side to it. This was surprisingly difficult. It seems that as engineers, we often don’t give a lot of credit to the power of humour. My previous post is on page 1 of Google when I search for Engineering Humour! So the videos I did find are all by non-engineers.

This first video is by Aparna Rao who shows a range of products or art installations she developed, many of which reimagine everyday objects and have quite a sophisticated sense of humour associated. The art installations are her speciality and all require technology for the implementation. The design of objects for quirky family members is quite touching.

Design Humour

David Carson is talking about design. He uses humour extremely well in this presentation although it take him about 5 minutes to get warmed up so don’t bail out early as it is well worth listening to the end. If you are interested in design at all, Electronics Design or any other sort, then this has some very interesting points to consider. I particularly found the implications for User Interface Design to be thought provoking.

Engineering Jokes

To the optimist, the glass is half full. To a pessimist, the glass is half empty. To the engineer, the glass is twice as big as it needs to be.

What is the difference between Mechanical Engineers and Civil Engineers? Mechanical Engineers build weapons, Civil Engineers build targets.

An engineer was crossing a road one day when a frog called out to him and said, “If you kiss me, I’ll turn into a beautiful princess”. He bent over, picked up the frog and put it in his pocket. The frog spoke up again and said, “If you kiss me and turn me back into a beautiful princess, I will stay with you for one week.” The engineer took the frog out of his pocket, smiled at it and returned it to the pocket. The frog then cried out, “If you kiss me and turn me back into a princess, I’ll stay with you and do ANYTHING you want for a week.” Again the engineer took the frog out, smiled at it and put it back into his pocket. Finally, the frog asked, “What is the matter? I’ve told you I’m a beautiful princess, that I’ll stay with you for a week and do anything you want. Why won’t you kiss me?” The engineer said, “Look I’m an engineer. I don’t have time for a girlfriend, but a talking frog, that’s cool.

Four engineers were driving to a conference together when their car stopped dead in the road. The Electrical Engineer said it was clearly a wiring problem and they needed to check the fuses. The Chemical Engineer said obviously it was a clog in the fuel line – all they needed to do was clean the fuel filter. The Mechanical Engineer said that they were all mistaken – surely it had thrown a rod and they needed to rebuild the engine. They all waited for the Software Engineer to say something, as he just sat there. Finally they asked him what he thought was wrong. He shrugged his shoulders and said “I don’t know maybe if we get out of the car and get back in it’ll start.”

A math and engineering convention was being held. On the train to the convention, there were both math majors and engineering majors. Each of the math majors had his/her own train ticket. But the Engineers had only ONE ticket for all of them. The math majors started laughing and snickering. The engineers ignored the laughter. Then, one of the engineers said, “Here comes the conductor”. All of the engineers piled into the bathroom. The math majors were puzzled. The conductor came aboard and collected tickets from all the math majors. He went to the bathroom, knocked on the door, and said, “Tickets Please”. An engineer stuck their only ticket under the door. The conductor took the ticket and left. A few minutes later, the engineers emerged from the bathroom. The math majors felt really stupid. On the way back from the convention, the group of math majors had ONE ticket for their group. They started snickering at the engineers, who had NO tickets amongst them. When the engineer lookout shouted, “Conductor coming!”, all the engineers again piled into a bathroom. All of the math majors went into another bathroom. Then, before the conductor came on board, one of the engineers left the bathroom, knocked on the other bathroom, and said, “Ticket please.”

Two Engineers walk into a bar, the third one ducks.

Random things I found amusing

At one site based on PHPBB I found a section on Virtual Engineering Humour. The content was “Sorry but this board is currently unavailable”. I’m still not sure what Virtual Engineering is as I’ve only ever tried Actual Engineering.

Successful Endeavours specialise in Electronics Design and Embedded Software Development. Ray Keefe has developed market leading electronics products in Australia for nearly 30 years.  This post is Copyright © 2012  Successful Endeavours Pty Ltd

Computer Bug Number 1

On 9th September 1947, while working on the Harvard University Mark II Aiken Relay Calculator, Grace Murray Hopper was having trouble getting the machine to work correctly. The calculator was a very simple computer using relay logic. Investigations revealed that a moth had become stuck between 2 of the relay points. After they “Debugged” the machine it worked correctly. And so the term Bug and Debugged became associated with computers.

First Computer Bug - 1947

First Computer Bug – 1947

As fate would have it, the report with the moth taped to it, remained in the Naval Surface Warfare Center Computer Museum at Dahlgren, Virginia, until in 1991, it made its way to the History of American Technology Museum, part of the Smithsonian.

The origin of Bugs

However this isn’t the first time the term ‘Bug‘ had been used in relation to technology.  In the time of Thomas Edison it meant any defect in an industrial apparatus and in Hawkin’s New Catechism of Electricity, an 1896 electrical handbook from Theo. Audel & Co, we find the entry:

The term “Bug” is used to a limited extent to designate any fault or trouble in the connections or working of electric apparatus.

So the application to computers was natural. These days, we mostly think of bugs as flaws in software programs since that is where we spend most of our time Debugging.

Edsger W. Dijkstra once said , “If Debugging is the process of removing Bugs, then Programming must be the process of putting them in”.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile at Ray Keefe. This post is Copyright © 2011  Successful Endeavours Pty Ltd.

Engineers do have a sense of humour

Engineers might seem terribly serious about their work, but Engineers laugh too.  And of course, what makes them laugh is as unique as the work they do. The classic Dilbert series of cartoons by Scott Adams are a case in point.

This first example of Engineering Humour is is a classic piece of Dilbert humour titled “The Knack

In a recent blog post on Embedded Software Testing I also shared one of the jokes that looks at the way different Engineering Disciplines go about looking for faults or problem solving.  It goes like this:

There are 3 Engineers in a car going for a drive. The first is a Mechanical Engineer, the second an Electronics Engineer and the third is a Software Engineer. Fortunately the Mechanical Engineer is driving because the brakes fail and they are going downhill.  The Mechanical Engineer eventually brings the car safely to a halt and gets out to examine the hydraulic systems.  The Electronics Engineer gets out and checks and body computer, ABS system and the power train CAN bus.  The Software Engineer stays in the car and when queried about it says that they should all just get back in the car and see if it happens again!

And another of my favourite pieces of Engineering Humour is this joke:

The optimist says, “The glass is half full”.
The pessimist says, “The glass is half empty”.
The Engineer says, “The glass is twice as big as it needs to be”.

And an excerpt from a classic piece of Mechanical Engineering humour with the Engineers Guide To Drinks.

Engineers Guide to Drinks 2010

Engineers Guide to Drinks 2010

Anyone who subscribes to our blog will automatically get a full copy of this sent to them.  Thanks to Steve DeLosa of DeLosa Design Services for sharing this with me.

Over time I plan to add more content here but this will get the process started.  Please feel free to add any jokes or humorous stories as comments and if you know who first told any of the jokes listed here, please also let me know that so I can properly recognise the creators. As Engineers, one thing we do respect is the right be be recognised for what you do and create.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © 2010  Successful Endeavours Pty Ltd.

Software Testing

I recently met with an Australian Software Development company, PepperStack, and we got onto the subject of Software Testing. As someone who began their career as an Electronics Hardware Engineer, one of the things I learnt was that you have to test thoroughly to be sure everything is working as it should be. With Electronics, if you make a mistake with an Engineering Calculation you can easily destroy things. This is sometimes referred to as “letting the smoke out”. So it was good to meet with others who believe in the same level of rigorous software unit, module and system testing that we do.

Some Engineering Humour

Which reminds me of a joke I once heard:

There are 3 Engineers in a car going for a drive. The first is a Mechanical Engineer, the second an Electronics Engineer and the third is a Software Engineer. Fortunately the Mechanical Engineer is driving because the brakes fail and they are going downhill.  The Mechanical Engineer eventually brings the car safely to a halt and gets out to examine the hydraulic systems.  The Electronics Engineer gets out and checks and body computer, ABS system and the power train CAN bus.  The Software Engineer stays in the car and when queried about it says that they should all just get back in the car and see if it happens again!

Now don’t get me wrong, I’m not having a go at Software Engineers. The process of finding and eliminating faults is a very important part of the development cycle and is something that needs up front thinking and not just responding to symptoms.  And the more complex or sophisticated a system is, that harder it is to fully test every possible response to every possible stimuli and after a certain point it becomes impractical to have 100% Test Coverage (every line of code has been executed through all of the possible states).  The reason this is a bigger problem with Software Development is that the flexibility of software means that it is inherently complex and it takes skill and planning to manage that complexity so it is testable.

So here is the issue. More than any other discipline, faults can be experienced by an end user of a product under a situation or scenario you could not have proactively tested against before release.  There are many potential reasons for this including:

  • change of hardware or operating system environment
  • new standards or protocols
  • the sheer number of potential combinations of drivers, peripherals, software and users
  • the product being used for a purpose it wasn’t originally designed for
  • gamma ray corruption of a memory location – I am getting esoteric now but in some areas like avionics and space this is a big threat

So how do you reduce the likelihood of these problems occurring?

Improving Software Quality

With many new products having Electronics and Embedded Software and the Software Development requiring 80% of the effort, it is important to delivery it as quickly and fault free as you can. The main weapons in your Software Quality arsenal have been known about for a long time but are, in our experience, just not used.  These are:

  • Architectural Design – work out how the data and execution flow will happen and how you will manage the constraints
  • Functional Decomposition – divide and conquer but with an emphasis on how each module fits into the system and how the interfaces work in detail
  • Error handling – who will decide what to do with response codes – again this is data and execution flow and part of the architecture. In many cases exception management is at least 50% of the project.
  • Have an Integration Test Plan – some thing that proves the data and execution flow matches the architectural design.  Too often “it builds” seems to be good enough here.
  • Unit Test modules – so you remove all the issues before adding them to the integration
  • Do the Integration Tests before you try system testing
  • Design modules so you can integrate them as shells then add functionality down the track
  • Have NVM and configuration data available at the beginning of the project and not as an after thought at the end
  • Have a System Test Plan and use it
  • Use some of the good practices of Test Driven Development – run the tests every time you change the code
  • Have a rationale for what level of Code Coverage you can accept
  • Have a rationale for what level of Churn you can accept – Churn is the percentage of the lines of code that have changed in the past time period.  Usually either a week or month depending on the size of the project.
  • Use automated software quality tools. For instance we use both PC-Lint and RSM to automated many software quality metrics which saves a lot of time in Code Reviews
  • Use Code Reviews, also known as Software Peer Review.  It really does save time.

Next I plan to look at what you can learn about software testing from a Squash Racquet.

Ray Keefe has been developing high quality and market leading electronics products in Australia for nearly 30 years.  For more information go to his LinkedIn profile. This post is Copyright © 2010  Successful Endeavours Pty Ltd.