The picture in today’s post comes courtesy of Dr Marc Dussault, The Exponential Growth Strategist. At his recent Exponential Business Building Bootcamp, he demonstrated how a Squash Racquet gets broken from repeated use.

Broken Squash Racquet

So what does this have to do with Engineering? Glad you asked.

First, I have to explain the demonstration. Marc showed that it takes a very large amount of force to break the Squash Racquet.  He really applied himself to the destructive task and it took a few minutes of escalating Squash Racquet abuse before it finally succumbed and broke.  Some of us in the front of the room could tell just how much it required to break the Squash Racquet. However the Squash Racket already had a crack, so Marc knew where to apply the force in order to break it.  The picture above is the final outcome.  Without the crack being obvious, it would have been almost impossible to have broken the Squash Racquet using just randomly applied force.

Marc then explained that way the Squash Racquet became cracked in the first place, was by it being consistently scraped along the wall as he retrieved the ball from shots along the wall.  Marc is an outstanding competitive squash player and currently ranks  as World # 18! So he knows his stuff when it comes to squash.  You can read more about this at his Mindset Of A Champion blog.

So if you know what to look for, you can monitor the thinning of the racquet and get an idea of when and where it might fail.  If you don’t know what to look for, then the failure will be unexpected.

Software Testing and Software Engineering

A lot of Software Testing can suffer from the same problem.  If you already know where the weakness will be and how to spot it, then finding a bug is easy.  You can set up the scenario, monitor for the symptom and confirm the failure.  Or, if you have enough resources you can go the brute force approach and just break it through the persistent use of randomly directed and escalated force of testing.  However very products are simple enough and very few companies are large enough to have that level of resource and to solve the problem this way.  So for the rest of us, the other 99.995%, a more intelligent approach is needed.

Since you don’t know where and when it will fail, it is best to remove failure causes from the beginning. This is where Software Engineering come is. Software Engineering is not just coding.  Coding is the production end of the Software Engineering process.  Software Engineering is about designing the system so you have defined the components so they are each fully testable in their own right. Then you can apply processes like Unit Testing to ensure they are fully functional as stand alone pieces of software. You can then perform Integration Testing to ensure that software added to the system correctly handles both the Execution Flow, also known as Control Flow, and Data Flow required including error and Exception Handling. The result is that you build up a fully working and correctly executing system quickly and with great confidence. It isn’t a magic bullet but it is close to it.

As was famously quipped by Edsger Dijkstra, “If Debugging is the process of removing bugs, then programming must be the process of putting them in”.

So if you put less bugs in, you have less debugging to do. And that saves time and removes future time bombs.  Because the chance that you find them all is zero percent. And you can’t create a system that is 100% testable by brute force means. So you have to go about it smarter.  It will save time, money and improve the business outcome now and into the future.

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.

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.

Today begins Australian Engineering Week 2010.  You can get a full run down on all the events at Make It So which you might recognise as a tribute to the Star Trek series. 

It got me thinking about why I got started in Engineering.  It was music.  I had done 1 year of a Science degree focusing on Physics and Chemistry at Deakin University and had taken a year off because I had no idea why I was doing a degree.  So I worked a few mundane jobs and joined a pub band.  We were pretty bad.  I had only started playing guitar a year before that.  The equipment was low grade and needed a lot of maintenance and I was constantly trying to improve the PA, the mixer, the guitar and amplifier and the effects.  They were all analogue electronics in those days. It was mostly trial and error and occasionally trial and success!

What if I knew enough about Electronics to be able to improve, or even design from scratch, my own guitar effects pedals, guitar amplifiers, mixing desks and PA system?

But where would I learn that?  So I went back to Deakin University and asked them.  And they suggested Engineering.  I had mostly thought of Engineering as roads, buildings, bridges and transport so this was a new type of Engineering for me.  But I was also hooked.

Four years later with a First Class Honours Degree in Electrical Engineering I was doing just what I had set out to do.  Electronics Design was now a part of who I was, not just an area of study.   My rig was designed and built by me.  And I also doing electronics design and custom pro-audio equipment construction for recording studios and professional musicians.

So check out Australian Engineering Week 2010 and for some more insights into Engineering you can also read the blog at Engineering Education Australia.

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.

My thanks to Tim Heemskerk of ABB High Voltage Division in Lilydale for this clip.  It shows how dangerous High Voltage power can be in Electric Power Transmission Systems and why ABB take so much care in how they handle High Voltage Switching, Power Factor Correction and Fault Isolation and Reclosers in systems operating at these Elevated Voltages.  Be sure to wait for the slow motion replay at the end.  I think these guys might have seen an episode or two of Myth Busters.

