What do Embedded Software Engineers Really Do?

A great post by Colin Walls.

What *** really *** resonated with me is what he says about maintenance, “efficient” (quote marks are Collin's) code, keeping it simple, writing code that is readable by non-expert humans, commenting (and then commenting some more).

“Efficient” code is another wolf in a sheep's clothing.

Orange Rubber Boots in Action

How to behave in a disaster. Lessons from BP for IT

Six Action Shoes & Software Process

Grey Sneakers. Informal. Lounging - going nowhere. Creative juices. Lateral thinking. (Use the Six Thinking Hats: White, green, red, yellow, black, &  blue).

Brown Brogues. Path finding through unfamiliar terrain. Scouting alternate routes. Prototyping. Decide on the way ahead.

Black Dress Shoes. (what we normally refer to as formals) Draw up a formal plan. Instrument it. Execute.

Purple Riding Boots. Use of formal authority. Monitor, assess, provide feedback. Take corrective action.

Pink Slippers. The human touch. Team building activities. Diffuse inter-personal tensions.

Orange Rubber Boots. For emergencies. The customer will be in trouble. Locate the defect. Make the work around. Pull all-nighter. Then Analyse cause (Grey sneakers and/or Brown Brogues). Take corrective action (Black dress shoe, or Purple Riding boots). Note: If you wear Rubber Boots for too long, your feet will smell. So will your process. This is an anti-pattern.

Wolves In Sheeps' Clothing

1. Sheep's Clothing - Customer Orientation. Wolf - scheduling not based on reality; under priced.
2. Sheep's Clothing - Quality Certification. Wolf - Lip service to quality.

3. Sheep's Clothing - Quality Department. Wolf - Quality is no longer the responsibilty of developers.

4. Sheep's Clothing - Productivity. Wolf - Unmaintainable code; "indispensable" coders.
5. Sheep's Clothing - Heroic Efforts. Wolf - Create emergencies; no learning; "indispensable people;

Certfication & Quality

Todays Swaminomics talks of how the award for Corporate Social Responsibilty does not correlate with actual behaviour towards society.Both BP and Goldman Sachs had received it. Recent damage caused by these companies show that social responsibilty was not a value. It was mere PR glitter.

Quality certifications, like the award for Corporate Social Responsibilty, can be obtained with the required "paper work" and some amount of play acting. It does not mean that Quality is a prime value for the company. In most cases it is obtained for adding glitter to marketing. And all that glitters is not gold.

Quality has to be a basic value. A value expressed not through certfications, or  on the web-site, or in quality manuals. It has to be the gating criteria for all product decisions. It has to be expressed through action. Actions speak louder than words.

Deepwater Horizon Oil Rig, "Bhoot Banglas" & Wolves in Sheep's Clothing

Deepwater Horizon, the oil rig in the Gulf of Mexico that blew up was a "Bhoot Bangla". 

This Bhoot Bangla was not created overnight. There were a series of broken windows that no one attended to.

(see more on this)

Why did no one attend to the broken windows? I quote from the article: "... drilling priorities taking precedence over planned maintenance". That was the wolf in sheep's clothing. And there was no process shepherd.

(PS: I apologize for the mixed metaphors:-)

White Paper on Software Quality

Good article on sustainable software quality improvement.

Eternal Vigilance

Eternal Vigilance is the Price of Liberty - Thomas Jefferson.

Without vigilant civil society, civil liberties will get eroded.

So too is eternal vigilance the price for Quality.

Quality needs shepherds to protect processes  from being slowly decimated by the wolves, most in sheep's clothing, lurking in the forests of software development.

Getting Ahead

Last Saturday Prof Ananth, Ditector IIT Madras, addressed the alumni in the NCR area.

During the talk the need for inculcating values came up. Prof Ananth narrated how during one of his interaction with some of his students he was told that there was nothing wrong with "cogging" (copying) as the objective was to get ahead! I suppose some "dudes" thought it "kewl" to tell the director that.

Would you want such a person as a colleague? What about as a researcher? How about for testing your mission-critical software? Or designing nuclear power plants?

Values are not learned in colleges, or in organizations. Display of wrong values needs examplary punishment.

Values are learned primarily at home and school. They are absorbed from the social environment and need correction at home.

And can a person who copies really "get ahead"? Like athletes taking performance enhancing drugs to get ahead, there are damaging, long term side-effects. The getting ahead is very transitory.

Expand Your Box

At acmet we used to build (and maintain) compilers. Compiler builders must know the strong and weak points about compilers for similar target MCUs. Sales of processors depend upon the tool support provided. It can be the deciding factor for choice of an MCU. That means compiler builders must be familiar with competing compilers and their target architectures. This task calls for experienced tool builders.

Tool builders must also be fully aware of the expectation of the users. They must be able to talk the application developers language. People who build a compiler for a DSP must have some understanding of DSP techniques. It is familiarity with the application domain that can lead to targetted customization, to relevant pragmas, and appropriate libraries.

I came to this realization a bit too late:-(

Do not become a pin factory worker. Follow Seth Godin's advice.

A Fun Place to Work

So what is fun at the work place?

Here are some things that I consider fun at the work place:
 * Making commitments - and meeting them.
 * Finding preventive measures for defects.
 * Helping colleagues better their knowledge.
 * Writing software that is not hard to understand - or at least not harder than necessary.
 * Writing the tests to prove that the code does what it is meant to do - and not do.
 * Taking equal pleasure in others fun.

Here are some things that I definitely do not think as fun at the work place:
 * Practical jokes.
 * Jokes on other people's physical characteristics, or mannerisms. This I find particularly detestable. Mercifully I have never been in such a workplace.
 * Disturbing others - loud talk, raucous laughter ...
 * Offensive language

The second list is a partial list of  ill-mannered behaviour. An ill-mannered person does not show consideration for another's feelings. An ill-mannered person lacks empathy. An ill-mannered person is about "me". Do you want such "funny" persons at your work place? Should not the selection and retention process, select and retain persons with a sense of fun suited to the work place? Should not the process ensure that "funny" persons are rejected, or promptly ejected?

To Err is Human ...

To Err is Human; to Forgive - Divine

But to Forget is Stupid!

Create, or modify software, and defects will be introduced. Penalize individuals for it and defects will be be swept under the carpet. Team cohesiveness will disappear. So forgive - and forget - the person.

But to forget, what led to the defect being introduced. To forget to learn from it. To forget to put preventive practices in place. That would be stupid!

Do the hansei.

Optimization - Seth Godin & Geoffrey Moore

Seth Godin in a recent post advises against spending time on optimizing something that is doing well enough. Rather it is better, after a certain stage to spend time on creation.

Good advice for individuals. And for businesses too. I recommend one should read Dealing with Darwin: How Great Companies Innovate at Every Phase of Their Evolution for a clearer - and longer - exposition.

Geoffrey Moore defines the state of a company along two axes - Core, and Context. Core represents activities/products that provide differentiation from the competition. Context is everything else that a business does to stay in the game. .

A product progresses from being high-Core + low-Context, to high-Core + high-Context, to low-Core + high-Context, and finally to low-Core + low-Context.

It is in the later two states that optimization - including outsourcing - come into play. It is also during the third stage that it becomes important, to use Geoffrey's words, to "extract from Context and allocate to Core".

I think Seth's advice fits in with "extract from Context and allocate to Core". And that optimization can only take the business so far.

Here is a  a video of Geoffrey Moore explaining these concepts to an audience of software developers.

Broken Windows & Bhoot Banglas

Ever come across tests that are no longer in sync with the specifications/requirements? Code that has been modified but the specification/ requirements document has not? Changes made but no comments in the version control log? No version control? Defect fixes lead to side-effects destabilzing the code?

If you have, then you have come across a bhoot bangla (a broken-down haunted house).

Bhoot Banglas start with broken windows. Code that is not documented is a broken window. A requirement that cannot be traced to implementation and a test, is a broken window. A defects that is not caught in review is a broken window. A Magic numbers is a broken window (and replacing 1 by defining it as ONE does not make it any less magical). Unrestrained use of globals is a broken window. Unrestrained coupling is a broken window. A broken test is a broken window.

Look actively for broken windows. Fix broken windows as soon as they are noticed. Do not wait for a big clean-up phase. Do your good deed for the day.

The book Broken Windows, Broken Business: How the Smallest Remedies Reap the Biggest Rewards has great relevance to software development and maintenance. As it says in the introduction a "broken window" is "any small indication that something is amiss and not being repaired". It leads to much larger problems.

Broken windows result in Bhoot Banglas. And Bhoot Banglas result in broken software people.

Quality Control Feedback Loop

In yesterday's post I mentioned Quality Control (QC) is finding the defect in the process, or its implementation, and then fixing it.

Inadequate training would, in many cases, be a major contributing factor. How much time is spent on training? Is the training process suited to the people selected by the selection process? Are people evaluated on evidence of process practices?

Yes, quality needs the commitment of the CEO. Commitment both by word and deed.

As the tag-line of this blog says: Quality is like six-pack abs - hard to get; hard to maintain.

QA or QC?

We send our product for testing before shipping. Some tests fail. We fix the defects and send it again for testing. This time it passes.

What did we do - QA or QC?

Neither.We fixed defects. Period.

Only the process that we used to make the product, can provide Assurance of Quality.

Defects reaching final testing indicates some flaw in the process, or in its implementation. We need to ask: Why was the defective code not caught in review? Why did unit testing not catch it? Were the specifications, clear & complete? ...

It is when we investigate the cause of the defects reaching final testing, and institute corrective measures, that the feedback loop is completed. There can be no control without feedback. Only then does Quality Control (QC) happen.

Excellence

"We are what we repeatedly do. Excellence is therefore not an act but a habit" - Aristotle

The above quote was in an email that I received.

I am sure that something was lost in translating from classical Greek to English.

Surely just repeatedly doing something out of habit will not improve us in whatever we are doing. If we are to improve in doing something, surely how we do it must change. Continuing to do something in a manner because it was always done so, would still have us hanging from trees.

It is the PDCA (Plan, Do, Check, Act) cycle - not just repeatedly Doing (the D part) - that will move us towards excellence.

Yes making the PDCA cycle a habit will lead to excllence.

Who is your Customer?

This is a question I frequently used to ask our new inductees. Invariably the answers gave one of the company's customer.

Whoever uses a team member's output is that team member's customer. If  the member has written a class, then any other member who uses that class is a customer. If the customer has problems in using the class it must be treated as a "customer" complaint, attended to promptly, and the root cause found and rectified. The customer is not to be lectured and told as to how he can change his code.

If the code is hard to understand, or not well documented, or with incomplete unit tests, then the customers (those who will review the code) are being treated badly.

Then there are people who will maintain the code long after you are gone; they too are your customers.

Growing and nurturing such an attitude is a defining part of team and company culture.

Kaizen: The Key To Japan's Competitive Success. (I have the international Edition of 1991.) On page 51 it has a sub topic, "The Next Process Is The Customer". Then on page 135, while describing cross functional management at Toyota - "The overriding goal is to never inconvenience downstream customers."

There is a lot that software companies can learn from Toyota.