Call them what you want; bugs, defects or undocumented features, bugs in software are more prevalent than ever! It is no surprise that the equation to increased development profitability is to control defects (Faster coding + less defects = shorter lifecycle). It seems as of late, more and more development teams are content with releasing code that has observed, identified defects. So what drives this counter intuitive behavior?
Compressed timelines, limited resources and scope creep all play their part, but more disturbing is the number of developers which rely on someone else to complete their unit testing. Looking to our industry leaders as examples, this behavior appears to be the norm, not the exception. For those of us that have been Beta testers for Microsoft, we all know firsthand how unusable many products are until the first Service Pack. What is driving this type of development cycle?
We work in a code-and-fix culture
Many developers leverage their defect management system as an extension of their unit testing. In our organization the pace is fast and the timelines are tight. It not uncommon for a deadline to sneak up on a developer and their reaction is to release code that is functional, just not well tested. This always results in a series of frustrating iterative cycles, where QA finds defects, and a developer has to reexamine code they just completed. Once this cycle gains momentum, projects get down to the “crunch week” and developers are frantically moving their way down a large list of never ending defects. Secretly they are preparing themselves to release code that will undoubtedly need to be fixed.
Here are some ways an organization can break out of the “code-and-fix” culture:
All project must have a single team lead – The only ways that the impact of defects on timeline will be taken seriously, is to direct accountability. A single team lead is perfect to keep a project focused and on track. Even if the lead cannot be dedicated to writing a large portion of the code, they need to feel empowered to have control over its quality. A good team lead is one that understands unit testing and is comfortable in being critical of areas of the project that are not reliable.
Whenever possible, no project should ever have one single dedicated resource – If we take our lead from extreme programming, two minds are always better than one. Having multiple development resources involved in the development process, exposes code to multiple perspectives. This is not to suggest that every project must have two or more fulltime resources, but the entire development team should have the capability to step in and contribute to the solution.
Refactor, Refactor, Refactor – Every developer should have refactoring as a top priority to help improve their codes internal consistency and clarity. It is impossible to write defect free code unless the internal structure and design is easily understood by any developer. This includes clear and consistent variable and method naming, and meaningful method summaries and comments. The more clear and understandable your code is, the more likely a bug the surfaces can be squashed with little impact on adjacent methods or modules.
Reuse proven techniques – Feel comfortable extracting, stealing or borrowing code from other projects you or your team have already done. You cannot write code faster than cutting and pasting something you already know works, and has been thoroughly tested. Standardizing on methodologies, algorithms and techniques. Standardization reduces defects and minimizes making the same mistake twice.
Take an Agile approach to development – Projects that span more than a week of effort should always be broken into multiple “sprints” or iterations. Each iteration must have a clear deliverable and should last no more than a few weeks. More often than not, an iteration signifies a milestone in the projects lifecycle. At the end of each iteration a release of code should be made to the projects stakeholders. Care should be take to achieve as much closure as possible to those sections of the system included in that iteration. If you can’t complete a section within the fixed iteration length, then move it to the next iteration.
Stop assuming, start abusing – Always get clarity to functional requirements before you start coding. It is reasonable to ask project leads or account managers for excessive detail on functional requirements. More than one developer has created defects in a system because they assumed they understood clearly what they were building. Frequent communication with a projects stakeholders will decrease defects. There is not a good account manager on the planet then wants a developer filling in the gaps without a clear understanding of the clients vision.
Bugs squash em fast! – As quickly as possible exterminate defects from a system. The longer one waits to address an “undocumented feature” the more likely they are to interject new defects during the process. If this defect was documented in a defect tracking system, comment on the steps you took to reproduce the defect, how you fixed it and the results of you unit test. Taking the time to write about it can go a long way in making sure you thoroughly understood the extent of the defect.
Understand the difference between a defect and an enhancement – This sounds simple, but without a clear separation of the two we have no way to measure what in the process is empowering the code-and-fix culture. Developers like to put code to rest as quickly as possible. We love to group together as many changes as we can into a single attack on a chunk of code. The more we do at once the less likely we are to kill the original defect. Anytime an enhancement is done adjacent to correcting a defect, you increase the risk of masking the original issue. Worse yet you might get the desire to rewrite the whole thing negating all previous testing. Enhancements have their time and place, just not grouped with defects.
Stop making excuses – When you write poor code admit it. We all make mistakes no code is perfect. Be embarrassed when you are asked to write a contact form and when QA goes to click the submit button it blows up. All developers have time to test and must make sure that we have tested the application just as others will. How can a developer feel comfortable saying something is done, if the first users gets to experience an “unhandled exception”.
Wednesday I had the great opportunity to participate in the second annual f8 developers conference in San Francisco. Last year I attended on behalf of Terralever, one of only about 30 selected launch partners. A few weeks before the first f8, Terralever was asked to develop two proof of concepts apps that demonstrated the power of Platform. It was a crazy two weeks of development, but we pulled it off and were one of the first Agency to have proven Facebook platform experience. Since then, we have built various applications, some for start ups looking to use Facebook as there platform, while other for big brands like BMW and Nike.
This f8 Terralever was selected by Red Bull as one of only a handful of launch partners that would have the opportunity to integrate Facebook Connect (announced during the keynote) with some of their properties. As you can imagine were were very excited about this opportunity, and more excited about what Connect will mean to all of our clients.
This year Terralever has the great opportunity to present at Microsoft’s Mix 08 conference in Las Vegas, March 5-7th. Mix is an amazing conference that exposes the technology community to the latest on Silverlight, Internet Explorer, ASP.NET, Expression, Windows Live and other key technologies. The topic I will present on is “Silverlight as a Gaming Platform” and specifically our experience writing a game in Silverlight 2.
