Advertisement

Blog

Please, Keep Murphy & Hofstadter Laws Away

[Editor’s note: Every once in a while I like to have these types of articles to remind us that even when you think a design might be pretty straightforward, always be prepared for the unforeseen gotchas.]

Starting a new project always requires prior evaluation of the complexity, new skills needed, literature, demonstrators, development tools, vendor support availability, and more. It is a time-consuming but essential task during project planning. Unfortunately, we cannot cover every possible project execution aspect during project planning. As a consequence, it does not warrant immunity against Murphy’s and Hofstadter’s Laws.

Murphy’s Law: “Everything that can go wrong will go wrong.”

Hofstadter’s Law: “It always takes longer than you expect, even when you take into account Hofstadter's Law.”

Some time ago I worked on a project involving fairly simple hardware. It was barely a 100 MHz SoC with USB device support connected to some LEDs and one 13.56 MHz NFC transceiver. All the complexity was expected to be in the firmware development tasks. We integrated one very new Cortex M4 SoC and one relatively mature NFC transceiver from two widely recognized chip vendors.

It seemed simple enough from our point of view but Murphy's Law came into play. On one side, we ordered some SoC samples that turned out to be silicon revision 1 and included some bugs. Those bugs were corrected on silicon revision 2, which was available a few weeks later. On the other side, the NFC transceiver card emulation (CE) operating mode was also hiding several unpleasant surprises. What was supposed to be a mostly software development task became a brain-killing RF hardware debugging process.

Weeks behind schedule, Hofstadter’s Law proved valid for hardware development tasks, too. At that point we decided to make a radical project change. We started designing our own analog front end (AFE) to replace the NFC transceiver. There was no alternative in the market implementing all the functionalities we needed. The AFE required some signal conditioning, AD conversion, hardcoded (FPGA) digital signal processing, and load modulation generation. Not all was negative as we exercised and developed further some “rusted” skills and took very valuable lessons. Once again we corroborated the big importance of a coordinated and fluent team work for achieving complex project goals.

Have you ever had to make a major redesign for a product? Have you tried to use any component in a mode not yet fully tested by its vendor? What was your worst components selection nightmare?

