Subscribe

Simplifying software design

Staff Writer
By Staff Writer, ITWeb
Johannesburg, 03 Oct 2017

Software projects have two types of complexity: inherent complexity in the problem being solved, and accidental complexity introduced by the development team through poor design, misunderstood specifications, time pressures or lack of skill in a technical field.

So says Lorraine Steyn, co-founder and CEO of Khanyisa Real Systems, adding the aim should be to eliminate all accidental complexity, leaving only the problem that needs to be solved.

"In solving the problem, we should note that the human brain can only keep track of a limited number of issues at once. Think of it like mental juggling - if you have to keep too many conceptual balls in the air at once, you are more likely to drop one."

Modular design

According to Steyn, a key strategy for handling complexity is to break the problem down into smaller parts.

"In coding, we refer to methods, and the aim is to have any particular method responsible for only one behaviour (single responsibility principle). For instance, a method that stores some data into the database should not also be responsible for updating on-screen information. Good design is definitely modular."

She adds methods should be "loosely coupled", meaning that where the method is invoked in code, it should be given all the data that it needs to perform its function. "The method shouldn't be dependent on other methods, or even worse, on a particular program state. When there are many inter-dependencies between methods, we are back to juggling mental balls, and need to remember which other methods affect the piece of code we are writing, and what the next method might need from us."

Methods must be treated, as far as possible, as black boxes. "We know what they do, and what data they need to do it, but we don't have to know 'how' they do it and we especially don't want to have to worry about any side effects they might produce," she explains.

Pair programming

Steyn adds the 'way' code is designed is as important as the instructions that are written. "To really improve code design, try writing code with another developer. This technique is called pair programming. It turns out, not too surprisingly, that two heads really are better than one."

Pair programming consistently delivers better, simpler code design, as well as having a built-in review process, she adds. Code produced by a pair of developers is generally of higher quality (less bugs) than code produced by a single developer.

Companies might be concerned about the cost of having two developers for every task, but they needn't be. There might be an overhead to pair programming, considering the upfront development time, but it disappears if the full life cycle is taken into consideration.

Firstly, she says fixing code errors in testing, or even after deployment if they've slipped through testing, is very expensive. In pair programming, every line of code is being reviewed as it is written, and far fewer errors reach the testing phase.

Next, no developer types 100% of the time. "They type a bit, and then they think a bit. When two developers sit together, they are generally working at a higher pace than one, because one is thinking while the other is typing, and vice versa. On this point, developers report that pair programming is very tiring because it is so intense," she explains.

In addition, Steyn says when two developers discuss their code design as they work, they naturally arrive at a better design. Just having to explain what you want to do usually helps to clarify uncertainties. Together, they will produce a simpler design that is more maintainable, modular and efficient, than most developers would arrive at on their own.

Finally, pair programming is great for knowledge-sharing. It is always a risk when only one developer knows a specific piece of code, and with pair programming, you always have at least two who can now support and maintain that code, she adds.

Share