Complexity can hide bad practices

Another reason to keep it simple is that simplicity often highlights poor design or implementation at an earlier stage.

I was recently reviewing some code written by an offshore development team. In examining one particular set of functionality, I found that the complexity in the way they had implemented their solution made it hard to determine what was going on.

By refactoring the implementation, with the aim of simplifying the implementation, I gained not only a better understanding of what the software was trying to do, but uncovered a number of strange behaviors hidden by the complexity. As a very simple example, it turned out that in the course of the implementation, the code did the following (this is intentionally simplified to illustrate the net effect):

String count = “32”; …. cut lines of code … int i_count = Integer.parseInt(count); … cut lines of code … String countStr = i_count + “”;

Without the intermediate int value actually being used.

Simplicity can be copied

Yet another reason to keep things simple is that the first time you design and implement a solution to a problem you may well be doing so to solve a particular problem.

However, this may then become a blueprint to others on how to solve the same or similar problem elsewhere within the team, project or organization. If the solution you create is as simple as it can be, then not only will this approach permeate across the organization, but that "copied solution" will be easier for others to understand.

You'd be surprised the number of times I have heard the answer "I did it that way because that was what was done before" when I have asked (particularly more junior developers) why they adopted a particular approach. When this is followed up with a question about how the solution works, on more than one occasion I have received the answer "not sure really".

Avoid over-engineering

My final comment on keeping it simple is that you should be careful not to over-engineer solutions. That is, you should only implement what you need to implement and not attempt to anticipate future needs. Not only may those needs never actually materialize, but they also make the software more complex and more difficult to understand (not least as anyone looking at the code later on may fail to understand why the additions were included).

Conclusion

There are many reasons for keeping things simple, but there are also exist a number of "pressures" that may limit the simplicity of the solution. These pressures can include the desire to produce some fun code or to “impress other programmers” with your skills. At the end of the day, though, it’s the simplest code that may actually be harder to write than apparently more complex - but potentially less thought out - code. ®

15 comments posted — Comment period finished