Aerospace Software

1539 Page Views in the last 30 Days

The heading says it all and I cannot stop smiling. Yeah! I know, I should be modest and all, but I just feel so happy about it. This blog is reaching out to many and that makes me real happy. I know there are hugely popular blogs with massive readership, and 1539 is a laughably tiny number, but then the number has jumped up considerably from what it was. That alone gives me a great deal of satisfaction.

But then numbers are just that - numbers. Many of you are obviously visiting my blog. What I am not sure is how useful this blog is.

I will be grateful if the vistors to this blog leave a comment on whether their visit was worth their while, or how this blog could be made better.

Flying the A380

I have been travelling.

My return flight from London Heathrow to Dubai will remain with me for life. I flew back on an A380!!!

My first major project as a Project Manager was a Level A Software Development for the A380. (Unfortunately, not huge publicity is given to the fact that AK Aerotek has worked on multiple A380 systems / subsystems - the Indian newspapers, on the other hand, go hyperbolic when it comes to one of the bigger competitors ... that's PR job for you! Hmmmm... I won't deny traces of envy here.)

In any case, flying on an A380 reminded me of the Project Manager who boldly volunteered to sit on the first trial of an aircraft designed by his team, when rest of the team turned pale at the idea. His logic: he was safe since he was sure that the aircraft which his team designed wouldn't even fly.

In my case, the flight took off smoothly and was uneventful. How I wished there was someone sitting next to me to whom I could boast! (The couple sitting next to me wouldn't even talk to each other!) A380 is noticeably quieter than all other airplanes I have flown in. I could actually enjoy the movies on the seven-hour flight (I still do not have a QC2/3). All our attempts (there were 3 of us) to get an upgrade in exchange of flight miles were a failure. The flight was apparently full.

Coming back to the A380 Level A project. It was a concurrent development and everything was developed from scratch (except the sensors). It was also a distributed system. Concurrent development has its own unique set of challanges that are not addressed in DO-178B; for that matter not many software development books address concurrent development. It is worth writing a book on this. That may be because not many projects are of this type. Most projects build on pre-existing products and most projects turn into a re-engineering project. Which is a pity from an engineer's point of view.

The First Successful Commercial Aircraft

Perhaps you already know this, perhaps you don't. I certainly didn't when I first read about it many years ago in a "non-aerospace" related book: The Fifth Discipline by Peter M. Senge. 

At the least, such information could be conversation starters (for nerds?). At best they remind you of the innovations that goes almost unnoticed, which we take for take for granted, but which established an industry that you and I are today part of.

Here's the blast from the past ... enjoy!

The Wright Brothers proved that powered flight was possible, but the McDonnell Douglas DC-3, introduced in 1935, ushered in the era of commercial air travel. The DC-3 was the first plane that supported itself economically as well as aerodynamically. During those intervening thirty years (a typical time period for incubating basic innovations), myriad experiments with commercial flight had failed. ...[E]arly planes were not reliable and cost effective on an appropriate scale.

The DC-3, for the first time, brought together five critical component technologies that formed a successful ensemble. They were: the variable-pitch propeller, retractable landing gear [the pilot of the 2nd B787 flight will understand this!], a type of light-weight molded body construction called "monocoque," radial air-cooled engine, and wing flaps. To succeed, the DC-3 needed all five; four was not enough. One year earlier, the Boeing 247 was introduced with all of them except wing flaps. Lacking wing flaps, Boeing's engineers found that the plane was unstable on take-off and landing and had to downsize the engine.

Management Principles

There are occasions where blogs don't make the cut. It is far easier to express views in a page that is more or less static. I have done just that.
I invite you to visit my pages on management here:

I am  bad manager
The leadership Hype
Evidence-based Management

Do let me know if the effort was worth it.

You may leave your comments agreeing or disagreeing in the pages too.

Software Induced Economic Collapse

I picked up this interesting rant from Jack Ganssle's Newsletter The Embedded Muse 171:

"The software community has learned that a disciplined development process yields better code:
fewer bugs. Yet very few of us employ a rigid process. For instance,
we know from countless studies that keeping functions to a single page
reduces defects. How many of us enforce a short-functions requirement?
Code testing is a notoriously ineffective way to uncover bugs. How
many of us couple effective tests with code coverage checks or
inspections?"

Here's why DO-178B and equivalent standards are so important. These standards enforce disciplined development. The only effective testing mechanism is testing requirements - not code. In fact,  the very idea of testing code without reference to a requirement is ridiculous. Robustness testing is another good testing practice.

Despite knowing the price one has to pay for indisciplined software development, why isn't a standard being forced? I can see two reasons: a) Greed - Disciplined development costs money; and b) Software Engineers like to see themselves as free birds. They are like painters. Don't tie us down, our creativity will suffer.

I think the software world - not just the embedded world - is waiting for a disaster to strike.

Here's a thought experiment.

This year 2010. April 1st. The financial world is limping back to normalcy after seeing two years of financial turmoil. Japan has just started trading. Unknown to the traders a software bug is eating its way through the database. Suddenly, the traders stop on their track. The giant boards displaying the violently fluctuating prices is now displaying only zeros. At another end of the Tokyo city, the bankers are tearing their hair out. All accounts are showing zero balance. Overnight the world financial system has come to a stand still. The world as we knew has disappeared. There are riots on the streets. People have lost all their savings. People who had cash in their homes are protecting it with guns. A bug that could have been easily detected had a requirement based testing been carried out has wiped away centuries of development. This was not caused by a software virus. It was caused by a incorrect code in a popular software that was used world-wide. The software unfortunately did not follow the simple principles of partitioning. The tester could have caught it but then there were no proper requirements. Even without proper requirements, robustness tests might have caught the anomaly, but there was no rigour introduced in the development and testing. The G-20 summit is now mulling over how to enforce discipline in software development.

An unlikely scenario? Hmmm... Think again.

It is time the software world gets together and adopt a de-facto industry-wide standard on the lines of DO-178B or CENELEC. Let the next economic disaster not be software induced.

Have you subscribed The Embedded Bridge Newsletter Yet?

No?

Then you are missing out on something!

Go here and subscribe immediately.

I have and Ithink the newsletter will add to your knowledge in ways you have not thought possible. 

Job Hopping During Times Of Recession

Yesterday, in one of the news channel, there was a dooms day prediction. Nothing to do with black holes and the CERN. This economist - I could not catch his name - indicated that the slow down will continue through 2008, remain in 2009 and the first few months of 2010.

So what does that do to the job market?

I am very aware that this blog will be read by people who have tendered their resignations and are looking to greener pastures. I am sure the reasons behind these reservations are justified.

Recession or no recession, I am of the opinion that unless the following reasons apply, no resignation is justified:
a) If the next company offers a professional growth that is incomparable.
b) If there are personal reasons totally out of control.
c) If the present job was a wrong choice in the first place. It is easy to tackle point (c). This is also very obvious. And a change in this case is a change of career path. The surest sign of this distress is unhappiness. You are unhappy with yourself doing something that you do not like.

