Having known Paul Butcher as someone who was into software sales, it came as a pleasant surprise to see his new book on software debugging: "Debug It! Find, Repair and Prevent Bugs in Your Code". I finally got around to reading it last weekend. I was amazed by his depth of wisdom in software debugging. While most would say, "why debug, if you write code correctly?", software defects are an inevitable and unfortunate part of life. Recent evidence proves that on the average for every 8 lines of code a programmer writes, there is one defect. The defect rate does not vary much by how a expert a programmer is.
The book has a number of gems of wisdom on not only "how to fix" but also on "how not to fix" defects. Here is one of those from the book which most of us have have across at some time or the other:
int process_items(item* item_array, int array_size) {
int i;
/* For some reason array_size is off by one, so fix it up here */
array_size++;
for(i = 0; i <>
Process item_array[i]
}
}
A lot of times programmers find quick solutions to problems, and "make the bug go away", hopefully forever. Frequently not, but instead creating another defect in the process, somewhere else in the software. His recommendation of the need to always critically analyze the defect even after it is fixed is extremely relevant: "How did it ever work before?". Careful reflection, even at this stage can often provide clues and further insights not only to the defect that was fixed, but possibly finding other hidden defects too.
I also found his section on the need for automated testing very relevant in today's product development. Though some companies use that very effectively others do not invest in any automated testing. The author has also provided a good list of current popular software tools all the way from source control systems, bug tacking systems, to logging and testing tools and libraries.
Altogether the book is an easy read, with the author's flowing style. But like his recommendation on reflection after fixing a bug, the reader learns a lot more if he takes a break to reflect after every few pages he reads. Someone who was in the trade of developing software for a a few years, would readily identify with many of the gems in this book. This is a recommended read for anyone who works closely in the software industry, be it a developer, a tester or even a product manager.
Friday, July 10, 2009
Monday, May 25, 2009
Analysis of a failed Software Project
A real life project:
The project was to create an automated way of handling the back office work, with different interfaces and protocols to customers, data warehousing company, end users, hardware vendors, etc.
The project started with some discussion of schedules and features. The architect was bright. He could come out with innovative solutions to problems fast. Very inspiring and motivational to the team.
No one bothered to document anything, as everyone was “busy” and working day and night to meet the customer deliveries.Programmers were busy writing code, and then fixing it when the next set of customer requirements came. Everyone was busy "working". The architect worked the most, spending sleepless nights at the office.
Deadline after deadline slipped, and the project was slowly inching along. At the end of the year, a prototype with some features was available for integration. Neither complete nor exactly based on any specifications.
Then it came time to deploy the project with the first major customer. After technical meetings between the two companies, and initial tests, it was discovered that many of the customer message formats were incompatible with the system message formats. “So what, we can fix our side overnight to handle your message format” was the kind of mentality on the company side.
The message formats issue was fixed. But not having undergone any serious tests, other parts of the software started breaking. New bugs were reported everywhere.
Once real load started hitting the servers, it was observed that the response times were getting slower and slower. The system was crashing more often. An architecture review was conducted. It revealed many deficiencies in the architecture. No coding standards were neither available in the company nor were any followed by any developer.
After a few heated meetings in the months after that, the architect was let go. Some of the staff, complaining of long hours left. Some did not see the company going anywhere, since that was the one major project for the company.
What were the problems?
Inexperienced people. A lot of pressure was placed on the architect, who was the best of the pack. Though he did a great job, the work was far too much for one person. Most of the people did not have any real world project deployment experience.
Communication and Motivation. Though the higher management got along very well, team work stopped there. Company goals never made it to the trenches. Motivation was missing.
No Processes. In the haste to get things out fast, no one cared about defining a software development process. No clearly planned software requirements, schedules, testing, etc. Disciplined software development is the only way to produce software!
How about Risk management?
The company developed its own risk management practices, and paid a lot of attention to certain aspects of risks:
Risk of losing critical data – Backups were done and stored in different parts of the country at the end of every week.
Security risks – The premises were well secured with closed circuit security systems. Highly secure algorithms were used to transfer financial information, from system to system. Logistics of secure data was clearly planned. All sorts of precautions were taken to prevent hacking into the company systems.
Risks for hardware not being available. Various alternative plans were formulated to make sure the project is not affected, in case some of the hardware vendors did not cooperate to produce the customized hardware.
The company spent significantly on an external security consultants to point out flaws in the system.
However, management seemed to have forgotten the biggest risk: software development.
While this reads like a story, this scenario is repeated each day in countless organizations across the world. Software development risks are still not appreciated to this day by most organizations or management.
The project was to create an automated way of handling the back office work, with different interfaces and protocols to customers, data warehousing company, end users, hardware vendors, etc.
The project started with some discussion of schedules and features. The architect was bright. He could come out with innovative solutions to problems fast. Very inspiring and motivational to the team.
No one bothered to document anything, as everyone was “busy” and working day and night to meet the customer deliveries.Programmers were busy writing code, and then fixing it when the next set of customer requirements came. Everyone was busy "working". The architect worked the most, spending sleepless nights at the office.
Deadline after deadline slipped, and the project was slowly inching along. At the end of the year, a prototype with some features was available for integration. Neither complete nor exactly based on any specifications.
Then it came time to deploy the project with the first major customer. After technical meetings between the two companies, and initial tests, it was discovered that many of the customer message formats were incompatible with the system message formats. “So what, we can fix our side overnight to handle your message format” was the kind of mentality on the company side.
The message formats issue was fixed. But not having undergone any serious tests, other parts of the software started breaking. New bugs were reported everywhere.
Once real load started hitting the servers, it was observed that the response times were getting slower and slower. The system was crashing more often. An architecture review was conducted. It revealed many deficiencies in the architecture. No coding standards were neither available in the company nor were any followed by any developer.
After a few heated meetings in the months after that, the architect was let go. Some of the staff, complaining of long hours left. Some did not see the company going anywhere, since that was the one major project for the company.
What were the problems?
Inexperienced people. A lot of pressure was placed on the architect, who was the best of the pack. Though he did a great job, the work was far too much for one person. Most of the people did not have any real world project deployment experience.
Communication and Motivation. Though the higher management got along very well, team work stopped there. Company goals never made it to the trenches. Motivation was missing.
No Processes. In the haste to get things out fast, no one cared about defining a software development process. No clearly planned software requirements, schedules, testing, etc. Disciplined software development is the only way to produce software!
How about Risk management?
The company developed its own risk management practices, and paid a lot of attention to certain aspects of risks:
Risk of losing critical data – Backups were done and stored in different parts of the country at the end of every week.
Security risks – The premises were well secured with closed circuit security systems. Highly secure algorithms were used to transfer financial information, from system to system. Logistics of secure data was clearly planned. All sorts of precautions were taken to prevent hacking into the company systems.
Risks for hardware not being available. Various alternative plans were formulated to make sure the project is not affected, in case some of the hardware vendors did not cooperate to produce the customized hardware.
The company spent significantly on an external security consultants to point out flaws in the system.
However, management seemed to have forgotten the biggest risk: software development.
While this reads like a story, this scenario is repeated each day in countless organizations across the world. Software development risks are still not appreciated to this day by most organizations or management.
Tuesday, April 14, 2009
New Mantra for the Economy: Save and Invest
Save and invest..Is that the New Obama Mantra?
"We cannot rebuild this economy on the same pile of sand," he said, invoking a Biblical reference to Jesus' Sermon on the Mount. "We must build our house upon a rock. We must lay a new foundation for growth and prosperity a foundation that will move us from an era of borrow and spend to one where we save and invest, where we consume less at home and send more exports abroad."
Is this going to be a radical change from the consumerism the country has always preached and practiced? Would this be a sustainable model for future growth? Lets see.
http://news.yahoo.com/s/ap/20090414/ap_on_go_pr_wh/obama_economy
"We cannot rebuild this economy on the same pile of sand," he said, invoking a Biblical reference to Jesus' Sermon on the Mount. "We must build our house upon a rock. We must lay a new foundation for growth and prosperity a foundation that will move us from an era of borrow and spend to one where we save and invest, where we consume less at home and send more exports abroad."
Is this going to be a radical change from the consumerism the country has always preached and practiced? Would this be a sustainable model for future growth? Lets see.
http://news.yahoo.com/s/ap/20090414/ap_on_go_pr_wh/obama_economy
Thursday, January 8, 2009
Satyam: Where does Integrity Start From?
The events in Satyam Computer Services ( the IT outsourcing giant from India) have shocked all of us. Satyam in Sanskrit ironically means "truth". We all react in our own way. A lot of us react to it as if it is part of the larger problem of corporate corruption. Some call for stricter accounting rules, regulations and checks.
My belief is honesty and integrity should start in small things with each of us. How many of us can claim to have been honest all the time, even in simple things where it is easier to be honest Here is a story from a coworker friend:
"I went to an Arts and Handicrafts shop at commercial street in Bangalore to buy some souvenirs from India. When I asked for the bill, the guy tells me: If you need a bill, then you will have to pay Rs 11 more. I said, I was willing to pay the extra money. He immediately asked whether I was buying for a company. I said no it is a personal shopping. In sheer disbelief he asked me why I wanted to pay more. I said I would like to encourage taxes being paid properly. He looked at me for a few seconds before writing me the bill. This was not my first experience and I am sure most of us in India deal with these types of transactions "normally".
-
Isn't leadership about authenticity and integrity? Should it not start with each one of us ? Or can we get around by enacting more rules and regulations to fix the problems?
My belief is honesty and integrity should start in small things with each of us. How many of us can claim to have been honest all the time, even in simple things where it is easier to be honest Here is a story from a coworker friend:
"I went to an Arts and Handicrafts shop at commercial street in Bangalore to buy some souvenirs from India. When I asked for the bill, the guy tells me: If you need a bill, then you will have to pay Rs 11 more. I said, I was willing to pay the extra money. He immediately asked whether I was buying for a company. I said no it is a personal shopping. In sheer disbelief he asked me why I wanted to pay more. I said I would like to encourage taxes being paid properly. He looked at me for a few seconds before writing me the bill. This was not my first experience and I am sure most of us in India deal with these types of transactions "normally".
-
Isn't leadership about authenticity and integrity? Should it not start with each one of us ? Or can we get around by enacting more rules and regulations to fix the problems?
Subscribe to:
Posts (Atom)