33 comments on “Please, Keep Murphy & Hofstadter Laws Away

  1. etnapowers
    August 9, 2014

    “Starting a new project always requires prior evaluation of the complexity, new skills needed, literature, demonstrators, development tools, vendor support availability, and more. It is a time-consuming but essential task during project planning.” That's what usually it's called know-how: the more is the experience of a design team for a particular type of project , the better it will be the effectiveness of the result.

  2. etnapowers
    August 9, 2014

    The two laws in subject might be very useful for an engineer during the developing of a new project: when the product is working well even in the worst case scenario, in terms of functionality of each single block of the IC and of the time spent to qualify the product , then the IC is robust and reliable and will be launched on the market on time.

  3. Netcrawl
    August 11, 2014

    @etnapowers I agree with you. And also the rules, policies and strategies that your company or organization operates act as an operating system, the more efficient they are, the more likely you will be successful in implementing projects that will help you toward achieving your goal.

    You also need to take some “system requirements” approach to your company, this is very important because it will help you undertsand what  organization capacitance you will need in order to run a project smoothly and effectively. You will need a lot experience and expertise you can immediately access here.

    It is very important that you know how to identify the expertise of staff, whether you will need some external help like consultants or some outsourcing, and to get them in action in advance. 

  4. Netcrawl
    August 11, 2014

    @etnapowers starting a project always start with one important things- you need to ask yourself “Is your company ready to implement a project?” because this kind of endeavor will certainly push you and your company's capacities.  

  5. eafpres
    August 11, 2014

    I think the idea of such a self-assessment by the company before starting something new is very good.  In the past, the older, bigger companies could maintain market share by selling their deep competence as a value add to the product.  Now, the globlization of design, in large part due to the internet, has taken away much of this advantage and new companies appear based on one or two new technologies.  This causes the older, bigger companies to try to move faster, enter new areas, and stretch beyond their limits.  It is very difficult to wait until everyone is very sure.  To be competitive the risks must go up.

  6. eafpres
    August 11, 2014

    Hi Victor–I have heard a few extensions to Murphy's Law in my 30+ years, and proved most of them true:

    (1) Murphy was an optimist

    (2) Not only will anythng that can go wrong go wrong, it will do so at the worst possible time

    Another version I use of (2) is what I call Murphy's Law of Demos

    (3) The product will work fine until just before your demo to the customer

     

  7. eafpres
    August 11, 2014

    @Victor–“Hofstadter's Law–It always takes longer than you expect”

    On a more serious note, the area of predicting project schedules has been safely boxed into a tiny subset of the engineering profession called project management.  Unfortunately, they don't teach in school what project managers should know.  This leads to things like “OK, if you say it will take 9 weeks to design that, if I get 8 more engineers we can do it in one week”.  

    There are some important statistical concepts and applications that bear on predicting project timelines (and costs, for instance).  Most project mangers don't know them our use them.

  8. antedeluvian
    August 12, 2014

    Blaine

    I have heard a few extensions to Murphy's Law in my 30+ years, and proved most of them true:

    Did you see my blog on the Kagan-Gradin Effect (done for April Fool's, but only partially tongue in cheek).

     

  9. eafpres
    August 12, 2014

    @Aubrey–great stuff!  I had not read that before.

    I think your Gradin-Kagan effect is a member of a larger class which includes:

    (1) If you want something done right, do it yourself; 

    (2) Shop rate: $100/hour; $150/hour if you watch, $300/hour if you help.

  10. antedeluvian
    August 12, 2014

    Blaine

     member of a larger class which includes:

    (1) If you want something done right, do it yourself; 

    (2) Shop rate: $100/hour; $150/hour if you watch, $300/hour if you help .

    ROTFL. Thanks, I needed that!

     

  11. JamesBryant
    August 14, 2014

    Additional (fundamental – Murphy is based on it) Law:-

    The Laws of Physics continue to work, even while you're ignoring them.

     

    As Scotty tells us “Ye cannae change the Laws of Physics”.

  12. etnapowers
    August 15, 2014

    “Once again we corroborated the big importance of a coordinated and fluent team work for achieving complex project goals.” The importance of team work is really valuable, this is the real strength of a big company and the difference between a group and an individual. Each member of the team should know that something may go wrong in terms of technology or time consumption , but the mutual collaboration with the other members of the team can overtake the blocking points and this results in the success of the project.

  13. etnapowers
    August 15, 2014

    “(1) If you want something done right, do it yourself;” That's generally true, because nobody can do a thing, like you would do it by yourself , but, at the same time , nobody can do everything by himself, the expertise of other professionals is very important.

  14. etnapowers
    August 15, 2014

    The laws of physics if correctly applied by mean of its language (i.e. mathematic) can lead to a successful ending for a project. Murphy's law is useful to remember us that the interpretation of the physics has to be correct in order to avoid malfunctions due to mistakes.

  15. Victor Lorenzo
    August 18, 2014

    @etnapowers >> I agree with you in that “the more is the experience of a design team for a particular type of project , the better it will be the effectiveness of the result. “.

    In my opinion that especially holds true for teams with members from several different expertise areas.

  16. Victor Lorenzo
    August 18, 2014

    @Netcrawl, “(…)it will help you undertsand what  organization capacitance you will need in order to run a project smoothly and effectively

    In my opinion Project Managers (PM) could take advantage of any prior knowledge they have about project management theory. I think they should/must have more than a basic technical foundations and state of the art understanding in order to be able to effectively point out the required development team member skills.

     

  17. Victor Lorenzo
    August 18, 2014

    @Blane, I agreee with you on that “bigger companies to try to move faster, enter new areas, and stretch beyond their limits.  It is very difficult to wait until everyone is very sure.  To be competitive the risks must go up

    On one side it has a very possitive side effect as OSes like Linux and many other open source hardware and software projects are receiving a lot of attention and support from several big companies. The time from invention to production is getting shorter and shorter.

    On the other side it has a critical/severe drawback, incomplete and not fully qualified (in terms of quality assurance) products and components are getting into volume production/market. The two I've mentioned in the article came from two highly recognized really-big companies.

  18. Victor Lorenzo
    August 18, 2014

    @Blane, I've seen that “Murphy's Law of Demos ” in action too. When I got involved in a research and development project for the first time, I was still an EE student by then, colleagues from the Electronics Department used to call it “Efecto Visita” (effect Visit).

    Somehow systems under development, by them self, manage to get “smart” enough to detect a visitors presence and play “funny” (or not) triks.

  19. Victor Lorenzo
    August 18, 2014

    @Blane, “Unfortunately, they don't teach in school what project managers should know ” Perhaps this is partly caused by the missunderstanding that almost anyone with some basic knowledge from an almost static set of project management rules, a suite of software tools and a couple of books could lead a project to success.

    The opposite, in my opinion, also holds true. One highly skilled engineer, with almost all required knowledge for developing a product from scratch could make a horrible and completely incompetent PM.

  20. Victor Lorenzo
    August 18, 2014

    @Blane, “There are some important statistical concepts and applications that bear on predicting project timelines

    In software projects planning it becomes very difficult to predict the required time for implementing and testing the code. Here, experienced PMs and some big software companies define several software metrics and dedicate time to collect them, yet their validity for project planning is questionable.

  21. Victor Lorenzo
    August 18, 2014

    @Aubrey, thanks a lot for pointing us to the Kagan-Gradin Effect post. A must read ;-D

  22. Victor Lorenzo
    August 18, 2014

    @JamesBryant, absolutely, “The Laws of Physics continue to work, even while you're ignoring them ” and Murphy's law has a high correlation with our obsession to try to blend them.

     

  23. Victor Lorenzo
    August 18, 2014

    @etnapowers, “the mutual collaboration with the other members of the team can overtake the blocking points and this results in the success of the project “. That's exactly the point I was thinking about while writing the article.

  24. eafpres
    August 18, 2014

    @Victor–“”smart” enough to detect a visitors presence”

    I recall something similar about the office copy machine.  They could sense how much of a rush you were in, if you gave them the slightest inkling of fear, they would start jamming, making you late for the meeting etc.

  25. eafpres
    August 18, 2014

    @Victor–“big software companies define several software metrics and dedicate time to collect them, yet their validity for project planning is questionable”

    Your point is well taken. For me, I turn the problem around, like this:

    If I have, from a baseline of actual projects, an idea of the distribution of actual time required compared to original estimates, the with some relatively easy math I can estimate the uncertainty, expressed as a time window, for a given projection.  There is nothing I can do to make the projection more accurate, but I can use this information in a helpful way.  Let's say my projection is that the project could complete by November 15.  Let's also say it is critical that it get fiinished this year.  If the uncertainty of my Nov. 15 estimate is 60 days, then there is a pretty significant chance we won't finish this year.  Instead of trying to refine the Nov. 15 estimate, what should be done is look for ways that can improve the pace of progress.  Sometimes this is possible, sometimes not.  But understanding that uncertainty equates to business risk is lost in most PMs spending time updating MS Project files…

  26. geek
    August 31, 2014

    “Here, experienced PMs and some big software companies define several software metrics and dedicate time to collect them, yet their validity for project planning is questionable.”

    @Victor: I think the variance will always be there and you can't really make it to an absolute zero. The reason behind this is firstly because the software projects vary a lot in their nature and there's no such thing as a standard software. Secondly, the people making these software are human beings and you can't expect the same level of consistency from these that you'd expect from machines.

  27. geek
    August 31, 2014

    “I recall something similar about the office copy machine.  They could sense how much of a rush you were in, if you gave them the slightest inkling of fear, they would start jamming, making you late for the meeting etc.”

    @eafpres1: That seems to be the case with my laptop. Every time I have to boot it to do something urgent, the updates would start getting installed and it would always take such an enormous amount of time to be ready. I always feel it has some hidden sensors that I'm unaware of.

  28. etnapowers
    September 11, 2014

    @Netcrawl: I couldn't agree more with you. One of the major strengths of big companies is so having a lot of expertise among his departments and external consultants: an effective management of the team creation, depending on the expertise required to achieve a goal, can further enhance the engineering process. This is a key point that represents the real difference between a top company and its challengers.

  29. etnapowers
    September 11, 2014

    @Netcrawl: you're right, many times a real challenge may be the successful realization of a challenging project despite the company is not yet ready to perform the task. A success will benefit your company, a failure will teach you what you have to do to win the next time. The road to the know-how is full of hurdles but finally it gives great benefits

  30. etnapowers
    September 19, 2014

    @Victor: you're absolutely right. This is the reason for why many big companies encourage the job rotation of their employees. I think that if an engineer works on different products of different areas, he benefits an increased experience and know-how.

  31. etnapowers
    September 19, 2014

    @Victor: I got your point because I experienced directly that the success of a project of a big company is strictly related to the effort of each member of the team of sharing his background and experience with the rest of the team. The relation is bidirectional, it explains that if even one member doesn't collaborate, the project success is on risk, and this is absolutely an undesirable situation.

  32. Victor Lorenzo
    September 19, 2014

    @etnapowers, I've worked mostly for medium and small sized companies with a very limited number of engineers in the R&D team. Under that situation you have to cover, learn about and master many different areas, from electronic design (analog, RF, digital and soft cores) to mechanical design, passing even for low, middle and high level systems programming in multiple languages. It requires a lot of efforts and years for fulfilling the required knowledge and skills to produce high quality and robust products and automation machines.

    It is good to know that engineers from big companies have also the possibility to increase in experience and know-how and work in different areas.

  33. etnapowers
    October 6, 2014

    @Victor: your working experience is very interesting to me because in the environment that you described in your post there is the possibility to learn multidisciplinary  concepts covering many aspects of the engineering discipline.

    I think that in big size companies an electronic engineer can benefit the job rotation by experiencing products and activities that are several aspects of the specific electronic engineering discipline.

     

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.