Personal reasons totally out of control. Hmmm… This is tricky. Most of us would say that my personal problems are beyond control and that no one else understands. This also applies to the younger lot. I am sure that is true, but there is always a way out. As one grows in professional life there will be numerous occasions where personal problems will threaten to derail you. But at that period in time since the stake of leave a company is much higher you will not resign, I am sure. Rather you will find a way around. Well, why not use the same logic now. At the time of your formative year, when you are picking up the tricks of the trade and just begun your career, isn’t it more important to stick around? If you are able to solve your personal and professional problem, you would have already mastered a very difficult art that will stand you in good stead in later years – the art of managing conflicts. Having said that, I do recognize that many of the personal problems are really beyond control. If someone is getting married to a man settled in US or Maldives, then obviously the woman (it is still a man-dominated society, unfortunately) moves.

Ok – now what is a professional growth that is incomparable. If a project manager has the opportunity to become the head of a global outfit, then that may be termed as incomparable. Or if an engineer is offered the chance to become in charge of an UN project in Africa, then that is an incomparable professional growth (though many would disagree with this example of professional growth – UN work in Africa?? - but as I said these are my personal views.) Note that I am not talking of mere change of designation. If a Sr SW Engr is called Technical Lead in some other company (but doing similar job) with an apparent increase in salary (no one gives a 30% increase in hike – it is compensated within a year), that is not called an incomparable growth opportunity.

That brings me to yet another interesting aspect. What about foreign assignment? Isn’t that an incomparable growth opportunity? I not so sure here. Instinctively I feel it should be considered as an opportunity, but incomparable? Nah! Growth opportunity? Again no. Just an opportunity to see the world. But is it a reason for resigning from a job that has otherwise provided you with all other aspects that satisfies you? I am not so sure.

