Renaissance

At times we get that sinking feeling that the project is not going the right way and there is need to have course correction. Some projects meander in such a way there is no course correction but to change the destination.

Steve McConnel gives the three fundamental approach to rescue a project that is going wayward.

1. Cut the size of software so that you can build it with in the time and effort planned
2. Increase the process productivity by following on short term improvements.
3. Face the fact that the software will not be ready on time, slip the schedule and proceed with the damage control, possibly including canceling of the project.

Combining the above three we get rule to rescue the doomed project.

Drop a few features, increase productivity and slip the schedule as needed.

.

“I love deadlines. I like the whooshing sound they make as they fly by.”

Douglas Adams, English humorist and science fiction novelist, perhaps
best known for his novel “The Hitch hiker’s Guide to the Galaxy”.

You either get bogged down by the impending deadlines or you learn to enjoy them. Now that I am trying to enjoy the dooming deadline as it approaches me. I don’t know if it will make whooshing sound as it passes me.

As some one said, Schedules are made so that you can miss them. Making a schedule has been a mixed bag for me till now. Spot on if the I am in total control (read individual work) wayward for a group. There is more to programming.

Here I list the schedule made for WinWord at Microsoft for amusement purpose. The chart is adapted from Steve’s Rapid Development book.

Some lessons from WinWord schedule. Aggressive schedule prevented accurate planning. A 60-80 percentage was wishful thinking. The constant part of the schedule was firefighting.

This project experienced extremely high turnover. It had four development leads in 5 years, including two who quit the project because of schedule pressure and one who quit because of medical reason.

Because of schedule pressure, developers shortchanges their feature implementations, declaring them to be done even though they had low quality and in fact were incomplete. The result was that WinWord spent 12 months in Stabilization a period that had been expected to be take only 3 months!

.

.

Making a schedule for the software project is a painful activity. It is amplified more if you do not know what you are doing. Software schedule can be at most an estimation in the early phase of the project. The real schedule details will be available only once the project is underway and things become more clear.

I believe that the developers are one who can contribute to a meaningful schedule, the managers the least. The manager do not have enough information to arrive at the schedule estimate, but most of the time, they tend to push the deadline on the developer. The developers who do not stand up this, tend to agree to the bad schedule and end up screwing their life and work.

There fore developers should vote against a idiotic schedule when they encounter one. They should give or help to make a meaningful schedule. The lead and developers should meet more often to see if they are on track. If not they should take corrective action to get the project schedule on track.

Developers should only consume what take what they can chew, if the deadline is fixed drop the features, if features are fixed then extend the deadline. It is impossible to have maximum features in a very limited time span.

.

.

Working as a software developer is no fun. One is constantly bombarded with problems that is out side the technical boundary. One unnecessarily spends time on problems other than the one is supposed to solve.

There are plenty of things that kills the developers morale. The management needs to avoid them if they are in real need of getting things done.

• Asking developers to do meaningless task
• Having phony deadlines for the projects
• Having long and meaningless meetings
• Not recognizing the work
• Providing no motivation
• Petty office politics
• Not having trust on the team
• Spoiling the team structure
• Not giving developers responsibilities
• Ignoring them

.

.

Why is that most of the Indian engineers (read software) with five or more years of experience want to lead a team and are not interested to be an individual contributor (IC) ? Why is that being an IC such a sin? What is that it makes team lead position more attractive than IC ? Is it money , ego or some thing else ?

I am trying to get an answer to this riddle, if you have any clues or answer please leave a comment.

.

 .

I am all thinking what would have happened at Apple when iPhone as a product was conceived? 

What kind of tussle would have occurred between engineers and marketers/visionaries regarding the feasibility of the product? You want ipod, phone and internet to cram into one tiny piece of marvel, impossible? I am sure there would be some kind of arguments that would have popped up at the drawing board. 

• Is it okay for apple to make a phone?
• Can it survive the market dominated by Nokia?
• Can the low power expectations are meet?
• Will the multi touch screen survive the usage?
• How will test this complex thing?
• How can things be made simple? Is it possible?

And hopefully a zillion other questions, I am sure. I wish I could know how they try to overcome these and deliver the product that is revolutionary.

The tussle between the engineers and marketing team is present in all companies.

If the debate is open and both the parties listen then we can have wonderful product like iPhone, else that brilliant idea will meet its death in the drawing board.

.

A software project success depends on many factors. Steve McConnel interprets them in relation to Maslow’s human need. The project should satisfy these heirarchial needs if it need to excel. Most of the time the team members have no clue on were the project is heading and this gives rise to rumour and sick feeling spreads faster than common cold.

5. Self Actualization - Ongoing professional development

4. Self Esteem - Feeling productive, belief in project’s importance, important contribution, recognition

3. Belongingness and Love - Healthy team dynamics, trust

2. Saftey needs - Meeting personal promises for schedule and functionality

1. Survival needs - Project not canceled, team not fired, adequate physical working conditions and so on….