Bridges and Space Shuttle

Recently, on Joel on Software forum a thread discussed NASA decision not to fly the shuttle across an year change date. Being in space between the last day of the year and the first day of the new year is considered dangerous. This rose a debate on Space Shutte software quality.

An interesting article about the Shuttle software developement group can be find here.
The development group produces software with almost no bugs, they own a world record on this. The secret is a very, very detailed design upfront, for implementations an changes as well.

What is important about this methodology, in my opinion, is the fact that software design and coding start to look like the rest of engineering.
What's the difference between designing a bridge an a sw system? Both are complex and have a large number of interacting parts. The relations among these parts may be overly complex for both parties. The building process is not trivial and requires a large amount of organizational effort. Both may require trimming an maintenance, albeit what causes the need for maintenance to rise is different.

So, how comes that a bridge hardly fails but software is often buggish and a software project is less likely to hit the target?

The answer may come from seeing the Space Shuttle software group at work, they...

treat software like ordinary engineering.

There are comon engineering practices that are widely accepted, but not in software, that ensure the quality of work.

A very detailed design upfront is almost mandatory. Each real-world, industry produced, object has detailed sketches preserved in someone's drawer. Those sketches can be given to a technologist an be undestood. More, they fully describe the object. If required, technical relations come with them, stating all the production processes and calculations needed.

In almost every field of engineering there are rules or regulations to comply with. These, in engineering, are not thought as thethers. On the contrary, they are seen as the right way to do things. Design and build according to the rules and everything will work. You have no need to re-invent the wheel each time.

There are a lot of widely accepted standards that reduce compatibility problems to the minimum. There are no bolts on the market but those that comply to an accepted stadard. There are no car wheels availabe but those who fit codified sizes and performances.

None of the points above is common in software development. The cause is likely twofold.
Software development is young, modern engineering goes back to the 18th century, some time is required to let established rules and procedures emerge.
Software developers are young, and many of them think to software as way of life instead of an artifact like the others. This means that they tend to be a bit too much creative and suffer from any kind of constraint.

The last point would take us very far, and I'm not going to cover it more extensively in this post.
My point, anyway is the following:

whe should devote more efforts to software standardization and design, because software is more an art than a science, but it has been so for too long to find its way in modern engineering.

YouTube acquired....

I've heard about YouTube acquisition by Google.
What's noticeable in it?
It's the fact that Google is starting to spread its cash reserves to shop for internet businesses. This means that the "Google, the innovator" era is likely approaching to an end.
There is no complaint in it, it's a sign of the coming company maturity stage. In this phase the company reaches full maturity and becomes a serious competitor (for MS and IBM).

1001 Books You Must Read Before You Die

I stumbled upon the now famous list 1001 Books You Must Read Before You Die.
Two issues rose immediatly.

1) Oh, gosh, they are all fiction, literature; no essays or technical papers or scientific ones!

2) It's amazing to observe how Internet can comprise each and every style. Enumeration, in fact, was a strong point for Christian Scolastic philosophy in the middle ages.

Internet Explorer 7 is here.

At last is here. I downloaded the betas in the first few minutes they where available because Microsoft's new browsers are events.
Now that's officially here I say "at last!".

At last we can restart a browser war!

I've seen, in the latest years, Firefox adepts rejoyce while IE kept losing market shares. Even Opera's passionate users enjoyed stinging IE common users.

It looks like browsers are a sort of religious choice. Is there any need to underline how absurd is this?

P.S. I do not like Firefox but I used Opera a lot before IE7 beta. This IE version seems really better than competitors, albeit resources hungry as usual.

ISV need sales!

Today I suggest you a visit to
http://www.isvprime.com/

Hal Carrol's site is a valuable resource for techies who startup a mISV. In my experience I've never seen such an easy and straightforward lesson on how software sales work. Download the pdf book and read it, there is much to learn in it.

Painless Scheduling? with Poldina you can!

Scheduling is one of the most common activities that take place within a software company. Each one of us, being a developer, a consultant or a manager, faced it.
Poldina, too, studied the subject deeply and managed to craft a small theory that can be of help.

When the need to manage more than a few people and more than very simple projects rises, the Perfectly Educated Manager bores a number of holes in everyone’s patience and comes out with something like this:

Now we have complex activities broken down to simpler. For each activity duration and and owner are established. Precedence among activities is accurately defined. A number of milestones are set according to contracts.
Now everything can be kept under control and the Perfectly Educated Manager thinks that his job is done.

Cool, but useless, harmful and plainly wrong!

