3 Code POV Secret for Better Code

free-photos

The 1st POV is Your Self
The 2nd POV is Your Team
The 3rd POV is Your Stakeholder

Following my previous post for seeing code as an art, let’s look at the different POVs a code can have.

Code for Yourself

The focus for this code is the result and having the correct output. The lack of documentation is the most common symptom here. There was no need for any documentation as the coder codes for themselves. Complex algorithm can be written and maintain easily by the individual.

In the enterprise system, we sometimes see this type of code as part of ‘legacy’ system. It may also be part of a system that has not yet been cleaned and refactored. The code works, and do what it is supposed to do. When we need to modify or change the code, extra caution is needed. They may look confusing (if you are not the coder), and difficult to understand, change and modify. But they work and produce the correct output.

The problem with the code in this view is they don’t communicate much to others. Even though they work correctly, if you are not the coder, it may be difficult to maintain and extend in the long run. In this case, they are added to the technical debt (also see: technical debt is not a Code Mess!).

This view is the quickest to get a working solution and to be able to get a confirmation of the correct solution. The very first person who needs to understand the code is the coder themselves.

Code for Your Team

In this pov, the code is more maintainable and generally easier to understand by other developers. Patterns and code intentions are more recognizable and documentation exists in one form or another to help those communications.

We see this code more often as part of a system that we are currently working on and we see them often in production as well. The code in this pov are more visible in a team that does code review regularly. Debugging becomes easier and any developer in the team usually would understand the code. With the occurrence of design pattern and documentations, they may also be easily extended by other developers.

The code usually does not yet entirely reflect the business or the stakeholder intention. This is because the code is usually created when the developer does not fully engage or understand the domain. Only partial business knowledge are reflected in the code.

Quite often, this type of code may be enough for the company to move forward. Technical debt accumulates at a reasonable pace. The code itself already have a certain degree of extensibility and easily understood by other developers.

The side effects of this POV is that any changes in the business may take longer to implement. This becomes more apparent when we start telling them “We can’t do it in this timeframe” for a business rule request change that made the stakeholder to actually thinks “That should be simple”.

Code for The Stakeholder

The code in this pov can be difficult to understand at a glance. This is because the code actually reflects the domain and may use the language and rules of the domain itself. The gap in understanding the code is actually in the business knowledge, rather than programming skills. The code describes the behavior that the domain intended. In Domain Driven Design they are part of Ubiquitous language, and Martin Fowler technique of Domain Specific Language also helps to achieve this.

A software developer cannot create a code for the stakeholder alone. (With few exceptions for example if the person himself might own the business).

The code created for stakeholder contains the problem knowledge of the stakeholder. Producing this code is time-consuming and depends on the skill of the developer to absorb the business itself. It takes a collaboration between the stakeholder and the developer. Without the collaboration, creating this code may be nearly impossible.

The trademark of this type of code that, because it follows the business, it is very easy to change according to the business. When the business rule changes, the code and implementation can change accordingly and confidently. With code in this pov, even other developers in the team will be able to make the change confidently without fear of side effects as the change should only affect the context the change it is on.

The skill to transfer the business knowledge to code takes years to practice and forever master. The aim shifted from just creating a working code to a business and domain modeling. Microservices as an approach in Martin Fowler blog is a good example of how this can be achieved.

Conclusion

Developing an application is a complicated thing. Developing an application that just works, is easy, but they will not last long and soon will become a ‘Legacy’ that needs to be replaced. An application for a particular business must follow the business growth strategy. To be able to do that, the code created, must be done in a way that can follow the change in the business.

Codes exist to assist the business, not the other way around. In fact, in most discussions with the stakeholder, it actually helps the business to questions its own process and procedure that must be followed. As a developer, it is our job to identify how to support the business to expand and grow quicker from the technology pov and not to limit them.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s