How to talk about technical topics to other developers?

The most important soft skill for developers is the clear and effective communication. There are several situation when this skill is really needed. It is simply because the most of the projects is done is a kind of team work, so you need to simple talk to the other team members. One usual topic is to discuss about technical topics. Unfortunately a lot of developers are missing such skills and that’s why team work is becoming non effective in several cases. Let’s see how should these discussions to be done.

Why to talk about technical topics?

I often meet developers who think that it is simple a waste of time to talk about technical topics, just let them work and they will implement everything. This way of thinking is really not fitting to the modern ways of software development. First of all it is totally against teamwork. Additionally at a company usually the developers have different levels of knowledge in different topics, so really often knowledge transport is needed: you need to ask more experience colleagues for better solutions and you need to teach the less experienced ones to let them work more effectively.

The other point is that it is not always trivial to find the best technical solution for a problem. This topic is totally not black and white. For most of the solutions you can not tell that this is better, than the other, because it is not a scalar topic. Most of the cases you can tell for example, that this solution is better in runtime, than the other, but the other solution is using less memory. In our current situations we don’t have issues with the runtime, but we have a lack of memory, so let’s choose the second solution.

To be able to talk on this level you need multiple alternative solutions with all pro and cons. And to collect these ideas usually you need to talk about them, to talk a lot.

There’s also a point at quality: to improve software quality reviews are part of the daily work and at reviews you need be able to describe in an effective way why do you think that your solution is good or why do you think that the used solution is not good.

That means communication about technical topics is part of your daily work, if you don’t want to waste so much time you should learn how to do it in an effective way.

How to coach colleagues?

Typical situation that there’s someone at the company who has really good experience with a specific topic and he needs to support the other colleagues working with this topic.

In this case you need to do technical coaching to the others to support them to finish their work. It is also important for you that they are able to finish their work and it is also important that they are understanding the how and the why and they are not asking the same questions in two weeks again.

In this situation first try to understand what if the level of knowledge of the others. You can easily do it by some nice questions: “Do you know how this and this is working?”. But important: don’t try to make them feel that they are stupid just because they have a lack of knowledge. After that try to clarify the theory with all the reasons what are you doing and why. Once it is done do an example or a small part of work together, but don’t finish the work together, let them try it on their own, but stay always open for questions.

For coaching pair programming is also a good approach. Sit together in front of the computer. First you should do it and clarify each step. After a while let's change but still tell what should be done. With time you need to talk less and your partner needs to talk more.

How to ask colleagues for support?

The next situation is you are blocked in work and you need support from someone more experienced in the topic. First of all don’t ask as soon as you’re facing with difficulties. First try to understand what is exactly the problem and why is it not working. Also search for that in google and check for possible solutions online. If you can not find a working solution within a certain time don’t waste your time anymore, ask for search. Before asking for search try to summary what is really you problem and your question. Make sure if the chosen colleagues has some free minutes and he can listen to your problem. When you are asking don’t waste in details, because if you are giving a lot of unnecessary information it will be more difficult to understand your problem. But also take care about enough details. I got questions really often in a similar way, like: “I would like to push a shared_ptr as parameter and it is not working”. Ok, come on, why are you pushing the shared_ptr? Shared_ptr of which type? Is is const? What does it mean, it is not working? But the best if you are showing simple your code and clarifying what is your goal. If your code is far too complicated try to create a minimal example where the issue appears by removing irrelevant code part. You also need to understand that even if the other one is expert of the topic, he needs to understand your goal and problem first and it is not so easy.

How to ensure colleagues about your idea?

Also really typical if you have an idea about how to do something. It is always good to discuss about that with your teammates before implementation, since it is possible that even if you think it is a good idea in practice it has some disadvantages which are still not clear for you. It is also important if the other have other solutions listen to them, let’s try to understand their purpose and let’s try to understand what are its advantages over your solution. Then try to think what are the possible disadvantages and point out them. If you are talking about your idea first describe what is the problem to be solved and what are its main challenges. If it’s clear for everyone you should tell your idea step by step. At the end you can point out why do you think that it is a good solution, but you should also mention if you see some disadvantages. It is also good if you are talking about alternative solutions and at the end you are telling which one seems to be the best for you. If the others are criticizing your solution try to understand their reasons and ask them for suggestions. If your idea is to complicated it is good to create some diagrams of minimum working code example.

How to give a feedback about a technical solution?

If you are on the other side and one of your colleague is talking you about his idea it is also not always easy to answer in the right way. If you agree with the solution then it is easy, underwise it can be difficult.

