Squeeze more out of the construction phase of application development

Changes in the way software is developed mean that organizations need to make changes to the way that they plan for projects.

The world of software development is changing. Software development tools and frameworks are promising to improve speed of development. New agile development techniques are changing how we approach the development process. Whether your organization has adopted new tools, new methodologies, or is just looking at what's going on in the market, you've got to account for the compression of the construction phase of the software development process.

Silver bullets

Although there are no silver bullets in software development (See Fred Brook's seminal work The Mythical Man-Month for more on silver bullets), we continue to make incremental improvements to the software development process. You might think of it as introducing a little bit of silver into lead bullets. Many of the improvements that we have for software development are improvements for the construction part of the process.

Figure A

The Mythical Man-Month

New tools like Visual Studio 2005 have editor technologies that improve development speed by making it easier to remember the properties and methods on the objects that you're working on. The compilation process has changed so that it's largely interactive. Most of the syntactical errors that you can make are automatically identified while you're editing and are flagged so that they can be fixed without running a compilation cycle.

In addition, more of the basic functions are available in the form of both built-in foundational libraries as well as third-party open or shared source libraries. Most of the broad application objects have been written and more and more commonly these libraries are bundled into the core foundational libraries. This means that to create a feature point within an application there's a greater and greater likelihood that the code is already written, all you have to do is connect it to the rest of your application.

Even if not contained within the core language operating system, there are foundational layers which offer enhanced and more feature rich functionality which can be layered on top of the core libraries and in doing so provide further enhanced functionality. For instance, the Microsoft Enterprise Library, while not a part of the core .NET framework, reduces the amount of code necessary for those interesting in using it. It's a collection of free documentation and code designed to make enterprise projects go faster.

Third-party open and shared source projects are filling in the niche areas where the standard libraries aren't playing. Whether it's a library for reading and writing RSS feeds, a web based text editor, or a complete web management system, there is a plethora of individual solutions which can be integrated into your applications.

The benefits of this are reduced construction times. However, the cost is additional design or exploration time at the beginning of the process to identify which of these foundational components make sense for use in the project. Additional design or exploration time is necessary to identify the third party projects which are valuable to parts of the solution.

When Fred Brooks wrote his essay "No Silver Bullet – Essence and Accident in Software Engineering," one of the observations is that the software development process is fundamentally complex and there is little or no way to fundamentally reduce this complexity. As a result we're left with making incremental improvements. Steve McConnell in his book "Rapid Development" commented about the idea of Silver Bullets and made the case that even if a tool were able to reduce one part of the software development process it's unlikely that its effect could be felt in every area of the project. In other words, a 25 percent reduction in the construction phase of a project does not create a 25 percent reduction in the overall project's effort.

Application development management

Software quality and testing

On January 21, 2006 Symantec's anti-virus software was capable of detecting 72011 threats. That's a staggering number. Today there are dozens of new threats to computing appearing each day. Not all of these threats rely on software vulnerabilities, but a substantial proportion of the newer threats are directly related to bugs.

Much publicized failures of software including a few NASA missions, a baggage system at a major airport, and others have created a greater awareness—at least in the IT industry—of the impact of software defects.

A May 2002 report by the National Institute of Standards and Technology (NIST) titled "The Economic Impacts of Inadequate Infrastructure for Software Testing" estimates the impact of software quality in the tens of billions of dollars each year. At just under one percent of the nation's gross domestic product. That's a staggering number.

Clearly software quality has a long road ahead of it as we try to make software more reliable. It is no wonder then that a greater emphasis is being given to software testing in software development projects. Formalized testing is getting a boost in terms of total elapsed time in the project and the resources dedicated to the testing process.

Agile development methodologies are beginning to drive the idea of test driven development into the consciousness of developers and development managers. Test driven development, in a nutshell, means writing your test cases first. First you decide what the module or object that you're working on should do and then you write tests which test whether that functionality works as you envisioned it—even before creating the object itself.

The net effect on the software development project is that less of the formal construction phase is invested on truly developing the code, and more time is invested in developing testing constructs. The back end formalized testing further reduces the overall construction phase of the project.

Test driven development advocates argue, somewhat successfully, that the additional time spent on testing reduces the overall amount of time necessary to construct the software because fewer bugs or unimplemented features go on to be undiscovered until late in the process – when it is known that bugs are more costly to fix.

What does this all mean?

These changes mean that organizations need to make changes to the way that they plan for projects. Instead of using historic guidelines for the amount of time that a project will spend in construction, they must look to smaller construction numbers while increasing the amount of time for design and testing. If construction has historically taken 35 percent of the overall project time, then you may be able to squeeze that number into 25 percent of the overall development time while increasing the design and testing phases by five percent each.

While I've expressed this as a zero sum game—that is likely only to occur in a case where new technologies are integrated into the development processes of the team. Once the team is comfortable with the new foundational classes and the third party solutions the additional design time will fade away for a while resulting in an overall reduction.

Techniques like test driven development can reduce the overall construction time, particularly on projects where quality is prioritized, however, initially it will be accompanied by a learning curve that will likely more than eat up any savings you'll have.

In the end, software development is getting better by improving the accidental (non essential) aspects of software development. This doesn't radically improve the development speed of the project, although it does has a positive long term impact, if you're willing to start making investments in tools and techniques today.