Which tools should be used for your project

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

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

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.