Even if you think that the idea is super stupid you need to trust your colleague and his idea. You need to first understand his idea fully and also the reason why he is suggesting it. If you still think it is not the right way just point out why you are feeling uncomfortable with the solution (what are your fears) and try to give some solutions how these issues could be resolved. Never forget to mention the parts of the solution which you like. For example:

“This solution would really be well-structured and clear, but I think there are some corner cases when it wouldn’t work correctly. But if you are changing this part to that it would do what is required.” Something like this.

Summary

Communication is never easy, especially between developers and about technical topics. Try to always use the rules of assertive communication, give reasons and trust the others and you will see, it will work and it can really burst your career.

First experiences with Large Scaled Scrum

Two months ago I started at a new company. At this company we are following a working model which is much different than anything else I experienced before. This working model is called Large Scaled Scrum (LeSS). At the beginning it was very strange for me, it was totally against the mindset I had before. Right now I think I could already change my mindset partially, but I still have a lot of challenges.

What is LeSS?

LeSS is an Agile framework which is scaling SCRUM for really huge projects. It is trying to keep the organization as simple as possible without a big hierarchical system. It is mostly following the classical SCRUM events (sprint planning 1-2, daily standup, retrospective, review, backlog refinement etc.). Main values the are multifunctional, self-leading teams, learning and flexibility. You can find more info on page https://less.works/.

What does it mean in practice?

What I am describing now is the adaptation used in our organization. It can be that it is sometimes differing from the official theory of LeSS.

As I started at the company I became an official LeSS practitioner by taking part on a 3 day long training. Here I became familiar with the whole theory. Afterwise I joined an already existing team.

Our team has 8 developers and a scrum master who is also taking part in the development. Our task is basically end-to-end development: clarifying the tasks, architectural decisions, development, testing etc. The main concept is that none of the tasks are assigned to individual developers, they are all assigned to the team. Usually we have less tasks than team members and we are doing pair or mob programming (programming in a team). That means we are not usually sitting alone in front of the computer. The goal is that all team members should have an overview on all topics which are done by the team. The responsibility is also shared within the team.

Why is it so strange for me?

I have been already working in working models where I had my own task, which I was responsible for, I needed to implement it, I needed to hold the due date and if there was a bug in my code I was responsible to fix it. Additionally in the last time I was a technical leader in my project, so I was also responsible for the work of others. One hand I enjoyed this kind of responsibility, it made me feel good to tell that: “this is a functionality implemented by myself”, on the other hand it was of course stressful as well.

In this current working structure it is not the case anymore. On most of the tasks we are working with 2-3 team mates. Really often the code is note written on my computer, it is not pushed with my name. I am not feeling myself so much responsible anymore.

It also involves an other big difference in the way of working: earlier I was often sitting alone in front of my computer, listening to music and not talking to other hours long. It is not the case anymore. 90% of my time is about communication, sitting with someone and talking about the problems. I totally did not use to do it in this way.

In fact I’m learning a lot about different topics, working on many tasks, but I will never become the expert of the topic, I will never become the owner of a functionality.

What are the advantages of LeSS?

There are several advantages of this way of working what I can see. For example, due to the shared knowledge and responsibility, if someone becomes sick or has a holiday that does not have a big effect on the results of the work: the others have also all the knowledge, so they can just continue from where it was finished on the day before. And anyway multiple people are working on the same topic, so minus one does not make a big difference.

It also saves a lot of efforts at knowledge transfer. I had always bad experiences with situations when someone left the team: all his collected knowledge needed to be transferred to the others, it took a long time and it was not always effective.

In this model it is also easier to give tasks for junior colleagues: they can join the more experienced colleagues and learn very fast.

Due to the lot of pair and mob programming the code quality is also better and a lot of good ideas are coming up during talking about the tasks.

Also by lacking hierarchy the company is saving all costs of having multi-level management.

The stress caused by due dates is also pretty clear less and the time spent by randomly surfing on the internet in working time is also much less due to the pair programming.

So I can see pretty clear advantages of this way of working.

What are the biggest disadvantages?

On the other hand it reminds me a bit on the theory of socialism: shared responsibility, everybody is just doing his best. But in the end no one is really feeling himself responsible for holding the due dates, solving problems or making technical decisions. Really often we are just talking hours long about alternative solutions and no one is there to finalize the decisions, so we are just talking and talking and not making a clear decision.

I’m also lacking the career opportunities: in classical working structures there are hundreds of roles which can be overtaken and which are making some changes, some step further into the career, here I can not see much of them.

I’m also lacking the feeling that I can tell: “it is my code”. Maybe it’s childish, but that’s what I feel.

