With the recent passing of Steve Jobs, the world has had a reason to reflect on the significant impact some people have. Someone who made everything Steve Jobs did possible also passed away recently. On the 12 October 2011, Dennis Ritchie, the father of The C Programming Language, died at his home in Berkley Heights, New Jersey.

Beginning in 1970 and with the help of Ken Thompson, Dennis Ritchie began the design and construction of a new programming language. It was based on a language developed by Ken Thompson dubbed B. So the next language was called C. And the reason they wanted to create a new language? They wanted to write the kernel for the powerful multi-user operating system UNIX. that was to replace MULTICS which Bell Labs were ending their involvement with in 1969, the same year man first stepped on the moon. And in doing so, Dennis Ritchie and Ken Thompson created the framework on which all our modern computer and communications infrastructure are based.

Dennis Ritchie

The C Programming Language

The importance of The C Programming Language cannot be underestimated. Not only did it make UNIX possible, but it made UNIX possible on multiple computing platforms. It was also the foundation for higher level languages such as C++ and Java as well as most of the core infrastructure of the Internet is based on programs written in C.

A few additional reasons why C is so important:

• Microsoft used it to create their initial software offerings
• UNIX is the origin for OSX and iOS
• 80% of all embedded software is still written in C
• Our business writes the Embedded Software we create in C

The C programming language, Brian Kernighan & Dennis Ritchie

The C Programming Language, Brian Kernighan & Dennis Ritchie, was the language manual for C and was so well written that it made picking up the language easy and was one of the reasons for the rapid uptake of the language.

So much of our modern world depends on the work of Dennis Ritchie. And I along with many others are grateful. He may not have been the public figure that Steve Jobs was, but he is leaving a larger and more enduring legacy.

Here are some further accolades for Dennis Ritchie:

• Without Dennis Ritchie there would be no Jobs
• Dennis Ritchie: The Shoulders Jobs Stood On
• Dennis Ritchie, The Father Of C And C0-Developer of UNIX
• Father Of C And UNIX, Dennis Ritchie
• Dennis Ritchie, Computer-Programming Pioneer
• Dennis Ritchie, Trailblazer
• What we can learn from Dennis Ritchie
• Dennis Ritchie: the other man inside your iPhone
• Dennis Ritchie: Remembering another Computing Genius
• Dennis Ritchie Biography
• Dennis Ritchie Bell Labs

And finally the 1998 USA National Medal for Science and Technology received by Dennis Ritchie and Ken Thompson for their creation of the UNIX operating system and The C Programming Language.

And Ken Thompson and Dennis Ritchie explain what was behind the development of the UNIX operating system

We stand on the shoulders of giants. And Dennis Ritchie was a giant amongst giants.

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

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

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.

Electronics Design is a very challenging area where reducing Time to Market, increasing Engineering Effort, constantly improving technology, tooling lead time and Agile Software Development methodologies all lead to rapidly changing requirements while the project delivery time frame remains immutable. Fortunately Electronics Engineers are up for a challenge.

At Successful Endeavours we use Altium Designer for our Printed Circuit Board Schematic Capture and PCB Layout.  So I was amused to see this video clip of some of the typical things that you have to overcome when doing an Electronics Design project.  Enjoy.

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.

Manufacture Link has recognised Successful Endeavours win as Casey Business Of The Year 2010 in their website news article Successful Endeavours wins 2010 Casey Business of the Year .

Manufacture Link is an initiative aimed at increasing the opportunity for local manufacture by allowing members to create company profiles that reflect their capabilities and to also post requests for quotation so that other members can bid on work they might not have found out about any other way.

We are very committed to manufacture in Australia and in particular we provide Electronics Design and Embedded Software Development for Australian Electronics Manufacturers.

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.

Successful Endeavours were also joint winners of the Business and Professional Services award for 2010.

And we were finalists in the Manufacturer of the Year category which was won by Jain and Janice Lal at Australian Solar Manufacturing. They make high grade 200W solar panels in Hallam, as good as you can get anywhere in the world, and really deserved their win.  Well done Jain and Janice.

Casey Business Awards 2010

Above is a shot of the Casey Business Award Certificates and also the trophies we received on the night.

And here we are with Casey Mayor, Cr Lorraine Wreford, with the Casey Business of the Year award certificate and trophy.

Ray and Junette Keefe of Successful Endeavours with Casey Mayor Cr Lorraine Wreford - Casey Business Of The Year

Here we are with the joint winners of the Business and Professional Services award, Better Dental Care and a representative of Monash University who sponsored this award category.

Casey Business and Professional Services award

And here is a picture of the 3 award certificates together.

Successful Endeavours Casey Business Awards 2010

And the Casey Weekly (formerly Berwick & District Journal) on 7 September 2010 ran a 2 page special on the Casey Business Awards and this is an except from that covering our win as Casey Business of the Year 2010.

Successful Endeavours - Casey Business of the Year 2010

Below are media releases  and official City of Casey web pages related to Successful Endeavours’ win as Casey Business of the Year and also as joint winners of the Business and Professional Services award.

The City of Casey Business Media Release Successful Endeavours named Casey Business of the Year

The City of Casey official Casey Business Awards page

The Greater Dandenong Weekly 30 August 2010 Company Wired For Top Award

The Casey Weekly Cranbourne 30 August 2010 Wired for success

The Casey Weekly Berwick 31 August 2010 Wired to win the big prize

The Cranbourne News 2 September 2010 Business Backed

AMTIL News feature AMTIL Member ‘Successful Endeavours’ wins 2010 Casey Business of the Year

And we thank our clients and suppliers for being the excellent businesses they are.  This would not have been possible without you.

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.

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.

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.