Better Software - March 2008 - (Page 34)

made by stakeholders about what the software was supposed to do. Using this practice, experienced developers can convince the stakeholders that they never made their expectations clear and put the blame somewhere else, preferably on the compiler vendor. If this fails, developers may try raging at customers and stakeholders to get them to back off. This worst practice can set the stage for profitable future upgrades that allow fixes and insertion of the needed requirements to avoid the inevitable litigation in the courts. development to another company or purchase another company’s software instead of building it in-house. In this worst practice, careful reading of the supplier company’s marketing brochures and a long lunch with its sales representative should suffice as an acceptance test. Any delivery failures should be blamed on the external supplier. An experienced procurement agent and legal team can keep the finger pointing going long enough for the supplier to generate patches, upgrades, and service packs to fix the problems. creates merging headaches and bookkeeping problems. Tell them not to do that. Having the last code changes overwrite all the previous changes to a code block simplifies code management and saves the “best for last.” While something important that was put into the code previously could be overwritten, this can be remedied by judicious use of patches, upgrades, and service packs. In this worst practice, the profitable sales strategy is to charge customers multiple times to fix old problems that come back. 4. Just say yes to any and all requirement changes. Writing code before understanding requirements not only guarantees that the software is by definition bug free (only document the requirements after first determining what the software actually does) but also allows complete flexibility in saying yes to whatever users want. Saying yes to user requests creates goodwill in the early stages, and when combined with the assumption that all the tests will only be run once and pass, there is little chance of not being able to deliver the code on the unrealistic date (see worst practice No. 1). There is a downside, however, if the users remember what features they requested and have frivolous expectations about actually receiving them. Their initial disappointment can be mitigated with patches, upgrades, and service packs at a later date. Groveling may also be helpful at this point. In this worst practice, seasoned developers can meet almost any unrealistic schedule simply by allocating all but one of the features (usually the log on) to later builds. Since the last build winds up with all of the difficult features to code (see worst practice No. 10), hopefully the software will be obsolete by then anyway. 6. If the software is slow, buy faster hardware. 8. Refrain from having others review or inspect your code. There is nothing more irritating to a developer than having someone else point out problems in his code. A common misconception is that having another developer review code will increase the likelihood of finding defects early, thus saving time and money. This worst practice asserts that it does not make sense to tie up developers with code review; it slows down their own work. The code could be tested and defects discovered by lower-valued testers and customers. Another issue is the training required for developers who inspect code. These developers can spend days learning how to conduct an inspection and how to speak sweetly to the author of the code being inspected. These peer review training classes and follow-on inspections lower coding productivity rates and slow the project. Developers are much more comfortable trying to solve problems in groups to show who is smartest. Inspection training discourages this form of healthy competition. Inspection also increases the level of stress in most developers. They must write code with the thought that their peers are going to review it, short circuiting the productivity tricks of inserting blank lines, irrelevant boilerplate, and minimal proofreading. The wisdom of speaking courteously to the code author and only about the product when a real bonehead defect is discovered is questionable. It may be stressful for reviewers to hold back Timing studies, capacity allocations, usage profiles, and response-time analysis all take valuable time away from writing code. Fortunately, CPU and peripheral device speeds are getting faster and faster, so use this worst practice if the software runs too slowly. While there is a cost to buying faster hardware, remember that it is getting cheaper every week. If CPU clock speeds close to the speed of light are required, then the obvious solution is to use multi-core processors. This, of course, requires additional software to execute parallel processing efficiently, which requires additional memory, which requires additional communication time, which necessitates a new, clustered operating system supported by new compilers with thread-safe libraries. Delivery slippages can be blamed on all of these. This worst practice is a key element in the growth of the worldwide computer industry. 7. Use the honor system for code management and build process. 5. Reused and subcontracted code can always be assumed to be correct. One way to save time and money is to outsource much of the software BETTER SOFTWARE MARCH 2008 Setting up configuration management systems takes time and detracts from writing code. In this worst practice, assume that developers can keep track of their own code and trust that no one will ever change the main branch without informing everyone else. If two or more developers work on the same piece of code simultaneously, it 34 www.StickyMinds.com 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.