I also have issues with the communications: there are so many communication channels, that it is really difficult for me to collect all the relevant information.

I also have the feeling that the project is really lacking someone who has a good technical overview on the whole project, like a software architect. When we need to use an interface really often no one can tell us which interface is it and a lot of interface are duplicated.

Last but not least I would like to mention that the permanent pair and mob programming is really exhausting. It is really difficult. The team members needs very good social skills and a lot of patient, which is not typical for most of the programmers.

Summary

I didn’t expect that this change will be so big for me, it was also surprising for me that a working model can be so different from everything I experienced before. With time I’m changing my mindset and my feelings regarding this working model is also changing permanently. I am often asked if I think it is more effective, than classical way of working? To be really honest, I have no idea. We are loosing time by assigning multiple people to one task, but we are winning a lot of time by reducing review and knowledge transfer time. I would like to also clarify that these are my personal experiences, other developers may have different opinion about this way of working. I plan to write again about this working model after several months, maybe my opinion will change again.

From individual work to team work

Since the projects are constantly growing and the time pressure is getting higher and higher in the software business to walk alone on a project is not an option in most of the cases anymore. On most of the projects big teams are working from some people up to multi-thousand. But how are these big projects organised? Are the people working in a team or just individually . Are they really work in a team? Is it good if they are really work in a team?

The classical way of working

At most of the projects a projects is splitted between the different subteams based on some well-specified area: components, knowledge area, activity (architecture, testing etc.) or functionality. So each subteam has its clear job with well-specified inputs and outputs and they need to sync up sometimes with each other, but they are basically working independently.

How is the work organised inside a subteam? At all my previous projects the situation was the same: the wok was splitted up to smaller tasks and each task was assigned to a team member. That means each team member had its own task, own responsibility. Everyone was just working on his own tasks. The only interaction happened between the team members at the daily status meetings, at code reviews and if someone asked from help. But normally the team members were not technically deep in what the others are doing. It resulted the following situation: one hand you could working concentrated on your tasks, which was effective as far as you had all the necessary knowledge. If you stuck it took a long time to get help, because the others were also busy with their tasks and they needed time to understand what you are doing. Another difficult situation was when some became sick. Quite often no one else could finish his job without a really huge overhead. So it was always almost causing problems. It was also challenging when someone left the project. Most of the cases he had project-specific knowledge which the others didn’t have, so a knowledge transfer needed to be done. It was always difficult to work with junior colleagues, because they often stucked and lost days with trying to figure out their own solution.

On the other hand it was really comfortable that after getting familiar with the project you were able to work really independently, it was easy to work for example from home office due to the lack of interactions.

To escalate the problems the management was tracking our performance on a personal basis. That means if you wanted to reach a better number next to your name in the performance report you really needed to concentrate on your tasks and avoid wasting time with other issues. It was totally not productive.

The way of real team work

Now I changed to a new company and I’m working on another project. Here the way of working is much different. It is real teamwork here. The tasks are assigned to the team and the to a specific team member. Usually we are working on less task than the number of team members. The is no dedicated person the work on the specific tasks. It is really typical the 2-3 team members are working on the same task by doing pair or mob programming. So we are all sitting in front of one computer and working. It reminds me on my childhood as we were working with computer games with my friends, but we had only one computer. We are also changing tasks between team members frequently. It can be that one day you are working with one guy on one task and on the next day with other guys on another task. This structure is basically solving all the problems I mentioned before: the whole team is aware of the technical content of each topic and there is always multiple people who are deep in a specific topic. So that a sickness, a holiday or a change in the team does not mean a big problem. The junior colleagues can also work together with more experienced team members and they are learning really fast in this way.

On the other hand we often have the feeling that it is not effective at all what we are doing: three of us just sitting in front of one computer and talking about one easy class….hmm.

It is also mentally challenging: instead of listening to music and concentrate on the task, you need the follow and participate discussions all the time, listen to others opinion and formulate yours. This kind of close cooperation is also causing several conflicts between the team members. All things considered it is not so easy to work in such a structure, but I can see also several advantages.

In such a working structure you need to be able to communicate properly, describe your ideas and issues properly and to be very patient and flexible.

I have not the feeling that the best working model would be a hybrid model between strong teamwork and individual work. If you have experience with working in such a working model it would be nice if you could share them.

I’m new from the university - Let’s understand different roles

At most of the software companies there are several different roles: project manager, team manager, software architect, lead developer, technical leader, software tester, scrum master, product owner, junior software developer, senior software developer, system engineer, requirement engineer etc. If you are new in the world of software companies it can be quite difficult to understand the meaning of these roles. It’s because sometimes the same role has different names at different companies or the same name means different role. Plus some of these roles are really similar to each other, but still not the same. In this chapter I’m trying to give an overview about the meaning of these roles. But at some companies it can be different.