For those who don’t recognise them, the rectangular boxes with terminals sticking out the top are High Voltage capacitors used for Power Factor Correction in Power Distribution systems.  They have been charged to 13.8KV and hold 9675J of energy.  The pull cord is used to close the electrical circuit and the capacitor voltage is applied to the watermelon which conducts the current and the energy released causes it to explode rather spectacularly.  Not what you want happening in a real Power Distribution scenario which is why you want Engineers who know what they are doing working on both the Engineering Design and the implementation of these High Voltage Distribution systems.

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.

So I was very pleased to be receiving an award recognising the business side of Successful Endeavours.  The award was presented by Dr Marc Dussault of Exponential Programs and recognises entrepreneurs and business people who have demonstrated excellence deploying exponential strategies in their business by profitably creating exceptional value for their clients in a manner that is both measurable and sustainable. The award received was in the category of Engineering Consultant and was one of only 6 handed out in 2010 and the only one in that category. 

Exponential Entrepreneur of the Year 2010 Ray Keefe receives his award from Dr Marc Dussault.

You can read more about the awards at Exponential Programs Entrepreneur of the Year Awards page. 

The main reason for this post is to touch on the most significant aspect of this award for me. I once said that as a Business Owner I made a pretty good Engineer.  The past 18 months has a seen a transition away from that to the point now where I can say that I am an Entrepreneur who is also an Engineer.  Engineering is a Profession and so it isn’t something that suddenly stops being relevant.  Our education and mindset is all based on practical problem solving through the use of technology while balancing performance, risk and cost.  And we apply this skillset and mindset to most aspects of our lives, even when it isn’t the only way to go about it.  So I am very pleased to be making this transition.  Not only is our business better for it but our clients are as well. 

And I also thank our clients for the trust they have placed in us to deliver Electronics Design and Embedded Software Development for their next generation of market leading products, the vast majority of which are still made in Australia at a profit. 

Here is a picture of the Exponential Entrepreneur of the Year award certificate. 

Exponential Entrepreneur of the Year Certificate

 The initial nomination was published on PRWeb at 2010 Exponential Entrepreneur Award Winners Announced. 

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.

A funny thing happened to me the other day during the Christmas shopping rush at our local shopping centre in Endeavour Hills.  Our daughter had purchased some clothes for her nieces for Christmas and used the self serve checkout. When she got home she discovered she had not had one of the security tags removed so she asked for my help.

OK, I might be an Electronics Hardware and Embedded Software Engineer but I did do a year of Physics and Chemistry at Deakin University before switching to Engineering and I have had a role in the design of Multidisciplinary Systems with Electromechanical Actuators and Variable Frequency Motor Drives including Multi-Axis Robotic Handlers.  So I thought, “How hard can this be?”

The first step was to review the problem and identify the information.  Those familiar with Edward De Bono‘s Six Thinking Hats will recognise this as the White Hat stage.

I had:

• circular plastic sealed tag with an alignment  feature – a hole through it to accept a tapered pin
• a metal pin with a large head inserted into the centre of the plastic disk
• no other visible connection points

So assuming the tag was made at a minimum price, needed to be aligned correctly to be released and could be disconnected without an external power source; I concluded that the release mechanism was probably magnetic.  So I got a magnet and did some experiments and I could hear something click inside the security tag as I moved the external magnet around.  Now I am very confident that it is a Magnetic Latching Mechanism.  But no orientation of a single magnet released the pin.

I got 2 magnets and worked around the unit until the pin released and the problem was solved.

Having released the tag I gave the garment to my daughter to wrap in Christmas paper and put the tag with pin inserted back into it by the front door.  Since we were shopping the next day I thought I would return the tag.  At the very least it would get recycled.

What’s so good about being an Engineer?

At the shops, I went to the help desk and offered them the tag.  They were very confused.  I explained that it had been accidentally left on one of the items we purchased so I took it off and was returning it to them.  The stunned reply was, “You took it off yourself”?  “Yes” I said.  “I’ll have to call security” was the next reply.  So I said, “It’s all right, I’m an Engineer“.  “Oh, that’s fine then” was the reply and I wandered off to collect some final groceries for Christmas dinner.

So apparently there was a connection in the shop assistants mind that made being an Engineer something special.  They may not have know what that connection was.  And that got me wondering about Engineers and what is so special about us.  Here is a bit of a list of my initial thoughts if I ignore specific Engineering Disciplines:

• we create the future by designing and constructing the machines and systems that it requires
• we routinely solve complex problems that others do not know even exist
• we do all of this because we want a better world and are prepared to do our part to achieve it
• we have learned that covering up a symptom is not the same as solving the underlying problem

You might have some thoughts of your own so please leave a comment.

And of course, I hope you had a Merry Christmas in 2009 and that 2010 is a very good year for you all.  Happy New Year!

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  Successful Endeavours Pty Ltd.