The Top 10 List of Software Development Blunders
Are you making these software development blunders? Here’s the top 10 list compiled by Borland.
1. building Infrequently
The solution to painful dentist visits isn’t going less often, it’s going more often! The same is true of painful software integration events. Building frequently - preferably continuously - allows you to discover problems early on and nip them in the bud before they grow into big expensive disasters. Plus, building software is a critical validation step - you don’t know if something’s broken until you try putting it together. Build frequently gives you greater confidence that you know what the state of your software development project really is.
2. Not Validating Changes Against Target Environments
Customers usually aren’t too understanding when you tell them “Well, it worked on my machine.” The (often unconscious) assumption that the developer’s environment is an acceptable proxy for the “real world” is the hidden cause of many problems. It’s unrealistic to expect that developers will have the right setup on their desktops to fully validate their changes, especially when you need to build and test on multiple platforms or have test environments that require external resources. Changes should be regularly validated against all the appropriate target environments, preferably by an automated process.
3. Broken Builds
How many times have you (or one of your developers) been stuck waiting for someone to fix the build before you could continue work? For all the time developers save with visual editors and other coding productivity tools, ten times as much is wasted due to broken builds. Code needs to be successfully built before being integrated into the main code line where it can affect others. Ideally, work-in-progress should still be regularly checked into version control, but it should be kept isolated until it builds successfully.
4. Not Testing the Build
Many organizations fail to take advantage of the build process as an opportunity to test earlier and more consistently. Automated software inspection and build validation tests can help you detect regressions and other problems early, when they are easier to find and fix (not least of all because the changes in question will be recent enough for developers to remember what they were thinking when they wrote that piece of code).
5. Infrequent Check-ins
Making large, infrequent check-ins is not only a recipe for losing lots of work when you accidentally corrupt your hard drive or your laptop’s battery explodes, it also limits the value of other best practices like frequently executing and testing the build. Continuous integration is really only as continuous as the version control activity driving it - if you only commit your changes once a day, there’s no point in doing anything faster than daily builds (if you check-in your changes less than once a day, seek professional help immediately). Checking in smaller revisions more often also makes it easier to keep track of your work and track down the cause of any problems that are discovered.
6. Not Publishing Builds
Collaboration is the key to successful software projects and working code is the best artifact around which to collaborate. Giving other developers and QA engineers easy access to the latest builds helps keep everyone in sync. Make sure your build system can automatically publish successful builds so you don’t have to deal with managing distributions manually. And be sure to also archive your build configurations, so you can reliably reproduce customer issues on older versions of your software.
7. Interpreting Code Coverage in Isolation
The most frequently cited code coverage related blunder is probably “wasting time trying to get all the way to 100% coverage”, or “believing that very high coverage means your code works”. A commonly overlooked issue, however, is the importance of relative code coverage. If you can’t compare coverage between different projects, then you don’t know where scarce testing resources will be best spent. If you don’t know (or can’t remember) what your code coverage was last week, last month, or on the previous version of the software, it’s hard to evaluate today’s number. Code coverage is far more useful when you can view it in context.
8. Lack of Transparency
While it’s very common to see businesses adopt open source software today, it’s fairly rare to see those businesses adopt any of the practices that help make open source software successful. One key characteristic of open source development projects is transparency - everyone can see what everyone else is doing, fixing, or breaking - and this encourages bother peer accountability and recognition of individual contributions. This is especially important with distributed development teams where the right hand often doesn’t know what the left hand is doing (because it’s asleep when the other one’s working). commercial software development organizations would be well served by adopting practice to improve transparency among developers and, just as importantly, to give QA and management better and earlier visibility into development.
9. Relying Only on Unit Tests
Automating unit tests in your builds is a good start, but if you limit yourself to only doing unit testing, you’re missing an opportunity to catch a much wider range of potential problems. From simple static analysis tools like findbugs or checkstyle, to enterprise products for security analysis, license compliance audits, or functional testing, the build event provides and excellent opportunity for early detection of a variety of issues. Combined with a defect isolation mechanism, this can also become a valuable tool for enforcing software development policies or best practices.
10. Ignoring History
If you regularly build and test your software, but don’t persist the results in a database, you’re missing out on the opportunity to gain valuable insights into your development process and software projects. There’s a wealth of information in the form of build reports, test output, and other artifacts just waiting to be mined if only they were stored in a convenient way. Even relatively simple queries could uncover previously unknown relationships or dependencies - finding out that half of your build failures occurred after someone touched an obscure configuration file would give you a pretty simple way to optimize your build process!
Then, how to overcome these blunders? Borland offers whole bunch of tools to help. No kidding, from Lifecycle Quality Management to Performance Testing, Borland’s development tools are still the best.