Trainee:

This is normally a position which you can take over as a student. Normally it’s a part time job and you can support the developer team with implementation of tools or smaller features. This is normally the first step of your carrier.

Junior software developer:

A junior software developer is normally a software developer who has less experience and can work independent on features and software components, but still need regular support and leading from the more experienced colleagues. You can take over such a position normally after finishing your studies/working for a while as trainee. This is really a good position to learn a lot about software development.

Senior software developer:

It’s up to company, but normally your next career step after being a junior software developer is something called simply software developer or you are going to be immediately a senior software developer. A senior software developer is an experienced software developer (usually has at least 5 years of experience), can solve problems independently, can choose between technical proposals, has a good overview on the overall development process, can make solutions for new problems as well. Normally a senior software developer should be able to support the junior colleagues.

Software architect:

A software architect is responsible for the design of a software. That means a software architect is creating software design and makes sure that all the implementation is following the design (normally it’s done by code reviews). A software architect needs to have a very good overview, needs to know the related technologies well.

Technical leader:

At some companies each project has a technical leader. A technical leader is normally someone who can take technical decisions and who is technically responsible for the product. A technical leader is most of the cases overtaking the software architect tasks as well.

Lead developer:

Lead developer is typically a role at smaller companies. It is usually a mixture of technical leader and project manager.

System engineer:

The system engineer roles exist usually at products which has a close relation to the hardware (embedded development etc.). A system engineer is usually not deep in coding. A system engineer needs to plan how the whole system will work: why inputs are provided in which format, what are the states of the system, which outputs will be provided, what are the corner cases and limitations of the system. The system engineers are using quite often some modelling software (Matlab etc.).

Requirement engineer/Buisness analyst:

A requirement engineer or buisness analyst needs to understand what is the expected behaviour of the software in different use cases and document them in a clear, non-ambiguous way. They need to think about corner cases as well. Requirement engineers are usually not deep in code. This role is quite often overtaken by system engineers.

Software tester:

A software tester is someone who is creating test plans based on the requirements of the system and after that runs manual tests or implements automated tests and book the result in the correct format. A software tester needs to understand the requirements well and needs to think about corner cases. Most of the testers know some scripting language and test framework for automated tests.

Project manager:

The project manager is responsible for the planning and tracking of the project from budget and time point of view. That means: it needs to be planned: what will be done, when and by whom and the project manager needs to track it. If something is going wrong the project manager needs to identify and help to resolve the issue (like needed trainings, missing inputs etc.). Usually the project manager has direct connection with the customer and needs to report the state of the project to the higher level management. The project manager is responsibility is that the project needs to be done in time and inside budget. At some companies the project manager activities are shared between multiple managers (one is only responsible for time planning and tracking, one is responsible for the budget etc.). The project manager has normally some technical knowledge, but most of the cases the project manager is not deep in code.

Product owner:

Product owner is a role in scrum projects. The product owner is the one who has a good understanding of the project goals and requirements and who is creating clear user stories from these requirements. The product owner is setting the priority of the user stories and well. The product owner is always available for the development team but is not part of that.

Scrum master:

Scrum master is a role in scrum projects. A scrum master is supporting the team to keep the scrum process. A scrum master can be a developer as well in the same time.

Team manager:

A team manager is responsible for a bigger team and multiple project. The team manager is responsible for hire new colleagues, do regular feedback meetings with the employees, identify needed trainings and send the right colleagues to the trainings, supporting employees to reach the next step in their career path, motivating employees, identifying and tracking goals for the employees, do resource plan between the projects etc. A good team manager has experience in development, project management and has good interpersonal skills.

I hope it helped a bit to understand these roles. But as I said there can be big differences between companies.

Efficient home office

One big advantage of working as a software developer is the possibility of working from home. Although it is possible practically most of the companies does not allow to do it for all of their colleagues and there are also many developers who doesn’t like to work from home. The companies are usually arguing with non-trackable and not effective work and with pure communication. The developers has often also problems with the same points and they also think that is a bit depressing to work always from home.

