DEV Community: Marcell Lipp

How I prepared my first online course

Marcell Lipp — Mon, 22 Nov 2021 14:31:26 +0000

In the previous years I published several articles about different aspects of software development on different platforms. From all of them that ones were the most popular which were about version control with git, so at one point I decided to write a book, about this topic (https://www.amazon.com/dp/B095QK1MTN,
https://www.amazon.com/dp/B099C3GKL1).
Once the book was done I started to thing about how bring this topic on a higher level and I decided prepare some tutorial videos and upload them to youtube.

This was an activity which pointed out of my comfort zone. I'm feeling comfortable with doing the technical work and to write about it. I have also nothing against talking about it face to face. But to record it and publish it, so that people can replay it any time, so that people can find all mistakes I made later. They realize my English mistakes, my wrong pronunciation and my voice. And then they can leave feedbacks and comments. That was more than uncomfortable for me.

Finally somehow I managed to get over all these fears and I prepared my first tutorial video about "How can git support you in debugging your code" (https://www.youtube.com/watch?v=kNlnUaEcoLQ). I was really afraid when I first published it. And surprisingly I got really good feedbacks, both from friends and from people, who I don't know. One friend proposed me to prepare a whole online course. I still didn't feel comfortable with that, but after considering it two months long I started to prepare it.

I had to learn a lot: I read a lot and watched some online tutorial about how to build up an online course, what's to be taken care while working on the videos. I learned for example that the first 10 minutes are the most important, because after that time to listener decides if they want to continue the course or not. I also had to make sure if the sound quality is good enough. And I had to decide what I want to share in the videos: do I want to video myself, show some pre-prepared slides or my share my desktop while working on different scenarios? Finally I decided to do a mixture of slides and screen records, while solving real scenarios. I wanted to do my courses in a really practice-based manner.
And finally, despite all my personal fears I decided to add a short introduction video, where I record myself in my personal room. This was really something out of my comfort zone, but I managed to do it.

I learned how to record the screen and edit the video properly. I set up the environment and tried to configure it in a way, that it's well-readable in the videos. I created the skeleton of the course, collected the topics I want to share and figured out the best way to present them. I was thinking about the examples long hours long and I prepared some practical exercises. Then I recorded all the videos, which was pretty time consuming, but it also made fun. Finally I had to find a platform, where I can share the course and finally I decided to use Udemy for this purpose.

So I uploaded and filled everything on Udemy and finally I managed to publish my course.
It has two parts. The first part of for free for everyone and it's called "GIT for beginners" course (https://www.udemy.com/course/git-for-beginners1/?referralCode=2661870CB856A3BDB49C).
The second part (the follow-up of this course) is called "Advanced GIT course - Become a GIT expert" and it presents advanced tricks of GIT. Normally it's not for free, but in the next day by using this link you can get it for free:
https://www.udemy.com/course/advanced-git-course/?couponCode=7402FFF253AB9D0D86F5

I hope you will enjoy it, the only request is that please give me some valuable feedback, so that I can improve the course further.

Creating my first only course made me a lot of fun, I learned a lot, both technically and personally. In the meanwhile I received the first feedbacks and fortunately they are also mostly positive. I hope I managed to create a valuable content which will help a lot of developers.

Find the commit which broke the test in git

Marcell Lipp — Thu, 06 May 2021 20:58:51 +0000

Scenario

Find the first broken git commit.

Scenario in details

However the main purpose of git is version control, it can be also useful for debugging.

You found a bug in the system, your first two questions are of course: who did it and when?

Let git help you to figure it out in a fast way.

Detailed description of the solution

Case 1 - Manual verification of commits

If you don’t have an automated way to verify if a commit contains the bug or not, then follow case 1.

The solution will be git bisect. You can enter bisect mode with the command git bisect start.

Then you have to mark your current commit bad, as it contains the bug. Type the git bisect bad command. As the next step you have to mark the last known good commit, so a commit where the bug was still not present. For that you may have to try out several commits. But if you remember that it was still working 2 days ago, then just pick a commit from that day. You can checkout each commit to test. Once you found a good commit use the command git bisect good hash_of_the_good_commit. If the current head is the good commit you can skip the hash from the end of the command.

Now git bisect will checkout some commits. Determine for each if they contain the bug or not and mark them with git bisect good or git bisect bad. After several steps Git bisect will tell you the first good commit. If you think you made a mistake you can restart the bisect process anytime, just type git bisect reset.

Case 2 - Automated verification of commits

You can make this process faster if you have a script or any executable which can determine if the bug is present or not. You can even use a test framework. The point is only that the executable shall return 0 if the bug is not present and anything else if the bug is present.

Similarly to case 1 enter bisect mode with the command git bisect start.

Once you marked one good and one bad commit just use the command git bisect run path_to_your_executable. Here the executable is either a standalone script, but it can be even a call to your test framework with some parameters.

After this step git bisect shows you the first bad commit.

Step-by-step guideline

Case 1 - Manual verification of commits

Type git bisect start - It starts the bisect process
Type git bisect bad - It marks the current commit as “bad”
Type git bisect good hash_of_the_last_working_commit - Mark “good” the last commit where you are sure the bug was not present
Now git bisect will checkout a commit which is between the current and the last good commit. Compile it and test it. If the bug is present type git bisect bad, otherwise git bisect good.
Repeat step 4 until you can’t find the commit

Case 2 - Automated verification of commits

Implement a test which returns 0, if the bug is not present and non zero if the bug is present (most of the test frameworks already works in this way, so it is enough to implement some simple unit test in most of the cases)
Type git bisect start
Type git bisect bad
Type git bisect good hash_of_last_working_commit
Type git bisect run your_test

Test your knowledge

You can test your knowledge here:

https://github.com/lmarcell/git_practical_exercises_bisect

Additional git material

You can find more useful information related to git in the following ebook:

https://leanpub.com/practicalguidetoversioncontrolwithgit/

What did I learn from Artificial intelligence for robotics course by Udacity

Marcell Lipp — Fri, 30 Apr 2021 20:13:53 +0000

Introduction

During the last months I did not publish any blog posts. The reason is simple. I was busy with some other topics.

One hand I’m a lucky guy, who did not lose his job due to the current situation, I even had a bit more tasks to be done.

On the other hand, thanks to the flexibility of home office I managed to attend some online courses. Furthermore I’m preparing a material which is giving a great overview on the topic of version control with GIT, you will get more information about this project soon. And of course I occupied myself with non profession related activities.

Now the time is here to become active again on blogging.

During last spring there was an offer from Udacity for taking their “Artificial Intelligence for Robotics” course for free.

Since I have a stronger background of software development, but less experience with robotics algorithms I decided to take it. Let me write some paragraphs about my experience.

How about Udacity

I had no previous experience with Udacity, but I already took several courses from Udemy, which is one of their concurrents, so that’s a good base to compare.

Since I took that time the free version of the Udacity course the service was also limited: I did not have project review and mentorship to the project and I also did not get a certificate in the end. Later on I attended the Self Driving Cars nanodegree program as well, so I also have experience with the commercial Udacity courses, but let’s discuss it in a later post.

While doing the Udemy courses I often found myself bored and lost my attention. In the case of Udacity it was not the case at all.

The material is splitted into lessons, each lesson takes between 1 and 2 hours. During the lessons videos, written materials and quizzes are changing each other. The videos are following a friendly and natural style, while they are explaining well the problem and the solution. The written materials are giving a great summary on the theoretical part of the topics, sometimes even links are attached for some additional materials. The quizzes are either questions with some selectable options or coding tasks where you have to write a small piece of code or extend a given one. All your solutions are evaluated automatically. This is the way how you are making your attention alive and how they are forcing you to really understand the material.

After each session there was a section called “Problem Set”, which contained some tasks which covered the topic of the previous lesson and a “Q&A” session where the most frequent questions are discussed.

In the end of the course there was a practical exam with a list of practical tasks covering the whole material and a final project, called “Runaway Robot” to be solved. It was a real challenge, but it made me learn a lot.

It was a nice experience.

The content of the course

The course itself introduced the most important problems of robotics and their possible solutions. I prepared a very brief summary of these topics.

Since you find a lot of material about these concepts online, I won’t go into details this time, I’m rather just giving an overview.

Localization

The first chapter was about robot localization. The problem to be solved is to decide where the robot is located based on its motion and it’s senses.

Back to the university we learned a lot about distributions and probabilities. That time I did not really understand why we have to learn it, it was pure theory, so I did suffer a lot while learning it.

This chapter brought me at least one purpose, why I had to learn it that time and it also gave a great fresh up of the topic.

Furthermore it introduced me to some robot motion models.

All things considered it gave me a nice overview on the problem of localization.

Kalman filters

Kalman filters are great tools for making some predictions based on historical data. They are based on gaussians, which are functions to represent values with their probability.

So that if there’s a series of measurements with a given probability (for example about the position of the robot or of another object), Kalman filters can update the gaussian after each measurement based on the new measurement values and tell the most possible position of the tracked robot or object. One of its most useful applications in the world of robots and self-driving cars is sensor fusion, where it combines the measurements of several different sensors.

Another fact I have to mention, that it’s named after Rudolf Emil Kalman, who was Hungarian, similarly to me.

As part Udacity Self Driving Cars course I managed to implement an extended Kalman-filter, feel free to take a look: https://github.com/lmarcell/CarND-Extended-Kalman-Filter-Project

Particle filters

The idea of particle filters provides an efficient filtering method, which is really easy to program and which can be used for example for localization.

The main idea is to randomly create a large amount of particles, which are basically guesses where the robot is located at the moment. Then a weight shall be assigned to each of the particles. After each movement of the robot these weights shall be updated. High weight means that it’s very likely that the robot is around, small weight means that there’s only a small chance for that. By following this method after several movements it will be visible what is it’s most probable position.

Path planning

To find an optimal path between two points in a huge space is a challenging task. However this is a very important topic when we are talking about robots.

In an ideal case we already have a map of the space, but since this space is huge the classical path search algorithms, like breadth-first-search or depth-first-search are not efficient enough to find the most optimal path.

During the course two more efficient solutions have been presented. The first one is the A* algorithm, which is a kind of extension of the classical Dijkstra algorithm. The main idea is to introduce a heuristic function which provides an optimistic guess for the distance from a position to the goal position. So that takes the way where we expect the smallest distance based on the heuristic function.

The main challenge is to find a good heuristic function, since using the wrong heuristic function makes this algorithm really inefficient.

Next to A* algorithm the main concept of dynamic programming was also presented in the course.

PID Control

You have already planned the expected path of the robot, the next step is to let the robot follow this path. This may sound like a trivial problem, but it isn't. Just imagine: your robot is moving with a permanent velocity and you can only tell it if it should turn right or left. And you have the reference path, which should be followed. The most trivial idea is that if the robot is left from the reference path then let it turn a bit right. If it is right from the reference path let it turn left. In this case it will more or less follow the reference path, but it will always overshoot, so cross the reference path and this will result in a very strange and uncomfortable moving for the robot. A PID controller introduces a so-called differential and an integral component as well. If you find the right weight for the different components then you can reach a quite smooth and comfortable moving of the robot.

To find the optimal weight is also not trivial, but fortunately there’s a great algorithm called twiddle, which can help you.

As part Udacity Self Driving Cars course I managed to implement my own PID controller, feel free to take a look: https://github.com/lmarcell/CarND-PID-Control-Project

SLAM

SLAM stands for simultaneous localization and mapping. This can be used in the case when you don’t have a map of the environment of the robot. For example you have a vacuum cleaner robot and you want it first to move around the room and create a map of that, so that later it can find the most optimal path for cleaning it.

This is the problem of SLAM. This problem and one basic possible solution have also been presented as part of the course.

Summary

All things considered I learnt a lot from this course, it let me understand some main concepts of robotics which I could reuse as part of my daily job, while working on autonomous driving.

The course doesn’t go deep into the details, but it teaches and presents the main ideas in a very efficient way. This brought me to the decision to do the Udacity Self Driving Cars course, but let me tell you more about that course later.

Software development in automotive sector

Marcell Lipp — Wed, 22 Jul 2020 19:57:00 +0000

Introduction

The automotive business changed a lot during the last decades. Earlier a car was built up from poor hardware, without any software. During the last time there was a huge change: nowadays software is much more important in a car, than the hardware. All big companies are looking for software solutions on challenges, such as autonomous driving or environment friendly driving (E-cars, better engine controllers etc.). And to resolve these problems, there's a huge need for good and efficient software.

I've been working for more than 5 years in the automotive business and I still think that it is a really challenging and innovative area for software developers. Let me give you a better overview.

Software related areas in automotive

There are several areas in the automotive business, where software has a high focus. I will introduce them below, however there are other areas where software is involved and I’m not mentioning them.

ADAS

ADAS is an abbreviation of Advanced Driving Assistant Systems. This involves basically everything which brings the classical, human-based driving in the direction of autonomous driving. Several systems are already available in serial models, like: adaptive cruise control, lane keeping assistance, park assistant systems etc. But additional solutions are expected within the next few years which will enable autonomous driving in different environments (highway, country road, city).

From a software developer perspective these tasks are strongly related to robotics. Based on the inputs of sensors, like radar, lidar, cameras and ultrasonic sensors, by using additional inputs from the map and about the state of the car (current velocity, steering wheel angle etc.) it should be calculated what is the right reaction of the car.

Of course this process is split into several substeps, like sensor information preprocessing, sensor fusion, object prediction, trajectory planning etc.

Usually a lot of mathematics is involved in this area using technologies of signal processing, computer vision or artificial intelligence.

I think this area is maybe the most challenging area of automotive software development.

Engine control

Controlling the engine is done by software, which can be really challenging in the days when saving the environment is in focus and the related standards are very strict. To be able to achieve them very good software solutions are needed.

There’s even a trend of electrical cars. Their engine also needs strong software support to achieve an efficient energy consumption.

Brake control

Nowadays every new has an ABS (Anti-lock Braking System), which is a great software based support to achieve safe braking even in case of high speed or slippery road surface.

Next to that cars have several additional brake assistant systems, like differential scanning calorimetry (DSC) electrical stability control (ESC) etc. These are mostly software based systems, sometimes even with pretty complicated calculations in the background.

Automatic Gears

Automatic gear is also working in a software based manner nowadays.

Active and passive safety

Another big area is active and passive safety. Let's see what is included here.

Passive safety contains the classical safety features, like seat belts and airbags and pedestrian safety systems as well. Some software is already involved here, but that’s not really the focus here.

Passive safety is more interesting from a software point of view, however it is overlapping with other categories, like ADAS and brake control. It contains all the systems which can help to avoid an accident or just lowering the risks by lowering the velocity before an accident. That involves emergency brake systems, blind spot detection, adaptive cruise control, ABS, ESC, driver monitoring and lane departure warning. These systems require strong software support.

And I think it is really a good goal to work for decreasing the number of accidents on the roads.

Lighting

Modern cars have a proper system to control their lightning to light always with the right intensity to the right direction. To be able to do it some software support is needed, like detection of other light etc.

Infotainment

Classically infotainment contains everything that stands for the communication between the car and the driver, it involves all screens and touch screens, voice recognition, buttons on the cockpit and on the steering wheel etc. It always includes more and more functionalities, like multimedia, navigation, mobile communication etc. Of course these all require great software based solutions.

Navigation

It is a subpart of infotainment, but it is complex enough to mention it separately. Nowaday navigation requires next to great visualization and audio instructions. Also very good localization and path planning based on several inputs. There are challenging cases, like navigation in a tunnel or navigation in complicated, multi-leveled junctions.

Car2car communication

This topic is really pointing into the future, to the world of self-driving cars, but it is already part of our present. In such a system that’s a huge advantage if the cars can communicate with each other, share their planned movements, share what they can see or share their route. Additionally, cars can also communicate with the infrastructure: traffic lights etc. There are already solutions where the traffic light is changing if a bus arrives.

Additionally we can not rely on the internet, since there’s no signal for example in tunnels, so there’s a lot of challenge on the communication layer as well.

As more and more traffic participants start to communicate more and more information it will become a really interesting domain for both big data and wireless network solutions.

Tooling and simulation

Last but not least a huge area in tooling and simulation which is about developing small (and sometimes even complex) programs which can support the developers in activities like testing, simulation, visualization, parameter adjusting etc. At first it can sound easy but in reality it can also be pretty complex, especially if we are talking about traffic and car simulation.

Used technologies in automotive

The software development in the automotive sector is mostly embedded development, except tooling, that’s pure desktop development. Nowadays mobile application development is also part of automotive, since there are more and more situations when our mobile phone communicates with our car.

The core development used to be based on embedded C, but nowadays most companies are changing to use modern C++.

The tool development is mostly done in Python, in some cases in C++ or Java.

Popular frameworks are also used, like OpenCV, OpenCL, ROS etc.

THe model based approaches are also popular, so UML or Simulink is often used in the automotive sector.

Other than that all classical testing methodology is used, like unit testing mocking, higher level testing, software in loop, hardware in loop.

From the domain perspective all knowledge of robotics, computer vision, artificial intelligence or network programming is welcomed.

Of course up to the project and company this stack may change.

Development process in automotive

The development of the software of a car is done in multiple sections. First usually it starts as a research project. Its goal is to find the right technical solutions. The next step is a pre-serial development, it is still not dedicated for a model, it is a kind of overall solution. And the last step is the serial development, which has the goal to develop a proper software for dedicated models.

However more and more automotive companies are changing to work in a more agile approach, automotive software development is traditionally convervative and strict.

There’s a framework called Automotive Spice which should follow at most of the serial development projects. This framework is very strict and it requires you to document the requirements clearly, link the software design and related code. As well as the test should be properly documented and linked to software requirements and code.

Biggest challenges of automotive software development

Finally I’d like to point out some domain specific challenges.

No bugs in serial software allowed

As the development of the software is done it will be flashed on thousands of microcontrollers (ECUs). Currently most of the OEMs are flashing them manually one by one and there’s no opportunity for remote flashing. That means that to change the software on an already released car requires bringing it to the workshop and reflashing its software. It is of course inconvenient for the customer and costly for the company.

That’s why finding the major bug after the final release is really painful and should be avoided. In order to avoid such situations the testing of the software needs to be done in a really proper way.

Real Time communication network

In a modern car there are really a lot of microcontrollers (ECUs) and several sensors which are communicating with them (cameras, radar, lidar, ultrasonic sensors, wheel impulse counter sensor, rain sensor etc.) The communication between these sensors and ECUs should be really fast in order to avoid shortages which may lead to accidents. Package loss or communication errors are also risky because of the same reason.

Small capacity of processor and memory

The software needs to be written only once, but from the hardware thousands of units need to be produced. It absolutely makes sense to save money on the hardware by using a cheaper processor or a small memory.

On the other hand the software needs to be developed in a way that it is fitting well with this smaller capacity hardware, which can be challenging for the software development team.

Functional Safety

We all know that in a complex system a lot of things can go wrong: sensor failure, communication failures, unknown software bugs, memory failures etc. A car should be able to handle these situations in the right way. It should be able to detect and handle such situations in a safe manner to avoid or reduce such risks as much as possible. In order to do that a standard called ISO26262 should be followed during the whole development process. It provides a methodology to identify and classify the possible failures and to prepare the software to react on them in the best possible way.

Technically these solutions can be based on checking inconsistent inputs and outputs, on using multiple sensors to receive the same input and in certain cases to do the same computation parallel on multiple controllers with different algorithms.

Security

Since the goal of functional safety is to prevent risks caused by the failure of our own system, the goal of security is to prevent risks caused by externals. In the century of computer viruses and hackers it is very important to have a proper mechanism to guard the system from possible manipulations coming from outside, since they could cause serious accidents. This is a new area in automotive which has a really high focus and which involves huge challenges.

Summary

After more than 5 years as a software developer in the automotive business I see this area as a really challenging area, which needs more and more software developers. If you are considering changing your domain don’t forget about automotive.

Advanced GIT Tutorial - How to debug your code with GIT?

Marcell Lipp — Mon, 18 May 2020 12:12:00 +0000

Introduction

Unfortunately every software developer knows that things are often going wrong. Something breaks the build, something else breaks the tests. Someone makes changes which don’t fit with the coding guidelines etc.

It can be pretty difficult in such cases to figure out what went wrong, long long hours and days of debugging is needed sometimes.

Fortunately git can also help in such situations. Let’s see some builtin git commands which can make your life easier if something went wrong in your project.

Figure Out, Who Introduced The Guilty Line

You are reading a code and you find a line. “Who the hell did it?” - this is your first question. Maybe you don’t understand the purpose of the line or it is not following the coding guidelines or it is the root cause of a bug. The first thing that you can do is to check the git log for that file and figure out which commit contains the relevant change. It can be time consuming, especially if there’s a long history of the file and the relevant change happened long back in the time.

There’s another, more efficient solution: git blame.

Just type git blame filename. It will show you for each line, which commit was the last one that modified it.

This way it is pretty easy to figure out who did the change and what was its purpose.

Find The First Broken Commit

You found a bug in the code. You know that a week ago it was still not present and you don’t know the exact root cause yet. It would help a lot if you knew which commit introduced the bug, you could save a lot of debugging-time.

Git bisect is the best solution in this situation. Git bisect is a binary search method in your commit history. It can even handle the merge commits. Let’s see how it works:

Type git bisect start - It starts the bisect process
Type git bisect bad - It marks the current commit as “bad”
Type git bisect good hash_of_the_last_working_commit - Mark “good” the last commit where you are sure the bug was not present
Now git bisect will checkout a commit which is between the current and the last good commit. Compile it and test it. If the bug is present type git bisect bad, otherwise git bisect good.
Repeat step 4 until you can’t find the commit

Thanks for the power of binary search, it is a pretty fast method to find the guilty commit.

It can cause issues with this method if the bug is not consistent, it randomly appears in some commits.

Automatize The Search Process

It can be time consuming to test the commits manually.

Fortunately it can be automated. Git bisect also supports running automated tests.

Implement a test which return 0 if the bug is not present and non zero if the bug is present (most of the test frameworks already works in this way, so it is enough to implement some simple unit test in most of the cases)
Type git bisect start
Type git bisect bad
Type git bisect good hash_of_last_working_commit
Type git bisect run your_test

This method will find the first commit where your bug is present.

Summary

Both git blame and git guilty can be very useful in situations when you have to figure out what is the root cause of a bug. It can be much faster than using a classical debugging approach, given that you committed frequently enough.

How can COVID change the life of programmers?

Marcell Lipp — Thu, 23 Apr 2020 19:55:00 +0000

During the last months the whole world changed a lot. Something happened that was not expected at all. The schools closed in most of the countries and a lot of courses have been started. Most of the companies changed to home office mode or closed down. Anyway, digital solutions have a high role in the current situation. The companies with a good digital background can survive, the rest can easily fail.

Fortunately most of the software companies have a good digital background. But how will this situation influence the life of programmers in the long term?

Finally we can do home office

At most of the companies the opportunity of home office is a big ghost since years. Even if there are no technical obstacles or they could be removed by a simple IT solution (like setting up a VPN bridge etc.), a lot of companies still had a policy of no home office or very restricted rules for home office (like only once a month etc.). In most of the cases they had the impression that working from home is not efficient. Or they just wanted to track their employees more strictly and easier.

At most of these companies it changed now and they changed to an almost 100% home office mode. Which means most of their employees in most of their time are working from home.

I’m sure that on one hand there are companies and projects who are more successful on this change, on the other hand some companies may fail this change.

The reason for failing can be the lack of trust from management point of view, wrong leading strategies in the company, pure technical infrastructure, lack of experience or lack of motivation from the developer side.

But based on what I’m experiencing and what I heard from others at most companies this change was more or less successful, the teams are working from home with similar efficiency as they had before.

From the developer side there are also different opinions. There are ones who hate working from home. For some of them the conditions are not fulfilled at home properly, others are just too social to do it on a daily basis.

But, at least from the ones I know, most of the developers like this situation from a work perspective. I personally also like it, but I would prefer to work from the office once or twice a week.

The other point I often heard is that some of the developers have difficulties to find the work-life balance at home and they are working much longer than normally. You have to be strict with yourself to manage it properly.

What will happen to our projects?

Another perspective is the perspective of the customers. Since a lot of businesses stopped working during the last weeks, for sure there will be a lot of projects cancelled by the customers. On the other hand there are fields where there's a huge need for software developers: online communication and education solutions, digital solutions for shops and services etc.

So I also expect a lot of new projects coming in the near future. However all of us need to be flexible, it can happen that we have to change our profile a bit and to change domain or technology in the future.

What comes after Corona?

As for now most of the well-paying developer jobs are placed in big and expensive cities and expensive countries.

At these places even if you have a good salary you don’t have a huge chance to have your own house in a calm circumstance with a nice garden, these places are mostly too crowded for that and the prices are too high. Furthermore a lot of developers are working far from their home, just to have a proper job.

In the current situation there’s a good chance that companies will realize that home office work can still be efficient and they can save a lot of costs on that (like renting office space etc.), so they are changing fully or partially to this mode in the future.

I already heard some nice visions from programmers about moving to the countryside or back to their hometown and doing the same job for the same salary remotely.

It sounds great, but I doubt if it could work so easily.

If you take a look at how most big companies are working nowadays: they have headquarters and offices in more expensive countries, near to their customers and they have offices in so-called best cost countries (like India, eastern-European countries etc.). The reason is that it is enough to pay much less (sometimes even around 25%) in the best cost countries, than in the expensive ones (US, UK, Germany etc.). But they still want to have a certain amount of employees who are there in place, who can meet any time with the customer, who can be tracked better, who are near to the fire.

So if you are working now at an expensive and well-playing place and you are changing to 100% home office mode and moving to some nice, preferred place your advantage over the colleagues working in the so called best cost countries will be strongly reduced. So that it isn't worth it for your company to pay you 3-4 times more than for your colleagues working in the low cost offices. So most likely they won’t do it in the long term.

On the other hand the disadvantage of being far away from the headquarter will be also reduced if more and more work is done remotely. It makes no big difference if you are working from home in the next street or 2000 kilometers away.

That means if the home office model will become more and more popular I expect the differences of salaries between the different countries to be reduced in the long term.

How to make the most benefits from the situation?

How can we handle this situation?

First of all I have to remark, that we are very lucky compared to other professions, since our job can be easily done from home, so we are not stuck without incoming for weeks or months. On the contrary, we can save some time by not having to commute to work everyday.

One hand we have to do our best for our current work and current project to show that we are efficient developers even from home office.

In order to do that you have to have a strict daily routine and you may have to try out new tools or new ways of working. For example we started to do only mob-programming sessions and I think they are really useful.

On the other hand in your free time you have to learn something new, so that you will be flexible enough to change if it is required in the future. Take a look at the trending technologies and domains. There are now a lot of online courses available for free or for a discounted price. Do them, it makes you really powerful in the long term!

How I released my first book

Marcell Lipp — Tue, 21 Apr 2020 13:07:51 +0000

How I started blogging

I started to write my first blog posts almost two years ago. My motivation was to collect and share my knowledge and try to help other developers in their career and daily life. My feeling was that there are already thousands of technical blogs available online, but there’s a lack of blogs which is concentrating on the non-technical skills of software developers, which are giving a good overview on this profession. On the other hand I knew a lot of developers who were technically good, but they still couldn’t step ahead in their career, because of the lack of their soft skills. So I started to write blog posts on these topics. I wrote several of them. Later on I also wrote posts on more technical topics and I also started to publish my posts at several portals and communities, like dev.to or CodeProject.

I had posts which were more popular and others were less successful, but based on the number of readers and the feedback it became clear for me that there are people who are interested in my posts. I collected the most followers on dev.to.

From blog posts to book

After several blog posts I started to think about organizing my posts somehow, to build up a unit from the small posts. Finally I decided to write a book based on them. It is based on blog posts. I organized them and extended them with a lot of topics. Then I wrote it again and realized that some of them have to be rewritten from scratch to reach a higher quality, others need to be strongly reworked or extended. And some chapters were also missing, so I wrote them. I think such work can never be done, but at a point I encountered it as a completed work. At this point I started to think about how to publish it.

How to publish a book in 2020?

First I had doubts if I wanted to publish it at all. The topics I’m addressing are strongly subjective. I’m sure that there are several professionals who do not agree with all my suggestions and there are also one who think that they are just trivial. In case of a technical book the situation is pretty clear and objective. I think in that case it is easier to make a decision about publishing.

Finally I decided to publish it.

I never did something similar and I had absolutely no idea how to publish a book, so I asked my best friend, google to help me.
Google told me that men have two main options: classical publishing through a commercial publisher or self publishing.

In the first case I have to create a book proposal of my work and send it to publishers and they will decide if they want to publish it or not.
This sounds easy, let’s do it. I created such a proposal for my work and I collected around 10 publishers which are publishing books in IT topics and I sent my proposal to each of them.

Unfortunately this method was not really successful for me. From most of them I received negative feedback in some days, telling that it is not matching properly with their profile and future plans.
It is not time to give up, so let’s check the second option.
In case of classical self publishing you should find and pay for some support people who can edit and proofread the book. Also the cover should be designed. Then you should investigate a bit in printing and into the marketing in order to sell it.

Well, that was not really an option for me. I did not have a high financial plan with this book, I did not want to investigate a lot of it.

Finally I found a light-weight option of self-publishing, which can be done without huge investigation. It is called LeanPub.
LeanPub is a perfect platform for publishing a low-cost version of your book in an e-book format.

I decided to publish by using this option.

Take a look at that! I hope you will enjoy reading it:

https://leanpub.com/howtosurviveasaprogrammer

Software quality assurance in practice

Marcell Lipp — Fri, 03 Apr 2020 06:29:00 +0000

Introduction

Every software developer has some idea of a good quality project (bug free, fast, easy to adapt, readable code base etc.). Some of the developers also have an idea how to achieve it (reviews, TDD, proper design, proper testing etc.). All these practices need to be collected and followed is a way.

Software quality assurance is something that is on the side of any development, regardless of the development process. Some way of quality assurance is used by all big companies. The goal of software quality assurance is to have a clear picture about the quality and try to reach and maintain a predefined level of quality.

Theory of software quality assurance

Most of the companies have a dedicated quality assurance team or at least one dedicated person who is responsible for the quality of the projects. That means it should be someone who is not involved in the project, who makes no development on that, this person rather makes sure that the development team does everything in the correct way. Quality assurance is involved in each and every step of the development process: planning and tracking of the project, requirements engineering, software design, implementation and testing.

The very first point is to set up rules to be followed by the whole development team: how should a requirement be documented, which level of software design is required in which situations, who and how should review the work, which coding guideline is to be followed etc.

Once it is done the role of the quality team is to make sure that during the project everyone is following the predefined rules. To be able to achieve it the activities should be documented in a clear way. For example, if someone did a review of a piece of code it should be documented in a way, that it can be always proved later that the given version of the given code has been reviewed.

There are predefined software quality standards and frameworks, like the different versions of SPICE or CMMI, which have several predefined rules, but every project and organization is free to set up their own ruleset.

Software quality assurance in practice

Setup rules and performance indicators

In practice the very first step to set up the rules for the development: coding guidelines, testing guidelines, responsibility matrices etc.

Some of them should be introduced right at the beginning of the project. But introducing all of them at the beginning can really go against performance and the success of the project. So some of these rules can be introduced in a later stage of the project.

Some of these rules are pretty binary: either they are followed or not. Like the rules in the coding guideline: “don’t use variable names longer than 15 character”. It is very easy to decide if this rule is followed or not.

There are other cases where the answer is not so clear. A good example is test coverage. Most of the projects require unit tests, but it is not needed that each and every line is covered by these tests. In these cases so called key performance indicators (KPI) should be set up. This thing should be quantified and measurable. For example for code coverage there are multiple possible KPI’s: line coverage, branch coverage, etc. It should be decided what is the official measurement method in the project.

These rules can be relevant for any step of the development (planning, requirements, design, coding, testing etc.).

Measure your indicators

Once we know the rules to be followed we have to figure out a way to measure them. The best way is if we can automate these measurements by some tools and integrate them to the continuous integrationsystem of the project. So that you will have continuous feedback about the state of the project, you can follow how its quality changes. It is good practice to introduce these KPIs to the whole team. Most of the tools which can do the measurement on different KPIs are easy to integrate, in other cases you can use some scripts to do the job.

Setup goals

Once the KPIs are measured and known by the team setup some goals. Like “the code coverage should reach 80%” or the number of compiler warnings should be 0, every component has to be linked to requirements etc. Let the team know these goals and let them work on them. Give regular feedback to the team about the distance from the goals and the achieved changes. It can be done by daily report emails. All these goals need to be documented in a clear way.

The most typical goals are the following:

Design has to be linked to requirements
Code needs to be linked to design
Positive review should be done before merging
Test should be linked to requirements
Coding guidelines should be followed. (for that a proper coding guideline is required)
Code should be covered by tests
Memory assumption/runtime should be in a dedicated range
The piece of change (commit) should be connected to a ticket in the ticket system
Tickets in the ticket system should be connected to requirements

Setup gates

Finally, you can set up some built-in gates to the CI system. That means it doesn’t allow to merge code which is violating any of the rules, like: contains compiler warnings, failing some checks, not covered by tests, has failing unit tests etc. This can reduce the speed of development, but increase its quality.

In general too strict rules can be against productivity, pay attention! You should always pass the rules to the project needs. So most likely the expected quality in case of a mobile game will be much lower than in the case of an aeroplane software.

Summary

Quality assurance is nothing complicated. I tried to describe it in a practical manner and not in a principled way. But one thing is important: you have to be strict, the rules which have been set up, need to be followed.

Advanced GIT tutorial - Interactive rebase

Marcell Lipp — Thu, 12 Mar 2020 21:53:00 +0000

Introduction

It can often happen that you did something wrong by using GIT: you gave the wrong commit message, created too few or too many commits, you have commits in the wrong order or with the wrong content. To change such things you have to change history in GIT. Interactive rebase in GIT is an efficient and powerful tool for that.

The idea of interactive rebase

Git rebase can change the commits between the current HEAD and a dedicated commit. You can define the commit either by its hash or by its index relative to the current HEAD by giving HEAD~n, where n is the index. So HEAD~10 means the 10.th commit before the current HEAD.

To change the last 3 commits before the current HEAD type git rebase --interactive HEAD~3 or git rebase --interactive hash_of_the_third_commit_after_head. Pay attention, the third commit after HEAD is practically the fourth commit in git log, since the first is the HEAD itself. Instead of --interactive you can also type -i. This command will open your default editor and list your last three commits. The format is something like:

pick hash_id commit_message for each commit.

The very first thing you can do is to change the order of the commits in this file. It is pretty straight-forward, just change to order of the lines

Other than that you have the following options with each of the commits:

Pick (p): You would like to keep that commit as it is, this is the default action.
Reword (r): You would like to change the commit message of the commit.
Edit (e): You would like to change the content of the commit
Squash (s): It merges the commit with the previous one, keeping both the commit messages
Fixup (f): Same as squash, but it keeps the commit message of the previous commit
Exec (x): Executes a custom shell command
Break (b): It stops the rebasing at that commit, you can continue later with git rebase --continue
Drop (d): It drops that commit together with its content. That’s the best way of getting rid of a commit
Label (l): It attaches a label to the given which is the actual HEAD: Pay attention! The parameter here is not a commit id.
Reset (t): It resets the label of the current HEAD commit. It is also not expecting a commit id.
Merge (m): It creates a merge commit.

You should just write the right keyword or its abbreviation (in brackets) before he commit id.

Resolve issues by interactive rebase

Here is a small collection of real life scenarios which can be resolved by interactive rebase.

Change commit order

As already mentioned, you can change the order of the commits. If you want to change the order of the last 10 commits:

Type git rebase --interactive HEAD~10
You see now the list of commits is your default editor. Change their order as you wish.
Save this file, resolve all conflicts

There’s a huge chance that you have to resolve some rebase conflicts, in this case change them, add the changed file with calling git add and type git rebase --continue at the end. Since the rebasing is commit based it can be that you have to fix similar conflicts in the same file multiple times.

Get rid of unnecessary commits

It can happen, that you would like to remove a commit with its content, do the following:

Type git rebase --interactive HEAD~10 (to remove some commits from the last 10)
Change the “pick” to “drop” in the lines of commits to be removed
Save the file and resolve the conflicts

That’s it, you removed the unnecessary commits with all their content.

One commit instead of multiple commits

Sometimes you created too many simple commits and you would like to make your history more clean with less commits. You can simply merge the content of multiple commits into one.

Type git rebase --interactive HEAD~10 (to merge some commits from the last 10)
Change the “pick” to “fixup” in the lines of commits to be merged into the previous ones
Save the file

Change the commit message of old commits

What to do if you want to change the commit message of an older commit?

Type git rebase --interactive HEAD~10 (to change the message of some commits from the last 10)
Change the “pick” to “reword” in the lines of commits to be renamed
Save the file
The current commit message will appear in your editor, change it and save it

Edit an old commit

How to change the content of an older commit?

Type git rebase --interactive HEAD~10 (to change some commits from the last 10)
Change the “pick” to “edit” in the lines of commits to be edited
Save the file
Do the changes you want, add them by git add and commit them by git commit --amend
Type git rebase --continue
Resolve all the conflicts

Split commit

How to split an already existing commit?

Type git rebase --interactive HEAD~10 (to split a commit from the last 10)
Change the “pick” to “edit” in the lines of the commit to be splitted
Save the file
Type git reset
Add the changes for the first commit and commit it
Add the changes for the second commit and commit it
git rebase --continue

Summary

In my view interactive rebasing in git is a very powerful option which can make several scenarios easier and faster. But in order to use it in an efficient way you have to really know how it works.

Which tools should be used for your project

Marcell Lipp — Wed, 26 Feb 2020 21:41:00 +0000

Introduction

To work on a project in a professional way you will need thousands of tools. Your tools can determine the success of your project. I collected the most important tools you should use for your project.

Tools

Ticketing system

The most important tool is to have a proper ticketing system. Regardless of the process you are following it’s making it possible to track the tasks to be done and the state of the tasks. It is also nice that everyone can add comments to the tasks, so that all hints and discussions can be documented in a traceable format. This system can be connected with the version control system, so that you can have a proper connection between your code and tasks. Most popular ticketing systems are JIRA and Redmine.

Bug tracker system

A bug tracker system stands for tracking the state of all detected bugs in the software. It makes you sure that you won’t miss any of the bugs. It is also nice that you can search the already resolved bugs and see what was their root cause and solution. It helps you to fix new bugs. Very often bug tracking is also done by the ticketing system. One example is Mantis.

Requirement handler system

In big projects, especially if you are following a classical development process (Waterfall, V-model) then you need a tool which is used for documenting all the requirements. Of course it can be done in word or any other text document, but a proper requirement handler has a lot of additional features: it is version controlled, it can do linking between requirements, requirements can be filtered and ordered based on different attributes, the requirements can be categorized.

Project planning/tracking system

There should be a project management tool used for planning of the tasks and resources and tracking the progress of the project. Sometimes it is integrated into the ticketing system, in other cases excel is used for this purpose. But the clearest solution is still to use a professional tool.

Version control system

This is a really must-to-have tool. You need a version control system which can track the changes of a code and it makes possible the parallel work of multiple developers on the same base of code. Most widely used version control systems are GIT and SVN.

UML editor tool

UML is a proper tool to document and visualize the architectural and dynamic design of your software. You have a high variety of diagrams to visualize your software from different perspectives (class diagram, object diagram, sequence diagram, state diagram etc.). UML is basically a semi-formal documentation of your software. It is possible to draw UML diagrams on paper or in a drawing software, but is proposed to use a professional tool for this purpose. My absolute favorite one is Enterprise Architect. Unfortunately it is only for Windows and it costs a lot. But it can properly format the diagrams, link the related diagrams between each other, control the different versions, handle different permissions and it can also generate some code from the diagrams.

Continuous integration system

It is also suggested to have a server with a continuous integration system. It can regularly build your code, run the tests and do additional code quality checks. So that you always have a clear picture about the current state of your code base and you can also set up some quality gates. Jenkins is a really good CI framework for starting.

IDE

IDE means integrated development environment. This is a tool which helps you to edit your code. But it also has support for navigation inside your code and you can usually integrate plugins for compiling, debugging or for version control. There is a high variety of IDEs like: Visual Studio, VSCode, QT Creator, Netbeans, Eclipse, etc. Fortunately, most of them are free.

Compiler

If you are not working with some interpreted language you will need a compiler to build your code. It is always up to the used language which ones can you use.

Interpreter

If you are working with interpreted code, like Python you will need it (instead of compiler) to be able to run your code.

Debugger

A debugger makes it possible to have a more detailed view on your code when you are running it. It makes it possible to see the call stack, the value of the variables and it also makes it possible to put so called breakpoint into the code. The run of your program should be paused at the breakpoints, so that you can analyze its state. With a debugger you can also run your code line-by-line. Most debuggers are integrated into IDEs. To use a debugger you have to compile your code with specific debug option, so that the compiler is generating additional debug information.

Code formatter

Most of the big projects have guidelines for the formatting of your code: usage of spaces and tabs, maximum length of lines, where to put the braces and brackets etc. Your code can be automatically formatted based on custom rules with some code formatter tools. For example for C++ you can use clang format. These tools can be integrated into your IDE, so that you can make sure that you are not violating any of such guidelines.

Static code analyzer

A static code analyzer checks your code without running it. It can be detected: unused variables and parameters, usage of uninitialized memory fields, violation of naming guidelines etc. It is really suggested to setup such a tool for your project to ensure better quality.

Dynamic code analyzer

A dynamic code analyzer similar to the static one, is also checking your code, but it is checking it while running. It can detect issues like memory leaks, and possible runtime errors.

Profiler

A profiler can measure the runtime and the memory consumption of your software in critical scenarios. You are supposed to use it in case of embedded development or if your software is using a lot of memory or CPU.

Test framework

If you want to run automated tests on your software you will need a test framework. In fact you can use different framework to your code on different levels: unit tests, component tests, acceptance tests, smoke tests etc.

Communication tool

You also need a communication tool which can be used within the team for communication. It is nice if it supports screen sharing and remote control of computers and if it is documenting all discussion properly. You have thousands of choices, like Slack, Skype for Business etc.

Time and holiday tracker tool

Last but not least you need a tool to track the holidays and the working time of the team members. However in some organizations working time is not tracked anymore, most of the companies are still using it for different purposes. It’s nice if the developers can book their time on different projects and tasks. It helps the project managers to get a clearer picture of the progress of the project.

Advanced GIT tutorial - Cherry-pick vs rebase vs merge

Marcell Lipp — Fri, 14 Feb 2020 21:27:00 +0000

Introduction

One of the most important features of GIT is branching. The development of multiple functionalities can be done parallel, independently of each other.

In the end of course a version will be needed which includes functionalities from multiple branches. The article is a brief overview on the methods about how you can create such a version.

Overview on GIT branches

In GIT every commit knows its parent. So the list of your GIT commits is a one-way linked list, representing the order of the commits. By default you are working on a branch named master. A branch is always stored as a simple hash id, which is the hash id of the latest commit on the branch. You can anytime start a new branch based on the current HEAD commit by the command git branch branch_name. This command creates a new branch, pointing to the current commit. Then you can change to this branch by git checkout branch_name. This will change your HEAD to your branch. Or you can do these steps together by typing git checkout -b branch_name.

On a branch you can work independently from the master branch. You can implement a new functionality, fix a bug or do some refactoring. In the meanwhile others are working on the master branch or on some other branches. Until you are working on your functionality new functionalities will be added to the master branch. At this point you have to create a version which has all the content of the current master plus your changes from your branch. There are three ways to do it. Let’s see the details.

Merge

The first, very classical way is git merge. While being on master branch (you can always check your current branch by typing git branch) type git merge your_branch. This command will create a new merge commit to the master branch.

What is a merge commit?

In GIT every commit has one single parent commit, except merge commits which have two or even more parents. The command git merge master creates a merge commit with two parents: the last commit of your branch and the last commit of master. So that by checking out this commit you will have both the changes on the master and on your branch. During merging conflicts can appear if the same lines have been modified on the two branches. In this case these conflicts have to be manually resolved.

Before merging always make sure that your branches are up to date with the remote branch.

The big advantage of git merge is that the history of the commit stays clear and unchanged.

The disadvantage is that large amount of merge commits can make the branch history unreadable.

Rebase

The second option is git rebase. Git rebase is changing the parent of the first commit on your branch. So git rebase master will change the parent of the first commit of your branch to the latest commit on the master branch.

To be able to do it all commits on the branch needs to be modified, because in this way they will contain the change being done on the master. Since you are changing the commits, their hash id will also change. So technically they will be new commits. That also means that multiple instances of the same commit (rebased and non-rebased) can appear in the git log. You really have to pay attention!

Furthermore git rebase is being done commit by commit, so the same conflicts can appear again and again.

The advantage of this method is that your history will stay one straight line, on the other hand it won’t be possible to figure out later, that a git rebase happened.

You should especially pay attention to rebasing if multiple developers are working on the same branch.

Cherry-pick

Git cherry-pick is the best command if you want to move only one (or some) commit from different branches to the current branch.

For example you have a bugfix commit on one of your branches and you don’t want to merge the whole branch to the master, only the one commit which is fixing the bug. You should checkout the master branch and type git cherry-pick commit_id, where commit_id is the hash id of the bugfix branch. This command will create a new commit (with a new commit id) on the master branch, which has the very same changes as the cherry-picked commit. The cherry-picked commit will stay untouched.

Summary of merge, rebase and cherry-pick

To summarize the topic: git merge doesn’t change any existing commit, it just creates a new merge commit, which has two or more parents.

Git rebase changes the parent of the one commit (usually the root of the branch, or the commit given as a parameter). With other words it is rewriting the history of the branch (or commit). The commits get a new hash id.

Git cherry-pick reapplies one dedicated topic on the current branch, with a new commit id. The cherry-picked commit stays untouched.

How I became a certified scrum developer

Marcell Lipp — Tue, 04 Feb 2020 21:37:00 +0000

Introduction

Some weeks ago I attended a week long training session with the title “Certified scrum developer” (a.k.a LeSS in action), organized by the company Odd-e.

I regularly attend technical trainings in different fields, but I never wrote a blog post about them. Well, I wrote one with the title “How to do a proper technical training for developers”, but that post was the result of attending several trainings which I did not like.

This time the situation is different. I found this training really helpful and motivating. It had a clear effect on the way I'm thinking about agile software development, however there are still some points where I’m not absolutely convinced.

I’d like to summarize here what were the most important messages for me from this training.

And just to be honest: since the training I attended was not certified (even if its title was “Certified scrum developer”), I don’t have such a certificate, but it does not reduce the value of this training in my view.

The training

The training itself was very different from the trainings I attended before. The attendees have been split into four teams and each team had a workstation with huge monitors and computers (2-3 of such stations per team, each team had 5-6 members). Then during the week we simulated a sprint of working on a real product - an online game. We really worked day by day as teams in a large scaled scrum organization, and during these working days we had several sessions where we talked about dedicated topics. These sections were also reflecting on the situation in our sprint.

The first day was focusing on the refinement of the items. We did a nice refinement workshop, and we got a nice introduction into the methodology of specification by example and its connection to acceptance tests. We also did the sprint planning 1 where we decided on the items to be done by each team.

From the second day the teams really focused on the development. There was a CI system, which verified every new commit and notified all teams when something was broken. In this case one team take over the “fix the build” responsibility. We were doing mob-programming, so usually 3 people were sitting in front of the same computer. There was a navigator of the mob session (who had the keyboard) and others who gave the instructions. The lead of the session has been changed regularly. We started every morning with a daily stand up and we evaluated the results of the day at the end of the day.

In case of any questions we were free to ask the product owner or even the customer. We also had to sync regularly with the other teams, since we had to touch the same code and implement similar functionality.

It was really exhausting, because the training was every day between 9 and 6 and it was really intensive. After the first day I almost lost my voice from speaking too much.

Although I've been working in a LeSS team for about a year (you can find my post about my first experiences and my later experiences part 1 and part 2), but this level of team work with continuous mob-programming was still something new for me.

The main topics of the sessions were: how to work in team and in pairs, how to do proper TDD, how to write good quality code, refactoring and how to do it, how does an agile organization look like, software architecture and design in agile development etc.

None of these topics were absolutely new for me, but they showed me these topics from a totally different perspective with very good practical examples, so I learned a lot.

Finally we closed the week with sprint review and a retrospective, where surprisingly most of the planned features worked properly.

The most important messages for me

First of all I have to clarify that I’m not a religious scrum believer. I started my career in an organization where we followed the classical V-model very strictly. There I have seen some advantages and a bit more disadvantages of that way of software development. Later on I worked in multiple projects which were following some kind of scrum organization, and as I have already mentioned, I'm currently working in a LeSS organization. Here I also see several advantages of the development process, but also some disadvantages. However, I have already realized that some of the disadvantages I observed were because of the wrong adaptation of scrum. So I think learning something new about agile development methodology can only help me. And to be honest this training helped a lot. Here I would mention some important points I learnt.

Proper way of specification by example

I already heard before about the idea of specification by example, but it was nice to apply it in practice. The high level idea is to describe concrete scenarios for your software with exact input and output data and use them as specification. To cover multiple cases (even the corner cases) you can organize the input values (and the expected output) into tables.

This way you can describe your requirements in a way which is well-readable by everyone, even for non-developers.

Additionally you can easily write automated tests based on these scenarios by using some acceptance test framework.

Taking a first bite

It is always a problem to refine and estimate tasks for topics which are absolutely new and unknown for the team. If we have no idea about the topic, how can we estimate it or how can we ask the right questions regarding the task?

The idea of taking a first bite is a solution for that. It means to first take something really small and easy from the topic, work on that and solve it. In the meanwhile you are becoming more familiar with the code base, so as a next step you can take over (and refine) a bit more complicated tasks with the same code. And keep on following this strategy until you are feeling comfortable with the code and topic.

How to do very proper TDD

TDD is a very popular buzzword nowadays. Basically the idea is to implement the code and the unit tests in parallel. But just like in the case of other popular buzzwords (SCRUM etc.) it is also pretty often misunderstood or misinterpreted.

The proper way of TDD is to always implement one test case (better to say, one check for your unit test), let it fail and then make it working in the code with the possible smallest change. Once it’s done you can do some refactoring to make your code nicer.

What is pretty strange for me is that you shouldn’t write more code than really needed. You really have to behave like you are being stupid. For example if you are adding code where you know that you will have three different cases, you are not allowed to prepare your code for multiple cases as you are implementing the first one. It is absolutely against the way, how I usually work. I’m always thinking about what can be expected in the near future and implement my code to support these upcoming changes. It will still take some time to change this mindset.

The power of strong teamwork

I already realized before this training that teamwork is a really strong power. This training ensured me once again about this fact. I heard several times that pair programming is just a waste of resources, earlier I was not sure if it’s true or not, but now I’m sure that it’s not true. Simply the fact that we were doing mob programming all the time let us learn a lot and helped us to avoid making a lot of mistakes. And the flat communication channels also made it possible to detect issues in time.

However I have to mention that it is mentally really exhausting to work in such a way.

Software architecture in SCRUM/LeSS

There’s a really huge gap between the idea about software architecture in classical development models and agile models.

In case of classical development models software architecture is predefined, planned, well-documented and more or less static. Static in the sense that it should change as little as possible during the development.

In case of agile development there's usually a different practice. The architecture is not really planned, it just happens. It is just the actual state of the code and it is continuously changing. However there’s still a place to talk about the current architecture and to make architectural decisions.

The world is not always ideal

This was maybe the most important message for me.

The world is unfortunately not ideal. There are always issues which make it difficult to implement a proper scrum or to follow proper TDD. There can be thousands of reasons.

All these methods we learned about are working in an ideal world, but even if the situation is not optimal you should make the best of what is possible and try to optimize it.

Remaining open questions

There are some topics where I am still not totally convinced about scrum. Let's see those points.

How to apply scrum with less social developers

There are a lot of programmers who are not so good at communication and other social activities. For some of them that was the reason to become a programmer. But the world changed and soft skills became very important for developers. Especially in case of agile development models.

Of course these soft skills can be improved, but I think we can not expect wonder from developers who are not good at it at all.

I met a lot of developers who had very good technical knowledge, but they could not communicate with their team properly. What’s the future of these developers? How can they be integrated into Scrum teams?

Does it really make sense to avoid thinking about long term software architecture?

It is clear that software architecture is changing frequently together with the requirements. But there are several cases when upcoming functionalities can be seen in advance. Does it really make sense to use a simpler solution and implement a more complicated one some sprints later if it is already known that the complicated one will be needed soon? At this point I’m still not totally convinced.

How to make sure that our unit testing is really done properly?

The way of TDD is to write test cases and to implement related code and to keep doing it until we can not think about additional test cases. Well, but these test cases are really just up to us. How can we make sure that we really covered every corner case if our test cases are not connected to any kind of requirements? It is really easy to miss some points.

How to plan an agile project?

Well, agile projects are dynamic, flexible and open for changes.

However in case of projects the question is very often pretty simple from the customer: I need a software with this and this functionality: how long do you need to implement it and how much does it cost.

In case of classical project management both questions can be answered based on some estimations, however these estimations are not always proper.

But how to answer such questions in agiles modus?

Is pair programming always worth it?

I have already mentioned about the power of teamwork. One of the most common teamwork practices is pair programming. It really helps a lot, it makes the knowledge session much faster and it helps to improve the code quality. However there are tasks which are pretty easy, repetitive and even a bit boring and not challenging at all. I think there are such tasks in every big project. Is it really worth it to do pair programming for such tasks?

Final thoughts

I really liked the training. This was the most interactive training I have ever attended and I really appreciate it. From the content perspective it was nice to see a lot of things in practice, it helps much more than just reading about these topics.

It was really a pleasure to have hands-on experience with this way of working: strong teamwork, mob programming, TDD etc.

It was really active, so it is not possible to mention everything well-detailed in this post, but that was not my goal.

It clarified a lot of things for me, but I still did not become a religious scrum believer. I still see a lot of advantages of this working methodology, but it also has its own cons.