Maintainability: Behaviour vs Structure
By — Aman Singh (Order, Request Management Ecosystem)
Introduction
There has been a lot of confusion between behaviour and structure over the years and many freshers faced this issue. What is the behaviour? What is the structure? What are the differences between the two? Who had a major impact on systems maintenance?
For starters, I’ll assert that there is a significant difference between them.
Behaviour
Developers were hired to develop systems that either make or save money for the organisation.
We do this by helping the product/ system stakeholders develop a requirement specification document.
Then we write the code that results in the machines/ system to satisfy the requirements.
Whenever the system violates the requirements, then we take our debuggers and fix the problem.
Structure
The software was invented to be “soft.” which means it was meant to be a way to easily change the behaviour of machines. To satisfy the above-mentioned statement, software must be soft, which means it must be easy to change.
Whenever the requirements get changed and enforces changes in the feature behaviour then that change should be simple and easy to make.
In order to do that, the structure of the system should be independent of the behaviours. The system should be modelled in such a way that it should not prefer or be biased towards one behaviour.
It is this difference between modelling a system from a behaviour point of view rather than a structure point of view, drives the growth in development cost. It is the reason that the first year of development is much cheaper than the second, and the second year is much cheaper than the third.
That is why mature companies give more emphasis to capabilities instead of building features.
Maintenance
Now I can assume that you know what behaviour and structure mean w.r.t to software systems. Now which one provides more value w.r.t to maintainability?
Let me share some data to help the same
Any systems that were redesigned for the same purpose share a common pattern.
If we compare both of the diagrams then we get the insight that every cycle is supported by an increasing number of developers and the growth in terms of code doesn’t match the same.
Now you can guess where the additional bandwidth gets consumed which is unproductive w.r.t to the organisation, the answer is simple — Maintenance.
Conclusion
In short Always Biased for the Structure, if the system is heading towards the behaviour point of view, then the cost of change will increase release by release and a time will come when the cost of change exceeds the benefit of change and many systems reach that point in some of their features or releases.
Remember as a software developer, you are also a stakeholder and you had a stake in software that you need to safeguard and that is your role and duty.
About the Author :
Aman Singh, coder by weekdays and creator by weekends! Helping build the order management for millions of bookings across the world at Urban Company.
Sounds like fun?
If you enjoyed this blog post, please clap 👏(as many times as you like) and follow us (@UC Blogger). Help us build a community by sharing on your favorite social networks (Twitter, LinkedIn, Facebook, etc.).
You can read more about us in our publications —
https://medium.com/uc-design
https://medium.com/uc-engineering
https://medium.com/uc-culture
If you are interested in finding out about opportunities, visit us at http://careers.urbancompany.com