My first experience with home office is coming from right the beginning of my career. It was the last semester of my bachelor studies. I only had to go once a week to the university, the other days I was just working on my thesis, which was a software with documentation, and next to that I was a trainee at a small company, where I was working in remote mode. I got my tasks and once a week I needed to present my results. So I had two big topics to work on from home and my time schedule was really flexible. First I thought it will be a really great time. After some weeks I realized that it is not good at all. In the morning I didn’t wake up in time, as I woke up I didn’t start to work, I rather watched some series. I started to work just right before lunch, then I got hungry soon, so I took a long lunch break. In the afternoon I tried to concentrate on working again, but most of the cases some friends just called me to go out somewhere and I could never say no for such invitations. So I went out until late, thanks for that next morning I couldn’t wake up again. Usually the day before my meeting I realised that I didn’t have any progress, so I was working all night long. Some week before the due date of my thesis I also realised that it’s not in a good shape at all, so I was working all weekends long on that. After a while I was totally stressed, because I always had the feeling that I should work. Next to that since I had a lack of experience I often faced with technical issues and since there was no one around who could help, it took me long hours to find a solution or I needed to wait until the next week meeting and in the meanwhile I was totally blocked. All things considered it was horrible.

After this experience I tried to avoid to do any home office, I was rather in the office until late or requested for a holiday if I had any issue at home. The years flied and 5 years later I found myself in a totally different situation. In the meanwhile I collected a good experience in software development, I became father and with that I also changed my lifestyle. At the company where I’m working I had sometimes chance to do home office and in the previous time I did it a lot. At the beginning I felt myself a bit uncomfortable at working from home, but it changed, now I really like to do it and I realized that I’m more effective at working from home as sitting in the office. But to achieve it there are some points to follow.

1. Do follow a preset daily working time
   As normally you have any kind of working time what you are following (like you are arriving at 9 and working until 4.30 in the afternoon) set up your working time at home as well. You can save your daily travel time, it is already an advantage. So let’s decide that for example you start to work at 8 o’clock. Then really wake up at 7.30, have your breakfast and start at 8. Be strict to yourself. And let’s concentrate on working until the end of your working hours. Out of your working hours be also strict to yourself: do not work. That’s needed to be able to make a difference between your professional and private life.

2. Do have your proper workplace at home
   This is the point what I couldn’t achieve in our current flat, but it is also needed. You should have a seperate working place at home, the best if it is a seperate room, where you have your desk and a proper working environment with all your needs: good chair, big monitor, sunlight, proper temperature etc. Be here during your working hours and don’t be here out of your working hours.
   
   
3. Change your clothes
   

   
   Of course it’s nice to be whole day long in your pyjama, but in that case you have the feeling that you are at home and not at work. Change your clothes. Of course you don’t need business outfit at home, but at least take a T-Shirt and trousers.

4. Your family needs to understand that you are not at home, you are at your workplace.
   
   
   It should be also clear for your family that you are not at home during your working hours, even is physically it is not true. You don’t have 2 minutes to help, you can not answer a short question and you shouldn’t be disturbed.
   
   
5. Keep on communicate with your colleagues
   
   
   It is also important not to be totally isolated from your colleagues. Keep on communicating them with some chat client or through phone. It is also good to have a daily status meeting which is done through phone. With that you and your colleagues have the feeling, that you are not working alone.
   
   
6. It is not working without enough experience
   

   
   The other thing I realized is that as a junior programmer at the beginning of my career I got stucked really often. That time just googling did not mean always a fast and working solution. But to ask a more experienced colleague helped really fast most if the cases. From home you can of course write to your colleagues or call him. You can also use a screen sharing application. But it is simple not so effective. That’s why I don’t suggest working from home for juniors.

7. Set up your daily targets
   
   
   It is also a good strategy to set up your daily target in the morning, what you would like to achieve until the end of the day. Don’t stop working before achieving it. In this way you will be really motivated in concentrating on work. You targets should be realistic, so doable, but not to easy.
   
   
8. Schedule your breaks
   
   
   If you are working in the office you are also taking breaks: going out to the kitchen to drink a coffee, chat with your colleagues etc. At home you also need breaks at work. I would suppose to stand up from the computer during your breaks. But you can use it as an advantage and you can do some house work during this time: bringing down the trash, do the washing up, put the clothes into the washmachine. Since these activities are much different than sitting at your computer it will be good to do them and as an advantage you won’t need to them after work.
   
   
9. Don’t do every day home office
   

   
   Working every day from home can be really depressing on long term, which leads to losing your motivation. My suggestion is to work 2-3 days per week from home, otherwise work from the office, if it is possible. It makes you able to keep networking with people from personal and professional point of view and it is keeping some routine in your life.

Design by contract - Learn something new about OOP

Introduction

