Lessons Learned in Software Development

“A highly developed values system is like a compass. It serves as a guide to point you in the right direction when you are lost.”
― Idowu Koyenikan

Photo by Vlad Hilitanu on Unsplash

Design Patterns and Principles.

It took some time and experience for me to realize that I don’t fully grasp the benefits design patterns and principles have to offer, however when the lights switched on I found a whole new world of developing solutions in a much more structured and controlled manner. The more time I spent on this the more I could understand this matrix, finding common and often shared solutions became clear for many different problems.

Design patterns are made up of different components that are repeated and reused in the same way throughout your software. They are single coherent units that flow seamlessly throughout design and execution without a flaw.

Good design patterns and principles are technology agnostic. This means software architecture can be designed without being aware of the technologies involved. Technology has its own set of advantages and disadvantages who’s influence we don’t want in our architecture for the fact that they will create a dependency on a technology that will change beyond our control in the future.

An agnostic design system allows us to create design standards that we can universally use across different design teams and products and it also acts as a library on how we as an organization design software and solutions.

Teamwork.

In most cases, designing software solutions is not up to a single individual, it is up to a team to share; domain knowledge, experience, and ideas on how to overcome problems and define solutions. We all have different backgrounds in education and experiences that create a unique frame of reference for each of us, as a result, we have a unique set of principles where we as individuals find value. It is essential to create a shared or overlap set of these principles within a team as they function as guidelines for daily decisions and behavior.

It helps to understand the purpose of the team which in return will help define team principles as well as understand what each individual my consider as a critical principle. When these principles are decided on by the team it is key to integrate them into the team’s daily processes and practice to make them visible and effective. Principles are regularly evaluated to see if they still add value. Lastly, address core value violations promptly and professionally, continued bad behavior ultimately undermines the team and creates more responsibilities for others. An example of a team principle could be to always automate a task that is manually repeated three or more times. Or to review and refactor your solution with a peer before merging it into the mainstream.

Trade-offs.

Every solution has its advantages and disadvantages, therefore, there will always be trade-offs, especially when working in a team. In order to determine which solution best suits the problem, we need well-formed arguments as well as avoid assertions without providing any foundation. Solutions define the quality of your product and often have permanent consequences. It is worth spending time on constructing decent arguments in order to understand each other clearly.

A design trade-off framework can help to structure and document arguments for solutions that can then be compared objectively. They can be worked into the principles and values mentioned earlier and we could also use principles and values to determine which advantages we prioritize and which disadvantages we definitely do not want in a context that matches our user stories and client requirements.

Let’s consider the argument structure: Solution X has these advantages but has these disadvantages in the context of z. When we apply a universal structure to our arguments and combine it with a universal set of principles, all team members conform to, it becomes significantly easier to understand and evaluate a set of solutions. We get a better understanding of the developer’s argument by evaluating the context in which a solution is proposed, as soon as the arguments are understood we can weigh up the advantages and disadvantages to make a better-informed decision. Team members move closer to speaking the same language and understanding each other, functioning as a single coherent unit that flows seamlessly.

Reference: