This article continues our series of blog posts on ERP and Business Management Software.
This time I would like to talk about a core value of extreme programming which should also be a core value of software development in general. Let me begin with a story that can be a great example of what can happen to any workflow over time.
Once I was invited to explore a huge machine building plant. Their specialization was building heading machines, tunnel building machines and other mining equipment. Their end product was amazing, but everything was much worse in terms of inventory and production management.
There were many office blocks and big rooms with people in them. While exploring the enterprise workflows, I asked most employees about their responsibilities. Guess what the most frequent answer was?
"I take this book, go to this page, take numbers from this column and write them into this row in another book".
This is why enterprise employees are usually afraid of automation. They have reasons to think that they would have no job after the enterprise is automated. Or alternatively, they could be moved to real work that assumed more knowledge and responsibility.
Serve the servant
This is what happens to almost every business as it grows. It leads to a great management crisis. However, the head management continues to handle matters the same way they always did because changing administration procedures is costly.
So they spend more and more time instead of spending money to rearrange their offices.
I remember when I was taking driving tests, at the driver licensing office, I was told to go to the traffic police office and get a letter saying that I had never had a license before. I had to do it two weeks prior to the tests because it was how much time they would need to gather the information.
I always wondered why on earth I was part of this procedure? The driver licensing office and the traffic police office should have been integrated in the same system, they could share the same data, couldn't they? So, why did I have to spend my own time to visit a place I personally did not need anything from?
This way, an office that was created to serve my needs, turned into an entity I had to serve. This is exactly what is called bureaucracy - a necessity to serve an office that supposed to serve you.
In the business software world
The best examples of over-engineered business management software can be found in the US Healthcare world. At Anadea, we took part in development of 5 or 6 medical apps, and the medical market never failed to amaze me.
In 2010 CMS (Centers of Medicare and Medicaid) changed some old and obsolete standards. After that, the MDS 2.0 forms that had 200 fields turned into MDS 3.0 that had 800 fields and 200 rules to maintain consistency. They provided a script for calculating some metrics and updated this script over 10 times after it was published.
Recently we worked on some other standards called OASIS forms. They had about the same amount of fields and consistency rules. I have no idea why insurance companies require so many fields, except for the idea that they probably want to maintain their legacy databases and calculations.
The same is valid for the most well known software. When dealing with third party APIs of old and famous websites (including Salesforce, Bloomberg, etc.) it is easy to see that inflexibility. The reason why the owners do not change that is simple - they cannot.
So, this is what it takes to deal with heavy legacy. When you see a problem for the first time, the price of maintaining the current structures seems more affordable than the price of changing the system. But both costs grow over time and the business owners have to pay the price even if they do not make any decisions at all.
At the same time, if changes in a system were made as soon as they looked reasonable, the problem would be solved and price would be paid just once.
So, now we are about to understand the value of simplicity in software development.
The cost of change
Kent Beck in his "Extreme Programming" book explains that simplicity is what allows the developers to easily make changes in the project code at the late stage of its existence.
He provides two charts that compare the cost of change in a usual not-one-step-back development process and the cost of change in the agile development procedure. Here you can see these graphs on one chart:
See the difference? The cost of change in a usual development cycle grows over time because the developers are allowed to move only forward without thinking about bigger changes in the software architecture. The architecture should be built correctly from the very beginning, the usual approach says.
The agile (or extreme programming) approach assumes that the developers are allowed to simplify the code as soon as they see an opportunity to do it. This is why simplicity is one of the core values of software developers.
Is it really that simple?
And if it is, why the usual step-by-step approach does not borrow the same principle?
In general, yes, it is that simple. The core values define the coding style and eventually the result the project owner gets. However, it is not sufficient to be "agile" to reach the goal. Here is what should be taken into consideration as well:
The result depends on the experience of the development camp. Not only they should consider simplicity as a core value, but also know how to apply it in real projects.
Simplicity works only when combined with other values such as communication, feedback and courage. The main reason why the step-by-step approach does not integrate simplicity into its core is that the project owners are too much concerned about terms and milestones and are not brave enough to change the architecture.
Simplicity is only possible if the project owner shares the same values the development camp has. Otherwise the developers have to struggle to explain their reasons for simplifying the code, removing redundant or obsolete parts of it, etc.
As you can see, the step-by-step approach is built on a different basement. Non-agile software companies can develop amazing applications. However, I often see how companies that have about 1500 developers are unable to make changes in their software because of impersonal reasons.
The approach to ERP development, just like with medical and business management software, has to be flexible because these software solutions are supposed to live a long life. So, their code should be kept simple and maintainable as much as possible. As a project owner, you can reach this goal by having the same values your agile development camp has.
In particular, you may want to appreciate their efforts to achieve simplicity of the code.