As I was studying Computer Science I met with the so called Hoare logic. Its main idea is that for each command/program you can define a precondition and a postcondition. These are logical expressions. Precondition must be true before starting your program. It is mainly checking if all inputs are in the correct range and so on. It can be of course also constant true, that means: there’s no specific precondition for this program. Postcondition must be fulfilled after running your program. Like your precondition is x > 0, your program is doing nothing else then y := x, then your post condition will be: x > 0 and x = y. With some predefined rules you can prove with methods of logic that your program is correct or not. It’s pretty easy in case of simple programs, but in case of complex programs it becomes quite complicated, that’s why it is really not typical to validate a program code in this way. It is a static code validation method anyway.

So I learnt it, passed my exam and forgot about that.

Years later I read about the so called SOLID principles and there was one called Liskov substitution principle. I had a flashback from my studies: “Hmm I have already heard it somewhere”. This principle is the following: “ if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program”. It is clear, but what does it mean in fact? It means the following:

• Preconditions cannot be strengthened in a subtype.
• Postconditions cannot be weakened in a subtype.
• Invariants of the supertype must be preserved in a subtype

Hmm, it sounds like Hoare logic and it sounds like something useful. At this point I read a bit more about Design by contract and what I learnt there gave me a much better understanding about how I should implement my programs in OOP.

I would like to show you the main concept.

Contracts of a class

We can talk about three different kind of contracts: invariant, precondition and post condition. Invariant is belonging to a class, pre- and post conditions are belonging to a method.

An invariant is nothing else than a restriction on the state of your class.  The state of your class is basically the value of your class variables. For example if you have a class for right-angled triangles your class variables can be: the length of a side, the the length of b side and the the length of c side of the triangle. These variables with their current values represent the state of your class. We know the rule: a*a + b*b = c*c in case of a right-angled triangle. That means if our class stands for right-angled triangle all values which are not fulfilling this condition are invalid, they are not representing a right-angled triangle. So this logical expression (a*a + b*b = c*c) can be your class invariant. This should be true in all cases. It will be checked: at the end of your constructor, at starting any of your class methods and at the end of your class methods. Next to that it is a good practise to keep you class variables private and reach them through setter and getter functions, so that your class can never get an invalid state which is not fulfilling the invariant.

The precondition of a method is a condition checked before starting your method. For example if you have a stretch function for your triangle which is having a parameter called factor your precondition can be that this parameter is greater than 0.

The postcondifition of a method. is checked at the end of the function, it is describing what you are expecting from your method. In case of the stretch function in could be something similar: a = old(a) * factor and b = old(b) * factor and c = old(c) * factor, where old means the value at the start of the method. Here it is also important that you need to think about the whole state of your class. So if it has attributes which should not be changed by the method it should be also specified in the post condition. For example if your representation has also a colour attribute than the post condition should be extended with: colour = old(colour).

Until now it is simple: each method has a pre- and a postcondition and the class has an invariant which is checked after construction and at the start and at the end of each function.

Contracts for sub classes

How does it change if your class has a base class?

Your class is holding the invariant of all of its base classes. So in case of one base class the following needs to be always fulfilled: invariant_of_base_class and invariant_of_your_class. So from a child class you can not break the invariant of the base class.

For example if the right-angled triangle class is derived from a triangle class, an invariant for the triangle class can be: a + b >= c (the sum of length of the two shorter side should be at least the length of the longest side). This invariant should be fulfilled also by the right-angled triangles.

Regarding pre- and post condition:

For an overridden function precondition can not be strengthened as the precondition in the base class. So it can be less strength (like instead of (a < 10 and b < 10) just (a < 10)) or the same as in base class.

For an overridden function postcondition can not be weakened as the postcondition in the base class. So it can be the same or more strength.

And this is called Liskov substitution principle, which is part of SOLID principles.

Maybe it is a bit complicated for the first time, but it says nothing else than: your subclass is a special case of your base class, so it should work for all inputs which are working with the base class and it should produce the same results as well.

Support of design by contract in programming languages

Using design by contract for your code is a defensive programming method, your program will have a runtime error in case of the violation of any contract (invariant, precondition or postcondition). That’s also usual that the check for the contracts is only activated in the test versions of your code and deactivate in the release version.

