It sometimes feels like business works against IT by finding something new to change, add, or by making some parts not relevant anymore when the project just stabilised and it was possible to see what this is that needed to be done. How come that the change in the requirement becomes so painful within software while in other human domains it’s not as stressful. In daily lives, humans learned to adjust, adapt, use workarounds, alternative routes, ask others for help, and drink coffee. So why is that the software process is trying so hard to resist the changes?
One reason is that we expect too much flexibility from it by assigning unrealistic voodoo stretching properties. Another reason is that it is hard to take the responsibility for something that no one is sure about yet. It appears that other domains have been dealing with these problems with a high level of success. It takes real engineering skills, experience, and patience to encapsulate and handle the change. In reality, the software world has much more in common with other engineering domains than one might assume, and we can learn a great deal from both their success and failure stories. Who would not want to build the software on quality, time, and budget in the end?
For over a decade we’ve been struggling to close the gap between the business and IT. The problem we all recognise is that technical and business people perceive a common goal in different ways. Business wants technical people to be as flexible and adaptable as possible. The IT wants rigid stability in the business model. As a result, both sides drive each other crazy. To bring the two together, the industry has come up with several theories and philosophies. But most of them assign non-existing voodoo properties to software development and ignore essential aspects of engineering and design.
A long history of working with business
As humans, we’ve had a long history of doing business and describing what needs to be produced in exchange for seashells, beans, golden or digital coins. We have been producing and selling, changing form and functions, improving and innovating products according to the buyers’ needs. Today, we successfully exchange sophisticated gadgets assembled from parts manufactured across different continents.
What allows a seller and a buyer to do business successfully? Trust does. Trust is our confidence that expectations will be met and the product will function as it should. We examine the quality by simply looking and touching the product, seeing it function. And trust between buyer and seller in the IT world means software quality, which is much more difficult to examine but is nevertheless essential.
Besides quality, trust is built on timing and budget. Business people focus on the time and cost of projects. But budgeting and staffing questions often become unmanageable as new iterations discover changes in the requirements and overlooked details pop up late in the process. All of this causes unexpected delays, additional staffing, and sometimes redesign of the whole system, making it hard to document, predict and plan business activities. Business people accuse IT of not doing their job properly and not being flexible enough. IT accuses business of not knowing what they really want.
What if it were me?
While losing motivation and struggling with this problem from the IT perspective, I try to stop and think what if it were my money invested in the whole project. Would I like to know how much it would cost and how long it would take? Hardly any of us would invest any time or money into something without knowing these details.
Outside of the software world we have been dealing with time and money problems for a long time and with a high level of success. Asking questions like “what if” or “when” occurs naturally to us. When we think it could rain, we take an umbrella; when we have a guest coming, we plan for some snacks; when we expect a baby, we plan for a bigger house. We buckle up in the car, even though most of us will not get into a car accident; we have savings accounts and insurance in case something happens. Whether because of a frightening or a happy reason, we all think about changes in our lives and try to prepare for them.
To change is to live
The fact of change creates IT jobs. Otherwise, software built once would serve forever with no adjustments. Business changes provide IT its daily bread but the IT industry fails to recognise this. Most of the IT people are so afraid of the changes, they invent frameworks and philosophies that split a bigger change into smaller pieces and name them something else to create an illusion that everything remains stable. To close the gap between the IT and business people perspectives we need to handle change well. This is the solution to build quality software on time and within budget and regain trust between business and IT.
So how do we handle the change properly? The answer is both simple and shocking. We should never use the requirements as the base for the software system design. One does not build a house one feature after another. There is no way a “cooking” or “bathing” feature will be solved before the foundation has been laid and the inner plumbing, electricity, interior, and many other steps have been completed. It is only closer to the end of the building project that certain features will be completed and ready to be used.
Catch the change
The most important aspect of this method for handling the changes is to encapsulate them into components. In the case of a house, there are going to be components such as appliances, furniture, and utilities. When on the highest level, the house was defined as the house, it should be clear that it cannot turn into a hotel or an office building. Similarly, one cannot make a car from a bicycle or build a truck from a previously built car, regardless of how many iterations or people get involved. It is not impossible to work that way, but it is one of the most inefficient and expensive ways of building. Without this understanding, the business lives with unrealistic expectations while IT promises something that they cannot deliver. As a result, the gap of misunderstanding and cross blaming grows.
Designing and building software based on the understanding of changes is not trivial. It requires knowledge of the domain, discipline, and dedication to the process and teamwork. This is not something that will suddenly evolve on its own. More people within the business and IT need to accept that change is the essential element when designing the software. The years of experience from domains other than IT have examples of both greatly and poorly designed architectures, and there is a great deal of knowledge there despite the belief that software is something special and soft so that the rules of physics do not apply there. The proper type of engineering and validation will bring confidence and trust to both business and IT. It is not a simple trip, but it is a trip to bring sanity to the software architecture.
