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.
Subscribe to:
Posts (Atom)