Software development is not bound by the physical world. If you are building a house, there are physical logistics that must be performed in the real world (e.g., moving 2x4s, pouring concrete or letting paint dry). However, software does not have that challenge. Software engineers can create software almost as fast as we can type. In a few lines of code, software engineers can put 1 million objects into memory. In a few more lines we can have those million objects talking to each other.
Complexity is born.
Software engineers need to manage that complexity to maintain speed. Ultimately, software development is about delivering the most business value for the least cost. Often times businesses focus on the short-term value/cost delivery, but software needs to be built with sustainability in mind in order to achieve long-term value/cost delivery. The reason for this is that unmanaged complexity will end up slowing down development. The software can become hard to evolve in response to changing market conditions and emerging customer needs.
Software engineering is all about managing complexity.
The software world has developed an endless list of engineering best practices to manage complexity (object-oriented design, design patterns, microservices, etc). One of the ways we do this is by decomposing our system to minimize coupling and maximize cohesion. Too much coupling in a system can ossify the code, making it hard to maneuver. Agile engineering practices are about agility. Coupling stifles agility.
When complexity is not managed well, your software can become tangled and interconnected. The project will move slower and new feature requests will become harder to satisfy. First-rate software engineering can save the day by managing complexity, avoiding tangled dependencies and keeping a program racing forward.
If you detect your software team is slowing down or pushing back on making what you would perceive as simple changes, take a look at your dependency diagram. If it looks like it was drawn by a baby, it might be time for some major refactoring.
© 2024 BeanStock Ventures