Dan Schoenbaum writes:
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.
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.
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.
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.
