If you Want Your Projects to Succeed, Learn to Sing

As a teenager and young adult, my favorite hobby was singing. I joined over half a dozen choirs over a period of 15 years, ranging from a local church choir to advanced amateur groups. I've never been really great at it, maybe just above average but it was fun. During that time, I had a chance to talk to trained singers and I now realize that their lessons have a much wider application than I originally thought.

Anatomy

I'm glad I learned to sing after I had biology classes at school. My singing trainers started off by "feel your lungs unroll to the bottom of your belly", then "your vocal folds are at the bottom of your neck" or "open the mouth at the top of your head when singing a high note"... I'm glad they are not my doctor. Joke apart, they were right: my breathing was stronger, I could sing loud without ending up with a sore throat, I could reach notes that I never suspected I could reach... My body was still the same but this new vision made me reach unexpected highs. Why on Earth should unlocking your knees relax your throat?

It is a matter of vision: think that your lungs are in your breast and you will tighten the thorax, reducing the available space. The vocal folds are in the middle of the throat: if you focus on them at their actual place, you unconsciously push them upwards, increasing stress. When singing a high note, you unconsciously bend the head upwards, stressing the vocal folds. Lock your knees and your whole body will be tense. If you adopt this different vision, the breast will relax and you will control the air flow with  the abdominal muscles, instantaneously gaining capacity and power. If you think you vocal folds are at the bottom of your neck, you will push them upwards to the middle of your neck... where they actually are but you will also intuitively increase the air pressure under them, thereby gaining the power you were seeking. Think that your mouth is at the top of your head and you will bend the head downwards, opening at the same time a number of resonators in your head (I mean physically, not mentally). Why do singers always smile? Try it by yourself and you will feel some high frequency resonators that start vibrating in the cheeks. Singers don't do anything just by chance: the secret is to focus on increasing your capacity, not on avoiding a problem. Treat your body in such a way that effort is only left for the fortissimo, when you have run out of other options.

Professional singers go through a number of steps: they learn to relax, then to refocus their vision, strengthen the control, fine tune resonators, increase power, and finally brush off all the work to make it sound natural. Pavarotti was decried by his peers because he started singing professionally before finishing this last phase and he made himself famous for the brilliance of his voice. Most of the others sing with a softer, more natural sounding voice, which is what makes their concerts pleasant and rich in emotions.

Lesson learned

Success is not just about doing things right: it is about understanding the consequences of our acts, take advantage of the effects, which will eventually fulfill our goals. As in singing, if you train your team to reach a certain throughput, they will tend to it, and any increase in demand will turn into stress. Train your team to discover their real capacity and the same demand will turn into a challenge. The attitude is what can turn a failure into success.

I have a - often criticized - habit of answering my team members' questions with other questions. It sometimes takes a little while before they understand the reasons behind it but, basically, I don't want them to execute blindly my orders. Strictly speaking, I don't have the bandwidth to make every single technical decision in the projects and, at the same time, I don't want to slow down the project by micromanaging everyone. On the contrary, I believe in empowering the members, give them autonomy, teach them to think and propose solutions instead of simply presenting problems. They will eventually come with questions but these will be more advanced issues requiring more attention. Meanwhile, I have educated them to think the way I do so that they can come up with answers we can easily agree on.

How about unrolling the lungs to the bottom of the belly? Technically, you lower the diaphragm to leave more room to the lungs. Ask a young singer to lower the diaphragm and he will naturally compress the thorax, which is counter-productive. Ask the same person to feel the lungs at the bottom of the belly, and he will relax, move the shoulders backwards and open the thorax. Same person, same goal BUT different order and different outcome. If you think about it, it works best when you lie to the person and it is all about perception. It happens to us all the time in our projects: depending on how you present the order, you see different results, and if you make the group feel they can achieve the goal, there is a good chance they will. The secret resides in showing to the group members where you want them to be by the end of the project, and not only where they are at the start. Some will succeed, others will fail but all will grow.

Before you start your next project, make sure that your group takes a deep breath and knows to visualize where their lungs are.

Internet of Things: Risks and Opportunities

The NBT (Next Big Thing) in the press recently is the IoT (Internet of Things). It is of such importance that it has its own TLA (Three Letter Acronym) and is mentioned all over the place. Journalists want us to believe that it will change the world as we know it, but will it?

Internet of Things: Evolution or Revolution?

Human societies usually use the number and impact of their revolutions to measure their importance in the global history. There is therefore a race to overhype the impact of small changes and pretend evolutions are revolutions. The invention of the stone-based fire lighter, of the round wheel or cutting a king's throat in a starving France did cause dramatic changes in the fate of society and opened to new ways of living. These were really revolutions.

