Sustainable Software Development, Part 2: Managing Complexity

As the code base grows, the complexity of your code increases. The pace of software development often slows down as the product matures. Why is this? What can we do to manage complexity?

Sustainable software development is about retaining software development velocity over the life-time of your product. In part one, I covered the technical debt side of sustainable software development. In essence, when you postpone refactoring, bug fixing, testing etc., you accumulate debt. As all debt, it has to be re-payed. But even worse, you will pay interest. Every time you think about, swear about, discuss, plan or anything (but fix) your known problems, you pay.

In this second part, we address another challenge to a sustainable pace of development: the increased complexity of the software. In order to avoid letting the complexity make your life miserable, we need to manage the complexity. For brevity, we will touch only upon these four areas:

Simplicity

Dependencies

Hierarchy

Abstraction

Fred Brooks makes the distinction between essential and accidental complexity (also discussed in his book “The Mythical Man-Month”). Essential complexity comes from your problem domain. The problem will have an inherent complexity you cannot get away from. Accidental complexity comes from the solution you’ve chosen. The “Keep it simple, stupid!” (KISS) design principle encourages developers to prefer simple solutions over those more complex. Thus, in order to manage complexity, it is important to keep the accidental complexity to a minimum. For example, dividing your code using the Single Responsibility Principle is one way, so that different pieces of functionality are not tangled up in a single class.

Another example of accidental complexity is the introduction of unnecessary dependencies in your software. Every subset of your code will have connections and communication with other subsets of your code. In a naive software implementation, the number of connections would grow wildly with the size of the software. The interconnectedness of your code is one aspect of complexity that needs to be managed. Decomposition and decoupling will help you, and they should be applied to all levels of your system: service, sub-system, module, class, function etc. Various design principles (e.g. Dependency Inversion Principle) and patterns can guide you.

Steve McConnell discusses hierarchy and abstraction in his article “Keep it simple” (and in his book “Code Complete”). Structuring your software as a hierarchy is a means of decomposing your solution into more manageable pieces. Normally, different kinds of hierarchies exist within your code. For example, think about the difference between the relation between objects (“which object creates/destroys/contains/depends on/owns the memory of which”) and the relation between functions (“which function calls which”). One architectural pattern that can help the high-level structure of your code is Layer (defined in the book “Pattern-Oriented Software Architecture: A System of Patterns” by Buschmann et al.). One upside of a structured approach like Layer is that tooling, such as automatic mapping which classes depend on which, can help you enforce your structure over time.

Abstraction is all about what level of detail is visible at what level (see also my post on abstraction). For example, the file system is an abstraction hiding the hard-drive with its tracks and sectors. When writing a program, you refer only to “file x”, and not to “track y, sector z”, which helps tremendously. Abstraction will help you reason about your program. Abstractions are largely domain dependent. Your domain will decide what is a good level of abstraction, hiding unnecessary detail while not constraining you.

Last words from McConnell’s “Keep it simple” article: “Neither hierarchies nor abstractions reduce the total number of details in a program — they might actually increase the total number. Their benefit arises from organizing details in such a way that fewer details have to be considered at any particular time.”

Firstly, by “all of the above”. But working towards:
The solution humanity found to encapsulate complexity, is languange. Google uses language to search and organise millions of pages.
At the same time developers are lazy to write/update docs. So to keep docs small and easy to update, keep the code small and simple (and testable).
By testable I mean you should be able to prove it works, if not, make it simpler/break it apart.
But then the complexity moves into next layer – how to combine these objects without create spagetti. The solution I think is to realize that spagetti is unavoidable, and therefor to document it in such a way, that the documentation can create the links. Therefor it stays searchable as language (human readable) and need not be “revised”.
The idea that “test” and “deploy” becomes part of “dev”, becomes a reality then.
The problem is to convince the hardcore coders to accept a new/”non-std” environment.
Working towards “declaritive” dev, rather than procedural/OO.
Still, it enables me to put whole systems in place, without bugs, in a few hours…

Undeniably consider that that you said. Your favourite justification seemed to be on the internet the simplest factor to take into accout of.
I say to you, I definitely get annoyed whilst other folks consider concerns that they just do not recognise about.
You controlled to hit the nail upon the top as smartly as defined out the whole thing without having side-effects , people can take a signal.

In the online sales business, aesthetic is very important. Designing a high quality,
SEO friendly e-commerce site is vewry easy annd can be accomplished in a few days or anyone
can simply go to e – Bay where they can have their online
business access. However, you can sell your gift items
to customers as well but that needs more investment.