Tag Archives: Methodologies

Development Testing – Is It Worth It?

I delivered a webinar yesterday as part of my day job at Parasoft . The topic was “Development Testing – Is It Worth It?”.

I talked about the reasons why Development Testing is useful, how it relates to process, policy, and how you can move from a reactive process of finding bugs to a proactive process of writing code that is resistant to bugs. As the old saying goes, an ounce of prevention is worth a pound of cure, or a week of debugging in this case.

The presentation is general, not designed to push any specific tools, so you should find it helpful. I’ve made both the powerpoint slides and audio available below. You can usually access most of the past webinars and other video content on the Parasoft site.

Take a look for yourself. If you have any comments or suggestions, feel free to mention it in the comments, or email me or reach me on twitter.

(powerpoint) (mp3 audio)

Download (PPTX, 2.52MB)

The webinar invitation read:

Development Testing: Is it Worth It?

Development Testing is a lot like exercising and eating well: pretty much everyone agrees that it’s beneficial and should be done, but few actually achieve it in practice.

A rising number of organizations are flirting with Development Testing by giving developers a static analysis tool and hoping that they use it to prevent defects. This is not unlike packing some raw broccoli and spinach in your son’s lunch box and expecting his health to improve as a result. This approach to Development Testing inevitably fails to deliver the results that organizations have been able to achieve with a comprehensive, policy-driven Development Testing process: reduced risks while cutting development time and costs.

If you can’t bear the business risk associated with defects surfacing in your organization’s software, join our webinar—Development Testing: Is it Worth It?—to learn how to get the maximum risk reduction from your investment in Development Testing. After exploring the dangers of relying on static analysis alone and the top barriers to comprehensive Development Testing, you’ll learn how Parasoft’s comprehensive Development Testing platform can help you:

  • Consistently apply a broad set of complementary Development Testing practices—static analysis, unit testing, peer code review, coverage analysis, runtime error detection, etc.
  • Accurately and objectively measure productivity and application quality
  • Drive the development process in the context of business expectations—for what needs to be developed as well as how it should be developed
  • Gain real-time visibility into how the software is being developed and whether it is satisfying expectations
  • Reduce costs and risks across the entire SDLC

Agile 10 years later: Dogma vs Doctrine

It seems like every few years a new software development methodology comes along. Frequently it’s a rehash of an old methodology, like object oriented programming’s rise (again) in the 90’s. Sometimes it’s a formalization of existing ideas and techniques, and sometimes it’s something completely new. Invariably the new toys excite a group of people who will promote them ad nauseam. Many of them become a flavor-of-the-month (or year) and then are never heard of again. Despite that, some of them end up being interesting and manage to survive their 15 minutes of fame.

The funny thing is that you can usually separate such ideas into two key components. One is the actual technology (ideas, tools, techniques, etc) and the other is the philosophy or religion. In other words, the “why” behind the whole thing. I prefer to think of it as religion because it tends to provoke the same kind of arguments and behavior as religious discussions and disagreements.

Agile development is a clear-cut case of such a problem. There are some wonderful, useful ideas embodied in the Agile Manifesto. If you apply them judiciously with an eye toward constant improvement and productivity, and where necessary take into account the evils of financial viability and mandated compliance overhead (such as aerospace, FDA, government, etc), you can start producing better software more quickly, and with less cost.

However when a group of people start doing Agile for Agile’s sake, you can have a disaster on your hands. I have witnessed this personally at some large companies where an Agile team had an interpretation of agile development that was at odds with the company’s needs.

I say interpretation of Agile, because different people have widely different opinions about the degree to which Agile alters their world. In one case a company building very specific hardware/software products has a very strong need to meet particular deadlines, and to deliver very specific features because they release a matched blend of hardware and software. In this company, the Agile team claimed that asking them to definitively schedule feature delivery was a ridiculous request. The team felt their company’s request was “ignorant” and beneath them. Not surprisingly, such an attitude doesn’t work well at companies who simply cannot have an agile release schedule.

For web-based organizations like Google or Amazon, the timing of feature delivery can be more or less whimsical. They can produce what they want, when they want.

On the other hand, companies building smartphones or heart-monitors face a very different reality. There are deadlines, requirements, scheduling, documentation, etc., all of which have to be met and coordinated.

The sad thing is that the dogma fueling the religious war (We can’t be expected to produce a schedule, we can’t write comments, etc) is counter-productive, which leads people to avoid Agile altogether, thereby depriving themselves of potential and probable productivity improvements.

In my experience Agile, like other methodologies before it, works best when followed in a contextual manner, mindful of product needs, organization (corporate) needs, and other issues surrounding the software in question. If you pick and choose the doctrines that can help your team and your product, you’ll be an Agile fan. If on the other hand you dogmatically adhere to “Full Agile,” without regard to the environment you’re in, you can cause project failure, put people out of work, and potentially kill a project or even a small company.

So Agile is 10 years old now. Should you use it? Will it make a difference? In my opinion if you separate the dogma from the doctrine you can definitely benefit. But beware the pitfalls. If you’re careless, you’ll waste time at best, and money, people and perhaps even more at worst. If you’re careful, the benefits from increase quality and productivity can be enormous.

Resources