A software potential movement?

We are all familiar with Moore's Law. It is one of the tenets upon which the great promise of the technology age rests.

However, even with the dizzying speed at which today's machines can process, computing technology isn't delivering the exponential uptick in business productivity, profitability and innovation that Moore's Law promises. Why is this?

It's because software isn't holding up its end of the bargain.

The various arms of an IT organization often operate in a vacuum.

Instead of exponentially increasing business productivity and allowing us to realize the full potential of our ever-faster and more powerful hardware, software consistently grows more complex, bloated, cumbersome and slow.

It is no secret that the majority of IT initiatives fail. Software is hard to write, hard to understand, hard to deploy, hard to use, hard to manage, hard to maintain and increasingly hard to justify. We spend billions of dollars building, implementing, fixing and fighting with our software, and yet we demand little in return, meekly accepting that our investments come with no quality or performance guarantees.

But let's face it: We need software. We are empowered by it and regardless of its shortcomings, software is here to stay. Its problems are ours, and the onus is on us as the innovators, developers and users of today's software to take responsibility for our contributions to its sorry state, and to commit ourselves to changing our approach to software in order to bring forth its renaissance.

Unfortunately most companies and solution providers limit their efforts at solving the software crisis by narrowly focusing on one area of the development process. Some are attacking the challenge of writing better code (faster), while others search for application management solutions that will enable our buggy software to "heal itself," and the rest of us invest in governance technologies that offer vague promises to "enable IT to run like a business."

Meanwhile, software still isn't living up to its potential.

IT projects fail because we often approach the software development process with reckless abandon. We have thrown the proven engineering principles and processes that other disciplines adhere to right out the window. We are lax in planning, we have few standards and design principles.

Bring the development team closer to the customer, close the gap between the builders and the testers and unite the process with the plan.

If we do create a blueprint for our applications, the team that lays the bricks rarely follows it. When building (coding), we deviate from our specifications. We shield the coders from the architect, we shield the quality testers and the maintenance crew from the coders and we shield the whole team from an understanding of what the homeowner (the software user) expects and needs from the final product.

To overcome the underachievement of software, we must abandon this myopic approach and begin considering the various phases of the software lifecycle as a whole, for the gestalt holds the key to better software, and the first steps to achieving something close to Moore's Law for our industry.

But where do we start? With a question. The simplest of questions, really, but one that is often forgotten in the increasingly desultory effort that is modern software development: What is this application supposed to do or help its user do better?

It is the answer to this question that must drive our software development projects and serve as the foundation for a radical change in the way we develop, deploy and manage our applications.

Start with a blueprint
Organizational silos make it easy for us to lose sight of this question and even easier for us to build software without keeping in mind that an application's raison d'etre is tied to the answer.

The various arms of an IT organization often operate in a vacuum with no knowledge of how their efforts relate to the purpose and intended use of the finished software product. Therefore, the second step to better software is to break down these silos. Bring the development team closer to the customer, close the gap between the builders and the testers and unite the process with the plan.

By imparting the entire software development team with a clear understanding of what the application they are building is supposed to automate, streamline or facilitate, the lines between the software development disciplines are blurred and all can focus on a common goal: build an application that does what it is supposed to do--and does it well.

This process starts with a blueprint. A map that guides the entire IT team through the effort of building, testing and maintaining an application that meets the business needs of the customer. This blueprint ensures that the builders lay every brick with the software's purpose and goal in mind. It should also enable the developers to consider testing in the early stages of construction and help quality assurance departments to understand the way in which the application will be used.

Breaking down silos, uniting the phases of the software lifecycle and creating a blueprint that each can understand and use is no simple proposition. But, the state of software is no small problem. The only solution to the lack of quality and the increasing complexity of software is to make drastic changes in the way we employ people, processes and tools to design, build and deploy it.