In any case, a person who resigns does not take into account that there are many aspects to his/her growth. The mentor who taught him/her the tricks of the trade, the friends who helped him/her out when he/she got stuck with a problem, the friends who went for a coffee with him/her when he/she was stressed, the subordinates who have encouraged him/her to look beyond his/her own work. How does he/she repay all this? By resigning? That is like saying, my use for you all is over … I would like to move on. So unless there are compelling reasons for leaving a company and as long your workplace provides a meaningful workplace, as long as you continue learning, as long as you continue laughing together, I do not think one should leave.

Every time I learn of a resignation, I feel sad. Now you know why. 

Recession or no recession. 

Solving software problems by telling a story

There are tomes out there on how to solve problems, on creative ways of solving problems and what have you. A search on Amazon for "problem solving techniques" reveal 8703 book results.  That's a lot. One of the best books I have read on solving problems is How to Solve It by G Polya.

In my experience there is only one way to solve problems. But before I give you my take on it, let me explain what I mean by problems.

These are those situations that block progress. If you are stuck with a piece of software bug that refuses to  go away, you may or may not have a problem. You will sooner or later solve it But if that bug is preventing integration of hardware and software, or if your embedded system is not communicating to the debugger because of a glitch in the software, or taking an entirely non-technical example, you are presented with two point of views, both having merit but the proponents are refusing to accept a compromise thereby holding up all progress, you have a problem.

And the only way to get round it is by talking. No I don't mean a negotiation between the two parties, if we consider the non-technical example given above. I shift the focus back to the technical world. The steps to be followed are:

1) Ask the engineer(s) to state the problem. If the engineer is a true engineer, this would be a terse description of the problem. In a line or two. This will not take you far. But it is a beginning.
2) Ask the engineers to tell you the story. Let them describe the problem as if s/he is the software and is experiencing what is happening. And I really mean a story. It should be elaborate and should start from a point before the problem point and should lead up to the problem point.
3) Ask questions so that the body of the story expands. It is likely that the story at point 2, above, will be very focused as the engineer is all focused on the problem at hand. More often than not the solution to the problem lies elsewhere; not in the focus of the engineer (otherwise the solution would have been found by now).
4) By now there would be many strands leading up to the problem point. Start with the most obvious strand and propose a modification to an upstream code that is likely to impact the behaviour of the problem. Be warned that the engineer will tell you it will not work. And s/he will give you a reason why it will not work. Insist on the implementation nevertheless.
5) You will be very lucky if the first solution works - though I have seen it working many times. Usually the engineer him/herself will come up with the solution as the story is told. Try out a few strands and you would most probably nail the problem.

I have seen this method working every time it is applied.

Started using iMac

Just wanted to record the date when I started using iMac. All excited! So many features to discover. Meanwhile feel free to advise.

Learning German - Free Resources

An established way to learn German (or for that matter any language) is to listen to the language as spoken in native tongue. Spoken language however, normally, comes at a cost. Either one stays in Germany or other German speaking countries, or buy expensive German Learning Courses. Among the German Learning Courses I found Rocket German (http://www.rocketlanguages.com/german/) the best for gaining initial confidence. It is also the least expensive of all other similar course.

However, after spending a considerable sum of money in buying books, CD's and German courses, I recently chanced upon this huge pool of free resources that is available on Internet. My earlier Google searches on German Language had not thrown up this site.

As it happens, Deutsche Welle has some fantastic German courses - all available for free. The material is very effectively designed (with the help of Goethe Institute in some cases) and can hold your interest for a long time - which helps when you are learning a foreign language. The language courses are graded and so one could pick up from the level one is comfortable with.

For example, the language course that goes by name of "Deutsche, warum nicht" is a set of four courses with increasing difficulty and contains upward of 1200 hours of recorded material. "Mission Berlin" is a gem of a language course. (There is also Mission Paris and Misja Krakow - for those who wish to learn (preliminary) French and Polish). The course is presented as a fast paced computer game. Check this out too.

And there is a lot more to explore.

Yet another method of learning German is to get a German sentence everyday by e-mail. You have the whole day to memorize the sentence. I find this very helpful. Check out http://www.german-flashcards.com. I found this site good to boost my vocabulary. The primary membership is free where you get to learn words and sentences on flashcards. Just spend 10 minutes a day to improve your vocabulary. Very effective. The premium membership helps you with the pronunciation too.

And finally my own home-grown method. I discovered this only last month when I was in Germany and browsing through a book shop. I wonder why it didn't strike me before. If you are into Tintin comics, then buy these comics in German (or in the language you are learning). You will learn the language faster and enjoy it all the more. By the way, Tintin is known as Tim und Struppi (= Snowy) in the German version.