Taming The Destroyer Of Software – Part 3

Today we’ll conclude our journey into Unnecessary Complexity (UC) and how to prevent its accumulation in maintained computer software. Programs that don’t have their UC managed will turn into Legacy Code, which becomes increasingly more difficult to modify as the accretion of complexity accelerates. Unnecessary Complexity truly is the scourge of our software systems.

On our journey, we’ve seen a way to write new code that minimises the introduction of UC in our systems. We also looked into how we could reduce UC in systems that are already adversely affected by high complexity. 

Now, we’ll discover the third pillar.

And it is simply this: To prevent or tackle UC, we must also know how to program well and apply this skill constantly in our work. We must care about the code and do the best job we can. Perfunctory programming is unlikely to lead to excellent, low-UC outcomes.

So, what exactly do I mean by knowing how to program well?

One does not become a good, experienced programmer, a Software Craftsman, by learning specific tools, languages, frameworks, or platforms. Knowing AWS or Azure and their SDKs does not make a decent programmer. Neither does it hurt to know how to develop an attractive web UI in Angular or React. Please understand that one can be a ‘bad’ programmer while still knowing all the ins and outs of such frameworks. 

Becoming a good programmer is about becoming aware and learning other knowledge. 

Like what?

Clean Code

How should we program at the lowest level of granularity: functions and data? For example:

• How do we name functions?
• How long should they be?
• How should we name variables?
• …

Many of my coding tips are about how to structure code at this level.

Furthermore, it’s necessary to learn and comprehend

• SOLID Principles (how to structure classes/modules)
• Component Principles (how to arrange components, the units of deployment)
• Clean Architecture (partition a system so it can be easily and quickly modified – modularity/pluggability)
• Code Smells & Anti-patterns, why they occur and how to fix them
• Design Patterns
• The different programming paradigms
• Unit Testing
• Agile
• DevOps
• and heaps more.

This material takes a long time to book-learn and longer to internalise. However, it’s worth studying. It makes this job less perplexing, more fun, more meaningful and worthwhile.