There are some programming languages, like Eiffel which are supporting contracts in a native way, but they are not really popular nowadays. For the today popular OOP languages (C++, C#, Java etc.) you can do your own implementation, it is also not too complicated or reuse an already existing library. For C++ Boost.Contract is a good choice. For Java there are several open-source solutions, like Oval or Contract for Java. For C# you can use Code Contracts. For Python PyContracts.

Summary

Of course I know that design by contract is not an often used way of programming and I think it is totally OK. On the other hand in my view this is a fast and easy way to improve your code quality and make yourself thinking a bit more about “what my code is really doing”. It makes also your code cleaner, because you will double check what should be really the state of your class and your pre- and postconditions are documenting the specification of your function as well.

I think even if you are not developing with this approach it is good to know about this way of programming and think a bit about your invariants, pre- and postconditions at implementing your classes to reach a better code quality.

How to write a really object oriented program

Introduction

As I started to do interviews with new candidates to our team I just realised that object oriented programming is topic which is really not clear for most of the people. For the question: “Do you know what is object oriented programming?” I usually got the answer: yes. For the follow up question: “Could you shortly tell me what is it?” I never got twice the same answer. I got a lot of good answers and a lot of answers which were not really matching with my understanding. And at a point I started to think about how I would answer this question and I realised that it is not easy at all.

There was an other example: I needed to reuse an already existing C++ code for my component. It was basically one class with around 200 functions and 100 variables, all of them were public and it was pretty unclear what they are standing for. After an analysis I just figured out that I can not reuse it as it is, because of multiple reasons:

• it was using a third party logger, which I did not want to include to my project
• The program which was using it originally were based on TCP/IP communication. Most of the functions were throwing exceptions if the TCP communication was not set up properly even if they had nothing to do with that
• Some of the member variables were used in multiple functions with totally different purposes. So if you wanted to call a member function from outside first you needed to set up ca. 10 member variables to the correct values to be able to get some results from the function.

All things considered I just decided to refactor this piece of code before reusing it and it took me a long time to figure out how to do it, because a lot of functions needed to be decoupled to a separate class and it needed to be figured out what effects are made by each variable for the different functions. It was a nightmare. As the customer asked me why this refactoring was needed I just replied: “Because it was not implemented in an object oriented way.”. At this point he told me: “Why not, it was all implemented inside a class, so it was object oriented.”. OK, from technical point of view it was implemented inside a class, so it was object oriented, on the other hand it was not following anything what means object oriented programming for me.

In this article I’d like to show you that object oriented programming is not just about using the related programming language elements, it is something much more than that. In my view you can also do object oriented programming in languages which are not supporting that officially (like C) and you can also work in a non object oriented way in pure OOP languages (like Java or C#). Let me show you my understanding about OOP.

Principles of Object Oriented Programming

First of all let’s see the official definition of OOP. I found a clear definition here: https://www.techopedia.com/definition/3235/object-oriented-programming-oop

It says:

“Object-oriented programming (OOP) is a software programming model constructed around objects. This model compartmentalizes data into objects (data fields) and describes object contents and behavior through the declaration of classes (methods).

OOP features include the following:

• Encapsulation: This makes the program structure easier to manage because each object’s implementation and state are hidden behind well-defined boundaries.
  
  
• Polymorphism: This means abstract entities are implemented in multiple ways.
  
  
• Inheritance: This refers to the hierarchical arrangement of implementation fragments.

Object-oriented programming allows for simplified programming. Its benefits include reusability, refactoring, extensibility, maintenance and efficiency.”

Let’s stuck first at the features:

• Encapsulation: I think this is the most important one. Each of the objects has a state which is hidden for other objects. And on the the other hand there is an “implementation” for each object. I understand under that the member functions of the objects. And the state and the implementation together is one unit or with OOP terminology one object. So if your object is a rectangle it will have a state with elements like width, high, position, colour etc. And it will have an implementation, implemented member functions, like: move, resize, paint etc. And this is one object, not less, not more.
  
  
• Inheritance: I would mention it before the polymorphism, because otherwise it is difficult to understand it. Inheritance stands for the connection between parent/child classes alias base/inherited classes. So for each class you can define so called child classes which can do everything what the base class can to (has the same public methods and member variables), but it can overdefine the implementation of the methods and it can extend the functionality (introduce new member functions and member variables). For example you have a class for animals. Each animal can move itself. But how they can move themselves if different for each animal. So the different animals will be inherited from the Animal base class and will override the implementation of move method. Plus some animals have some extra skills, like a dog can bark. So you can define a bark method for the Dog class.
  
  
• Polymorphism: This is exactly what I told about the move method of the animals. You can have for example a collection of animals and you can call the move method for each of them and you shouldn’t mind how it is implemented for the animal.

That’s the official theory. Let’s go further with some practical theory.

Objects and classes and the connections between them

From the name of object oriented programming we can see, that objects are the basic units behind this paradigm. The next important feature is the class. But what is the relationship between objects and classes: class is in fact a collection, a template for similar objects, for objects with the same methods and member variables. So if you are having a rectangle, then you will have a rectangle object which is an instance of Rectangle class. The rectangle class define that it needs to have a size and a position and the object holds it’s exact size and position. There are programming languages (like JavaScript) where it is not needed to define the class of an object. In this case objects are created based on so called prototypes.

So when you are planning an object oriented program first you always need to think about what kind of classes will you need in your program.

The other important question is: what are the connections between these classes.

There are 4 types of connections between classes:

• Composition:
  That means that the connected class is belonging to our class. They have the same lifetime (they are created and deleted in the same time). Our class can not work without the connected class. Like if we have a class called House and a class called Wall, then most likely there will be composition between them.
• Aggregation:
  Aggregation between class A and B means that class A has an instance of class B. Like Car has an Owner. But the owner can exist also without the car, and the car can exist without the owner, the owner can change any time.
• Association:

Association between class A and B means class A is using an instance of class B. Usually this relation between the objects is just a short term relationship, only during the run of the specific function. For example you have a class and it has a Log function. But this Log function needs an instance of the Logger class as a parameter. This is a typical example for association.

• Inheritance/Generalisation:

This is the relation type already mentioned earlier. It means class A is a special case of class B. It’s also called as child/parent class as well.

So the next to do is to decide what kind of relations are there between your classes. It’s good to do some graphical modelling for your classes to have a better overview. For that the class diagram of UML is a good tool. I would propose to always do a plan of your classes at least on a paper before starting to program.

There are two additional definition I wanted to clarify:

State of the object: In fact this built up based on the current value of all member variables. So if you are changing at least one member variable the state of your object is also changing.

Public interface of the class: This is all the methods and variables which are public, which are visible from outside of the class.

Based on that you can do a plan of your needed classes, but there are still some so called “best practices” in OOP programming.

SOLID

These best practises are called SOLID. This stands for the followings:

• Single responsibility principle
  Each of your classes should have a simple clear responsibility. You should be able to describe the purpose of the class with one sentence without using the words “and” and “or”. So yes: huge classes are most of the cases against this principle.

• Open/closed principle
  Your code should be open for extensions, but closed for modifications.

• Liskov substitution principle
  This is maybe a bit more complicated. But it means, that each of your parent classes can be replaced with any of its child classes without braking the functionality. This is coming from something called “Design by contract”. I plan to write a separate article about this topic.

• Interface segregation principle
  Your interfaces shall be small and clear and having one well-specified purpose. So you should avoid having interfaces which are returning a lot of data. So the public interface of your class needs to be well designed and easy to use. Make everything public is not a good practise.

• Dependency inversion principle
  You should design your classes your classes in a way, that the classes which are dependencies of your class can be set through some setter functions or constructor parameters. So that you can change them to any subtype later on. So for example if you have a Logger class which is used to create log files and you are can change it though a setter function you can change your Logger between an XMLLogger, a JSONLogger or a SimpleLogger if all these classes are derived from the same Logger base class. It is also helpful if at unit testing you need to mock your dependencies.

Let me extend it with my own suggestions:

• Always try to keep all member variables (so the state of your class) private and use setter and getter functions for more control
• Always try to design a user friendly public interface for your class
• Avoid the long parameter lists at your member functions, in that case always think about transforming some parameters to member variables if it really makes sense
• Read about object oriented design patterns and try to use them always when it is possible

Object oriented programming in practise

Now after getting familiar with all theory I wanted to include a short practical example. This is about implementing a Canvas which can visualise different shapes, like rectangle, circle, triangle and star.

A not really object oriented solution would be to create one Canvas class with member methods like: drawRectangle, drawCircle etc. But this solution is not nice, it is not using the features of object oriented programming and it makes difficult to extend your code (it is against open/closed principle).

Based on that my proposal would be the following:

Create a Canvas class. It should have a collection of shapes (aggregation with Shape class). It should also have member methods like addShape for adding new shapes or deleteShape for deleting already added shapes. It should have a drawAll function which draws all added shapes. Shape is a base class which has a draw method. Each shape has a (composition) size and a position. Position is a class with attributes for x and y coordinates. Size has a with and a height attribute. Each specific shape (Rectangle, Triangle, Circle and Star) are child classes of shape. So that each of them has a Position, a Size and all of them should implement the draw function. With this solution it is pretty to easy to extend the program with new shapes (just implement new child classes) of change the representation of position to other coordinate system.

This modelled and visualised in a UML class diagram should be something similar:

Summary

If you are an experienced software developer maybe I did not tell you anything new, but based on my experience a lot of programmers have a non-clear understanding about this topic, so I really hope I could help a lot of them. Based on my experience with this understanding you can ensure a much better quality for your work.