IoT is just a simple evolution of already known technologies and it has been around for much longer than journalists can remember. Ever heard of SCADA systems or Home Automation? They usually didn't go over the Internet but that's really the only thing that they missed to become an IoT. The revolution (if at all) about IoT is the marketing hype around it, the new applications that are targeting general public and the new risks that we will have to control and mitigate.

What's all this security stuff, anyhow?

For those who may find this title familiar, my reference in terms of introduction of technical subjects is Bob Pease, this genius who popularized a wide series of electronics topics over the years and passed away in 2008.

From a security point of view, a system starts becoming useful the moment its first intruder breaks in: this first intruder is called the end user. The comment may sound harsh but it is a vision that developers often miss to realize. The end user is a genuine part of the system but his interface is often an entry point for hackers, and this has been known for years. With IoT, we will see that the security risks are not limited to the interface but may open back doors and impact the real world, leading to a variety of new dangers: a blog site puts your reputation at risk, a financial institution puts your money at risk, an IoT can put your house at risk.

Risks vs. Dangers

There is a thing that irritates me in the press: many firms publish articles about how secure their products are and I often get to the end without understanding their claims - and often see how they are trying to sell me a product based on unsupported arguments. Is Linux really more secure than Windows? Is a Flash-based embedded system more secure than a desktop? The security level of a system depends on the weakest link, which will probably be the application. A Flash-based embedded system can abort an intrusion when you reboot it, as long as the application locks the ability to reprogram its memory. You may statistically improve security by using well tested elements but they are no guarantee at the level of the finished product.

All systems are potential risks, unless they are obvious or obsolete. To avoid intrusions, disconnect the network cable and disable the USB connector... but this will complicate the design of an IoT system. The point is not to avoid all risks but identify and mitigate them. But what is a risk, to start with?

A risk is a potential misbehavior that can be triggered by a specific condition. For instance, you work for a company that pays your salary. There is a permanent risk that your employer cannot pay your salary at the end of the month. If all the customers go away, the risk converts to a danger. Your work is a proactive measure to ensure that your employer has products to sell and ensure your salary at then end of the month, hence reduce the probability that the risk becomes true.

Risks Metrics

Generally speaking risks must be measured in terms of impact and probability. A truck may crash into your house: if it happened, the impact would be very high for your family but, if you live in a straight section of a street, the probability is very low, hence a low risk.

For every feature that we define, it is critical to determine if it can have an impact on the overall operation and, if it is the case, how to minimize the probability. If the probability cannot be reduced either, the feature should be reconsidered.

The 4 pillars of security

I have an open letter to marketing guys: "Please do not send me an article about secure products if you don't qualify the term. Best regards. Olivier". I hope I made myself clear.

Any Computer Science course dedicated to security will talk about the 3 pillars: Authentication, Confidentiality, Integrity. I personally prefer the extended definition that includes also Availability, although it is a direct consequence of Integrity. In short, I know that my information is safe if I can identify who the provider is, make sure that no one else has access to it without prior authorization, receive it unadulterated and have permanent access to updates. If you miss any of these 4, your system is unsafe, period. Remember the option of disconnecting the network cable above? You just broke the availability of information so you just made your system unsafe by applying DoS (Denial of Service). The challenge goes beyond this.

Safety vs. Security

Safety and Security are 2 typical marketing buzzwords. However, Security is usually a better selling argument than Safety so it tends to be preferred. I don't think this confusion does anyone any good so let's have a closer look.

