Forem: powerwebdev

A small philosophical consideration of the connections between code quality and team satisfaction

powerwebdev — Fri, 17 Jul 2020 13:22:03 +0000

I want to share a few thoughts on the connection of code quality and the good cooperation among teammates with you. These are based on my personal experiences in work life and on some articles I recently read, dealing with difficulties and conflicts with teammates.

Do these two topics share any connection? I think: Yes.

Let's start with the topic of good cooperation. I think that most of you will agree that software development includes team work for a large proportion. And, although this is not a guarantee that the result will be a good one, it is way more fun and there will be minor stress, if everyone gets along with everyone else.

But this is not always the case. It can't be because we all have different mindsets, different culture, education and different notions on what is good and what is bad. No wonder that there will be minor or major conflicts that disturb a nice working environment. However, in a professional environment we somehow have to deal with this. There are lots of articles and books written about this topic (even some here on dev.to). Thank god, because our daily work takes so much lifetime and it would be a pity if we waste it on only dealing with personal conflicts every day.

I recently thought that the code quality has a major influence, not only on the software quality, maintainability, etc., but also on our being together as human beings.

As I already mentioned before, software projects can be stressful (or most often are). And when we are stressed, we don't want to lose time. And this is where code quality comes into play.

In a stressful situation (e.g. time limits in a project, tc.) we don't want to lose time having to understand what our teammate did. We don't want to lose time by having to ask, getting a technical explanation that we don't understand immediately. This makes us nervous, stressed and angry. Often resulting in things that we say that we don't mean, up to thinking that our teammate didn't understand anything and is a complete idiot. And here we are: Serious conflict!
Does it help us in making progress, feeling good or work in a peaceful environment? I don't think so ...

By keeping our teammates in mind when we produce source code and try our best to keep it read- and understandable, we are able to reduce a great source of conflicts in our team. It also has some positive effects on the software itself (maintainability, extensibility, etc.). If we try our best to write our code in a readable way (and the readable way most often is not the one that is shown in tutorials, or technical explanations of new technology, etc.), we allow our teammates to better deal with stressful situations. Allowing them to quickly understand what we did and therefore removing a source of conflict. We give them back time that they are longing for! And having more time for other things reduces stress.

It is the same with books. Do you want to read books that are difficult to read or that you don't understand? No! Do you want to read books to get angry? No! Do you continue to read books that are difficult to understand? Normally not! (Ok, normally you don't have time constraints on reading a book, but I think the comparison is still a suitable one).

Focus on your work, use the existing technologies, apply your skills, but also think about the other teammates that will have to work with the source code you produce (the ones that represent you when you are on holiday, the ones that subsequent you when you move on and the ones that have to maintain your work).

A professor of mine once said when I attended a lecture in university: Wouldn't it be great if we would be able to write source code in the form of poems by Goethe or Shakespeare? This would be the ultimate goal of writing source code. Of course this is a total utopia, but I never could forget this sentence because it really has some truth in it.

Therefore, every time you write some code, also think about your teammates: Put your own ego back, avoid complicated constructs that show how brilliant you are. It will result in a much more productive and peaceful work environment.

I hope you could follow my thoughts and grasp the idea behind my thinking. Don't focus too much on new technology, also try to improve your code writing skills and therefore provide you and your teammates a peaceful and respectful co-working time!

I'm looking forward to your comments and thoughts about this!

An introduction to the concept of design patterns

powerwebdev — Thu, 02 Aug 2018 05:39:29 +0000

There are so many different definitions and opinions around on what design patterns are and all seem to be (more or less) different. Sadly, most of them lead to a wrong view on design patterns that put them in a bad light. In fact there is a very precise definition what a design pattern is and what it isn't. I'd like to summarize this here:

What exactly is a design pattern?

A design pattern is a precise description of a best practice, or a written down collective experience of multiple developers. There is a certain rule that defines when a design pattern can claim itself as one: The rule of three.

The rule of three says that a pattern has to be used in at least three independent systems. In the best case by developers that have never talked to each other before.

A design pattern can never be invented! It is found or identified. If a single programmer describes his own best practices on how to solve a problem, then this is very nice of her, but it is not a design pattern. Even though it is written in a structure commonly known from the Gang-of-Four design patterns (the structure alone does not make a good design pattern).

Design patterns commonly are written in a so-called template (a predefined structure), which has to be proven over years to be able to precisley transport the content and the pattern's idea. The structure is not fixed and can vary from pattern to pattern. There are only three sections that must be present in every design pattern:

Context: Definition of exactly when and in what circumstances the pattern can be used.
Problem: A precise description of the problem that has to be solved.
Solution: Right, the precise description of the solution to the problem.

The keyword here is precise. It is difficult to write a design pattern! Therefore, there are many conferences around the world that are here to help each other to identify if something is really pattern and how to describe it. These conferences are commonly known as "PLoP" conferences. There, people meet in so-called writers workshops and intensively discuss the text of patterns from different viewpoints. A pattern that has succeeded this process can generally be accepted as of high quality (which does not mean that the software automatically results in high quality, just because you applied the pattern). If you want to get a feeling why it is so difficult to write a good pattern, I can recommend you this paper that explains how you can write a pattern for "a doorlock", a thing everybody is familiar with. When I read the pattern, I'm always amazed how many details have to be taken into account to make this pattern work.

Design Patterns not only exist for software development. In fact, this concept has initially been developed for buildings architecture. Nowadays you can find patterns for software development, buildings architecture, cooking, education, organization in life, etc.

There are many more detailed aspects of a pattern, but these would go into too much detail for now. For example, when is a pattern a "classical" design pattern, or what is the difference between an architecture pattern, an architecture style, an idiom, etc.

What it is

A description of a best practice of collective experience.
A context-problem-solution construct that is very precise.
A problem solution that has been discussed by many people (normally, experts in the field) and accepted as a viable solution.
A way to document a best practice and hand it on to other struggling people.

What it is not

A description of a best practice of a single person.
Some kind of code structure, because patterns exist not only for software development.
A pattern normally does not describe solutions that are obvious (it is important to note here that patterns can become obsolete, because especially in software development new or improved languages / frameworks can make the solution obvious).

I'm happy for your comments to improve this list.

Good books on design patterns

The famous Gang-of-Four object-oriented design patterns: Design Patterns: Elements of Reusable Object-Oriented Software; Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides
Martin Fowler: Patterns of Enterprise Application Architecture
The complete POSA series: Starting with "Pattern-Oriented Software Architecture, Vol. 1: A System of Patterns"; Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal

Be careful when you buy books that have "design patterns" in its title. Many contain only solutions that someone thinks are design patterns, maybe even having a negative effect on the credibility of design patterns.

Further resources

Many software developers are mainly familiar with the patterns from the Gang-of-Four book, but in fact, there is a vast amount of patterns out there. You can search the conference websites, for example EuroPLoP, most of the patterns are freely available, or the library of the Hillside Group, an organization dedicated to the creation of design patterns.