Better Software - March 2008 - (Page 35)

“Knowing that customers are not happy with the delivered product can further add to the unhappiness of the developers. It is much more productive to follow the time-tested, scientific adage, ‘If it is not measured, it does not exist.’” a well-deserved personal insult or shaming look. The worst thing about inspections is that they may ruin the developers to the point where they get along better as a team, share information, and don’t have to work all night. Getting bogged down with difficult code at the beginning of the software project can hurt productivity, discourage developers, and idle the testing staff. Waiting until the end of the project to tackle the harder code decreases the likelihood that there will be sufficient time to complete the system. This increases the likelihood that features will be canceled or added to the next version of the product. If the feature actually is added at the end of the project, it may catch the test team members when they are most overworked and burned out and less likely to embarrass the developers by finding defects in the code. explain that your interface software was designed for the next version of the interface device, and then hope your staff can write the interface code before the other company comes out with its new version. 9. Know that developers will admit to and remember to fix broken code. 12.Never measure anything, because the result may be disappointing. Developers may become stressed if they have a long list of bugs to fix while trying to meet an unrealistic schedule. To reduce stress, problems found in the code could be discussed at lunch, noted on napkins if required, and fixed later. Documenting bugs and assigning them to developers to fix by a certain date also creates accountability, which is not compatible with meeting unrealistic schedules. Latitude for blaming must be preserved. Assuming another developer is going to fix the problem relieves stress. This worst practice has the added advantage of not wasting the developer’s time fixing defects that the users probably won’t find, anyway. 11.Ignore interfaces until the last possible moment. Trying to determine how to interface software to external products and then control those interfaces is always a significant undertaking. In this worst practice, waiting until the last possible moment to address the interfaces allows the developers to better understand what the interfaces actually are. Should problems arise, developers have two appealing options: always blame the other side of the interface for not adhering to the interface standards, and sell upgrades later to fix the problem once it has surfaced. The benefit, of course, is not wasting time writing code for interfaces that no one actually uses. If no one complains about a particular device not working, why write code for it? If numerous complaints come in about not supporting a particular interface device, have customer support www.StickyMinds.com 10.Keep the most difficult coding tasks until last. This worst practice emphasizes one of the nasty little secrets of software development—deferring the harder coding tasks until the last few builds of the project. When developers set their own feature list priorities and schedules, they can assure that the simple code is written first in the early builds. This has the added benefit of keeping the developers on schedule. Measuring the software development process and software product is not done, because it may lead to disappointment and negativism. Measuring things like defect find-and-fix rates, developer productivity, test coverage, customer satisfaction, process maturity, etc., can get in the way of the software project staff’s believing it is world class. Knowing that the schedule is unrealistic before the actual delivery date causes needless worry and concern. When developers know that there are bugs in their code, it makes them depressed and angry. Knowing that customers are not happy with the delivered product can further add to the unhappiness of the developers. It is much more productive to follow the time-tested, scientific adage, “If it is not measured, it does not exist.” 13.Avoid performing risk analysis. According to this worst practice, the best way to avoid risk is to think positively. The more time spent thinking negative thoughts, the more likely it is that something will go wrong. Imagining all the things that could fail is a time-consuming activity. Developing risk-mitigation strategies and tracking MARCH 2008 BETTER SOFTWARE 35 http://www.StickyMinds.com

Table of Contents Feed for the Digital Edition of Better Software - March 2008

Better Software - March 2008 Contents Mark Your Calendar Contributors eLightenment Technically Speaking Code Craft Test Connection Management Chronicles Cover Story: Breaking Ground On SOA Software Development Worst Practices Mind the Gap Product Announcements 10 Things You Might Not Know About... The Last Word Ad Index

Better Software - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.