We have just seen what Security is about but what is Safety? Safety if the condition of being protected from non-desirable conditions (summary of Wikipedia's definition). Is a secure system safe? In essence, yes. Is a safe system secure anyhow? Not necessarily.

I saw recently an article explaining that an embedded RTOS was secure: I'm afraid that a "secure" system is not synonym of "very safe". An RTOS takes care of tasks execution and, in some cases, can isolate the tasks from each other. On the other hand, it does not control the identity of the users nor with whom the tasks communicate. From this viewpoint, we can talk about safety. Any security feature will have to be implemented in the application itself.

Is Linux a secure system? Let aside the typical discussions about coding mistakes and other flaws, it offers features like user identification, encryption and firewall that help building a secure solution. From a design perspective, it can be considered secure. Note that I'm only talking about design: if you don't configure the system correctly or apply the relevant patches, your system can quickly become the target of a hack. Linux, or any Operating System considered as secure, is not a silver bullet or a magic wand.

My RF link is secure because it is encrypted

Have you ever heard this argument? Although it is true that secure systems are usually encrypted, the reverse is not a guarantee. WiFi is encrypted but if you ever loose your password, there are some Linux distribution that will help you to crack it. I'm talking about Open Source software and a standard laptop that you can discretely take in your car. Even the computing power of a modern mobile phone would sufficient to hack into a WiFi network.

Encryption serves 3 main goals:

1. Confidentiality, reducing unauthorized read access to the information;
2. Authentication, reducing unauthorized write access to the network;
3. Integrity, reducing the risk that adulterations go through undetected.

Confidentiality is the hardest of all because, even with the most complex algorithms, the decryption is a matter of time. My recommendation is to transmit only partial information that can be reconstructed only with an intimate knowledge of the solution.

Authentication is a more severe issue so it should use complex challenges. If you have to encrypt a password, send a clue to the counterpart, who will have to derive the encryption key from contextual data. It is not perfect but will at least reduce the risk of simple replay attacks. The idea is that, by the time they worked out what your current key is, you have already changed it.

Encryption does not guarantee integrity but it can help to protect contents. Multiple and variable keys will give a harder time to attackers to determine how to extract the sensitive information and alter it.

Availability, however, will remain a risk that should be assumed. If it can happen and is not acceptable, it probably means that the solution will have to be redesigned.

Now, if your RF link inherent encryption does not ensure the above, it is probably time to define a complementary strategy at application level.

By the way, what is IoT?

You cannot control a system's security if you don't define its scope. IoT is a mix of things that bring their own complexity and risks. IoT is an end-to-end system, that combines sensors and actuators, a local hub, a central server and an Internet access to monitor and control the far end, usually through a web site or a mobile application. This type of solution can give you the option of starting the central heating of your house on the way back from vacation or monitor a nuclear test without exposing your personal to radiation. Assume that an intruder breaks into the system and activates a feature in an uncontrolled manner: in the first case, you may burn gas in excess in your house while the latter you could well kill people and cause major damage to the environment. With great powers come great responsibilities.

IoT solutions must be secure by design without compromise and the level of control must depend on the criticity of the information. Let's assume that a hacker gets into the control of your central heating: what could happen if he gets read access to the temperature of the boiler? I suspect not much. Assume now that he can alter the reading: the boiler could stop working or, even worse, work non-stop and overheat, with the associated fire hazards that this could cause. Remember that the whole point of IoT is remote control and you probably won't have local human feedback to detect the failure.

Our first lesson is that the information should be segmented and made available on a need-to-know basis.

Why do we need 4 layers?

There is no general definition that imposes it but IoT designs usually follow this pattern: 1) local sensors and actuators, 2) a local hub, 3) a central server and 4) web access. These 4 layers have 3 main interfaces that need consideration, with their own associated risks. Web access threats are a recurrent subject and I don't claim to make a major contribution here, apart from highlighting that the impact goes well beyond a simple database this time.

The link between the local hub and the server will often be a proprietary protocol, as it is internal to the system. Its security will probably be under-evaluated for being hidden from the external world. The Stuxnet virus should be a loud reminder that systems are never intrinsically safe and that security-by-obfuscation has long been obsolete. What can we do to protect it? First, make sure that all actions controlled at this level are reversible: in the case of the central heating control, allow the ambient temperature to vary between 10 and 30 degrees Celcius and let the thermostat take care internally of the control of the boiler. This way, your hacker may increase your bill at the end of the month but the boiler's internal regulation and your house will be safe. We don't completely avoid the risk but we mitigate it (reduce the impact). Second, define patterns for fault detection: if the average outside temperature is 20 degrees Celcius, you can probably ignore requests to switch on the heating. Third, challenge your counterpart with random queries on a regular basis: a hacker may find the answer to a given challenge but will have a harder job to control your system permanently.

The local loop between the sensors/actuators and the local hub will probably be the weakest point in the chain because it will (erroneously) be considered safe: hackers would need to break in physically to interact with it. This false sense of safety can open doors to a variety of hacks: it is clear that a guy on the other side of the planet will have a hard time breaking into your ZigBee network but there are other ways to do it - and another audience. Local loops are traditionally designed to give close and accurate control over the system and can therefore cause higher level of damage.

Regarding physical connections, there are 2 main classes: wired and wireless. Wireless networks are easier to install but restrict the usability in terms of concurrent access (availability) and privacy (confidentiality). It is not necessarily a major restriction but has to be evaluated on a case-by-case basis.

Outlook

IoT is a new paradigm and the design requires a minimum of attention. The rules are not specially new but take a new light for some of the actors.

First, understand that the pillars of application security may not be equally important: in the case of the remote control of a central heating, confidentiality may not be as critical as authentication. In the case of a missile, geolocation may be as important as control. It will have to be evaluated for each project and information item.

Second, segment the types of information and define clearly what item needs to be handled within each scope. Our firmware applications handle global and local variables, or public and private methods. Likewise, our IoT should handle information within the sensor/actuator, within the local loop (between the sensor/actuator and the local hub), up to the server or up to the web application.

Third, evaluate the security requirements for each layer: we may find that the connection between the local hub and the actuator can be a simple 12V/1A control line but it will have to be checked. If encryption is required, check the required complexity and volatility of the keys: it can affect the complexity of the sensor or actuator and the microcontroller choice.