It is useless because each detailed Gantt is doomed to be subverted from basement by actual activities and probably only the final milestone will be respected. Given this probably it was worth only defining the milestones.
It is useless because it does not help the manager’s daily job, i.e. developers do not update the Gantt as tasks are over (the worst is when a group of people assigned to a task must asses the task overall percentage of completion…).

It is harmful because the solid, rigid, implicit task schedule work perfectly as long as they are respected to the minute. Each lead or lag too easily ends up in witch hunt to the faulty person who spoiled the harmony of the schedule. No need to describe the effects on people’s morale.
Maybe the Perfectly Educated Manager resolved not to be so stiff, but the fact itself of seeing each task changed in solid colored bar on the screen or on paper, stiffs his perception of the importance of schedules.
People can work themselves to death to meet an important deadline, and nobody takes lightly the decision to postpone a deadline. People can’t do this every few days to meet all the implicit intermediate milestones.

It is plainly wrong because, as everyone of us knows very well, the tasks do not occupy a solid period of time and precedence may be not so rigid. More, often there’s no time for the iterations required to fine tune a complex system or to cope with specification changes.

Paraphrasing a German leader of the beginning of the 20th century, “Gantts are only a piece of paper.”


So, Poldina had the occasion to carve out a quick guide to project planning and scheduling from her past experience. Let’s start from the egg.

First of all, have clear the goals and the final milestones. Often these are fixed by contracts. Then write down the skill set you’ll likely need. Try to find people who are interchangeable the most. I know that they’re more expensive than a bunch of chicken who are able to do one thing (i.e. one programming tool, one database etc.) but the right people, when glued together, can be incredibly productive and, sometimes, reduce your project’s duration to a point where there’s no need for a true schedule (this could solve the problem in such an elegant way…ah!).
Make sure also that specifications are written in a way that is adequate to your people. Specs will never be foolproof, nor they’ll contain all the information that the people working on the project will need. So they must contain the key information that are required to do the job or to figure it out, and this depends on the history and the culture of your people.

Now let’s face the duty of breaking down a large job in small tasks, this must be done because that’s the way the human brain analyzes problems.
Ok, a task does not occupy a solid period of time (if it is of any complexity of course, cooking hard-boiled eggs definitely do occupy a solid period of time…). The task related workload, in real life, is something like this:

It starts with a nose, usually when the task is informally discussed before a cup of coffee during breaks and lunches or some research is made from a general perspective. Then it rises quickly to a full or almost full occupation, then it slows down with a tail and may have some late bumps. While the bumps may represent late interventions to correct a bug or so, the tail is the most important part of the job. It is the period when the bulk of the effort lays on the back. It is at this point that dots on i’s and dashes on t’s are put and make an adequate job a great job to be proud of.
The area under the curve represents the total amount of work done. The height of the curve for a given point in time represents the person workload in that moment. No need to say that the solid block of time is the worst approximation possible of reality.

Given this, what is the graph that helps you the most to control the project and manage the workforce? In Poldina’s and mine experience is the following.

This graph has people on the y axis and time on the x axis, albeit the orientation is not the usual one. Unlike the Gantt, it focuses on people, who are the critical asset to manage. For each project member, there’s a bar that spans all the time the person is assigned to the project.
In this bar there are darker and lighter areas. Each dark area represents the period when the task almost fills up the time, each light area represents the superimposing of the trailing tail and the beginning nose and there is no fixed milestone between them. The individual tasks are a parameter written beside the line.
Precedence among tasks can still be drawn with an arrow from a light zone to a light zone.

It is clear that everyone can point his finger to a point in his/her bar and tell “I’m about here”. When everyone is done, just connect the dots and draw a line on the current date and, voilà, the project progress assessment is served.
In the perfect situation the two lines superimpose, otherwise all the points right from today mean a lead, all the points left mean a lag.

In this graph, operations like assigning a new task to a person or cutting it mean simply inserting or removing a segment of the line, with everything that shifts accordingly.
In the same way, the task completion level is not out of sight as the tasks are explicitly shown, anyway.
Punctual questions like, “what’s Joe doing now” or “Is this task done” can be easily answered. Individuals may update their situation by themselves simply moving the point of advancement and not entering weird information like “completion percentage”.
It is also useful to the individual member to have the situation available in a glance to manage their dependencies.

While the Perfectly Educated Manager is spitting in my face, I can assure you that this kind of representation has been very useful in the past. So, let me know what do you think about this.

P.S. To tell the truth I’m a Perfectly Educated Manager myself…

Let's start again...

I moved my blog to Blogspot.
I did this because, with the older platform managing user comments was terribly difficoult.
I moved all the long articles here.
The old blog can still be found here.
Thank you for your attention.