The Path to Develop Professional Programming Skills
The effect of software architecture on professional skills
What does it mean to become a professional programmer? Do we become professional by just working for long periods of time on some piece of software? How does elegantly structured timeless software get programmed?
Professional development includes any tool or technique that makes you more productive as a developer, your work less vulnerable to failure, or your code more understandable to your teammates. [1]
Here in this article, I would like to take you through a journey of questioning the very meaning of professional software development. Here we focus on the techniques over the other parts to understand the way the timeless software architectures build.
The Coupling Problem
If you’re like me, you know that something’s wrong with the way most software is built and maintained but you’re having trouble finding the hard facts that might lead to that conclusion.
Beyond Legacy Code — Out of Chaos
The most widely encountered problems in modern software are the problems raised when it is expanded. As we start to introduce additional features, the legacy code pile hidden behind the scenes increases exponentially.
The problem is generally known as hidden coupling or tightly coupled components. Here the basic interpretation of the tightly coupled code is that in order to change one piece of tightly coupled code, we also need to change different parts of the code as well.
The more the modules of software have hidden coupling problems, the more time it takes to introduce new features.
Grow the software like plants
As we dive into the problem, we are able to understand why it is so hard to create elegant architectures.
The architecture is not something that the software architect can achieve on their own.
The programmers of a software project, with every single line they code, also make architectural decisions about the project whether they realize it or not. The more the programmers of a software project are aware of the importance of their decisions, the better the architecture will grow.
“The actual architect of any software project is those who write the code.”
Robert C. Martin
As it has been observed by many professional programmers and architects, the software isn’t something we can design upfront.
The software has its own lifecycle. It starts from the very basic, the single object form, to quite complicated, millions of object forms. Along the way, the software is grown as the programmers and architects of the software guide the progress.
Uncover The Architecture
One of the core principles of growing elegant software architectures is being able to test and experiment with the architecture. If we can not experiment with the features, we probably can not find the optimal path for our software to grow.
“The software architecture is the most valuable part of any software.” Robert C. Martin
The architecture is the structure of the software that lets us write the functionality we want with the least amount of code.
The more code we have, the more problems we expect.
Put The Testing at The Core
To be able to keep the amount of code low, and the structure of the software elegant, we constantly need to refactor (change the code structure without changing its behaviour). Here the test-driven, refactoring-based software development is often practised by using the Test Driven Development(TDD).
When we place the TDD to the core of our software development cycle, we see our software is growing on its own, without needing an upfront design.
As we write the tests, the software grows on its own.
Surround Yourself Around The Domain
It is important to care about where we test first. Because if we test the non-essential parts of our software, we may end up with totally different software from the requirements of the software project.
That is why it is important to surround our tests with the domain of our project.
The domain-related features should be tested first.
After making sure domain functionality is grown nicely along with the software, we now can move on to test the controllers of the software which provides the communication between the dependencies.
Reach to High-Quality Tests
As we try to test our software around the domain of our project, we feel more and more the need for the dependencies. The dependencies are those entities that contain functionality we would like to use.
It is quite challenging to write separate entities that are capable of doing the job on their own.
Also, as the quality of our tests gets higher, the less likely we will have problems with the development of our domain objects or controllers.
“It is important to be able to distinguish between low and high-quality unit tests as well as being able to write the optimum type of tests in place.” Vladimir Khorikov
Knowing where to write integration tests, end-to-end tests, and unit tests is quite important. Additionally, the knowledge of test objects(like mocks and stubs) gives us more power over our tests when we try to guide the software towards elegant architectures.
Always Go Clean
The Test-Driven Development and its refactoring phase lead to naturally grown software architectures. While it is quite important to grow the software products in a natural way, it is also important to clean the weeds around the software architecture. (Kent Back’s analogy)
While refactoring, the naming of anything in software needs extra care.
As we develop the entities, their optimum name will change as well as any method, function and variable name within it.
Naming is everything.
If we do not care about constant cleaning of the software architecture from different directions, we may still end up with unintended results with hard-to-maintain software.
That is why our constant refactoring phase must try to keep the software as readable as possible.
Refactor to Design Patterns
One of the subtle and elegant ways of refactoring is to refactor to design patterns. As we implant the optimum design patterns in place, as well as renaming them appropriately, the software will start to have much more elegant architecture.
“The design patterns will provide much better readability to your software. But, don’t be so impatient to incorporate the design patterns in place. ”
Allen Holub
The more we delay the architectural decision of the optimum design pattern, the more educated decision we will make.
Here as Robert C. Martin states the job of the architect is to delay the architectural decisions as long as possible.
The later, the better.
Go From Micro to Macro
One of the downsides of deciding early is the liability of the decision. The early decisions will inevitably make us incorporate macro-level objects into our micro-level software architecture.
It is like trying to teach calculus before teaching to multiply numbers. The software won't be maintainable if we decide early in a particular direction.
The important thing to point out is that the software should grow incrementally rather than quickly. Trying to incorporate the database or some other big entity into micro-level software may damage the way the software grows.
Apply Design Principles
When we start to question when should we decide on a particular aspect of our software, the design principles help us along the journey. Otherwise, It is quite challenging to know when to decide on a particular architectural decision.
We can be sure about the timing of an architectural decision when our decision doesn’t lead us to violation of any of the design principles.
There are various types of design principles. Some of them for coding, architecture, testing, and even organizational structuring.
Using the design principles in their place lets us delay the non-urgent architectural decisions.
As we start to decide on time, our software architecture starts to grow elegantly.
For example, structuring a unit test by using Arrange-Act-Assert(AAA) pattern makes you realize the holes in your objects. The hints will let you know what you need to do in the next refactoring phase. The unending hints will guide the software in the path towards elegant architectures.
Use Abstract Thinking
The Less is More.
The core part of any programming paradigm is that they teach us we can achieve more by using less of the programming constructs.
While one may think, it is not possible to program in an object-oriented way in a programming language like C, on the contrary, one may create a higher level of implementation of the object-oriented paradigm.
Likewise, any programming paradigm can be practiced in almost any language given the language does not enforce a single programming paradigm as the functional programming languages do.
By utilizing the abstract thinking skills we acquired through Object-Oriented Programming, Structured Programming, and Functional Programming, we can form higher-quality software architecture.
The important thing is being able to detect the optimum style of thinking for a given software abstraction layer.
For example, the domain objects of our software well may be programmed in a functional style while the controllers are implemented in an object-oriented way.
Go Agile
The agile software development technique is the technique that aims to reduce cycle time which is the time between the ideation of a feature and its implementation.
True agile development is practiced when we are able to meet the changing requirements in a rapid fashion. While developing agile software is not easy, there are some hints that let us know we are doing well.
- Small Releases
- Incremental Development
- Automated Builds
- Maintainable Code
- Reduced Cycle Time…
Apply Chaos Engineering
While going Agile, using Test Driven Development, incorporating Design Patterns and Design Principles into our software architecture helps us develop elegantly structured software, there are still some problems.
What will happen if one of the dependencies suddenly goes out. Or worse what will happen when the place where we store our version control system or data storage blocks us?
This is what happened to the Iranians when America decided to ban all the Iranians that use American-based software. Most of the Iranians couldn’t reach their own GitHub repositories or their Amazon storage.
As we live in a world where trust is not seen as valuable, we need chaos engineering. Chaos engineering is a term introduced by Netflix.
When Netflix decided to move their storage to Amazon, they had doubts about Amazon-related problems. That is why they have come up with a subtle solution to the trust problem by introducing Chaos Monkeys.
What the Chaos Monkeys do is that they create chaos. If the architecture can preserve its own state when chaos arises, then one can make sure that the architecture has successfully grown to a bullet-proof form.
That is why the Chaos Monkeys experiment with all of the software dependencies. Unlike the testing where we try to test the ‘sane’ domain problems and the communication between unmanaged dependencies, with chaos engineering, we experiment along with all the different possibilities in all the different dimensions of our software architecture.
Become Professional Programmer
As a computer scientist trying to improve my programming skills, I have tried to show you a path for those who need to upgrade their programming abilities from intermediate towards to professional.
For me, learning these areas are a non-ending journey. With every book I read, I create a much better model of programming in my mind.
Here last but not least, while the books provide comprehensive details about the methodologies, it is also important to grasp the overall software development before getting started.
That is why I recommend you to first start with the Clean Code Learning Path which mostly consists of the videos of Robert C. Martin which is the writer of most of the books I have mentioned in this article.
Resources
All the resources mentioned in this article can be reached by using one of the best web libraries: SafariBooksOnline by O’Reilly.
References
[1] O’reilly, “What Do We Mean by Professional Development? | Driving Technical Change By Terrence Ryan” O’reilly, 2022. https://www.atlassian.com/git/tutorials/what-is-version-control (accessed Feb. 07, 2022).