Fourth, scalability will be a decision criterion. If you design a new system, make sure that you offer flexible features. If your solution is initially designed for a house, make sure it can support a complete, multi-storey building. But whatever you do, make sure that security risks remain under control.

Finally, take some time to study other people's errors: there are some sites like SANS or OWASP that specialize in best practices and can help to reduce the risks. It can be a great complement to our own experience.

PMP in a small business

After spending 15 years in the electronics industry, my family pushed me out of my native country, and comfort zone at the same time: I had to reinvent myself in the software industry and project management. It has been a very interesting experience all in all. Nearly 4 years ago, I changed job and joined a small, local electronics manufacturer, thinking that I would be back to my first love, i.e. electronics design. However, the ongoing projects led me on another path and made me discover a new professional world.

Small Company Dynamics

Before this experience, I had worked only in big companies, the smallest having about 1000 employees, with separate, specialized departments. In my current company, we have more needs than people, a fairly frequent situation in small organizations. This increases the level of responsibility and leads to more complex, global assignments. The project leader has a greater level of control over the projects and has to be expert in several fields, as he is also often involved in the actual work. One structure is not intrinsically better than the other: as people say here, you have to choose between being a "rat's head" or a "lion's tail". Projects tend to be of smaller scale, with a more targeted scope. This smaller level of investment also gives a chance to bounce back when opportunities arise, as long as the necessary resources are available.

On the other hand, there are different issues that should be taken into account. First of all, they tend to focus primarily on development, with some level of testing. Given the low level of bureaucracy, corrections are executed in fast iterations but it may take several cycles to fix the application. Also, the actual level of expertise may vary significantly from company to company.

Relevance of Project Management

Project management is arguably required in all sizes of organizations: customers are rarely a single person and providers often count with more than one resource. If the project is billed by the hour, the provider is treated as a time-limited resource and it is up to the customer to manage the tasks. However, if the project is negotiated for a fixed price, both must manage their own projects, with somewhat conflictual priorities: the customer wants a tailored result while the provider tries to finish as soon as possible with fixed requirements. Having a common set of concepts and vocabulary can therefore be an asset. This is where a Project Management training or certification comes into play. My current personal aim is PMP.

A certification is not necessarily a must: a number of organizations offer trainings based on a book called the PMBOK (Project Management Book Of Knowledge, published by the Project Management Institute or PMI). First of all, it is a very generic book that can apply to virtually any business (software, electronics, civil engineering, manufacturing, financial institutions, etc.) This universal language can help to establish the necessary processes to plan, execute and control all sorts of projects, even when mixing technologies. Second, it is a repository of generally accepted good practices, that apply to most projects most of the time: you will generally find that most rules apply explicitly or implicitly. Third, the rules are recommendations: no one will force you to implement everything but you're bound to find that part of the processes can easily be applied and improve the operation of your organization. The point is to define the sweet spot between inefficiency due to lack of control and to excessive overhead. The definition of the project management rules will therefore be a long-term, evolutive project on its own.

Hierarchy of Management Layers

The PMBOK will give you an extensive summary of the processes to execute but will not define how they should be conducted, as this belongs to the underlying methodology layer. If your company is already struggling with the execution and the methodology, why bother with an additional layer of complexity?

The question is actually rhetoric, because you will realize that you already perform part of the processes, in a more or less organized way. You don't necessarily want to generate a lot of documentation about Acquisition if you don't plan to buy more than a USB cable or a bag of nails but you implicitly Plan and Manage Stakeholders Relationships every time you meet with your customers and try to make sure you meet their expectations... or you manage their expectations to meet the reasonably achievable scope of the project, as a function of time and cost. The PMP training is therefore based on common sense.

Risks and Obstacles

The first risk is buy-in: In PMI's terms, you need to convince a sponsor in the higher levels of management, ideally C-level. Without strong support, you will likely face strong opposition and will not reach optimum results. A second risk would be an excessive level of control, which could easily bring the whole project to a stop: the main aim of any organization is to execute on their strategic projects and management should account only for a marginal cost, ideally financing itself with the savings that it generates.

Another risk is the Anna Karenina's Principle: happy projects are all alike but unhappy projects fail all in their own ways. It is not directly related to the implementation of management but a side-effect of an inadequate one. It sometimes comes from the belief that generic good practices do not take into account the specific needs of a given project: as mentioned earlier, the PMBOK applies to most projects most of the times so each implementation has to be tailored to fit the exact needs to be successful.

Bottom Line

Implementing a project management process is generally beneficial and has to be a project on its own inside the organization. It must follow the same processes as the other projects, taking scope, cost and time into account, and must come with success and exit criteria. However, keep in mind that that these are tools and must remain a support for the business: treating these tools as a direct target would be the wrong scope.