It's in your process

Why 55 is a perfect length

Procrastination and lack of motivation happen all over and anytime. If you google, you can find lots of pages describing difference between procrastination, laziness and motivation gap. In most cases they describe a problem from individual, personal prospective, some of them however take the topic more specific as lack of motivation in a company in general or on specific project. Especially LinkedIn is full of such articles, mostly sponsored ones. But how to understand that your project stuck with progress, motivation is low in general although some individuals are still fighting with circumstances?

You still deliver necessary functionality, and you still get your story points and necessary velocity, but something is wrong. Especially hard to understand if it’s a temporary state or first sign of hard-to-solve problems. Here is when we understood that our project was facing procrastination in full strength.

…when you understand that you have nothing to do

We use wide know procedure of cross-team code review. Also, we have a dedicated people who is responsible for specific parts of a system, and as you may understand, get all code-reviews on dedicated topic. There is an example we had recently.


Code review

From silver bullet to deadlock… and back

Some problems are expected and easy to solve. In most cases we never call them problems, but the tasks within stories. Solving them we call a development, simply saying a job.

Other problems are not expected, but they are still easy to solve, when we finally know about their existence. We call them bugs, generally we receive them from testers or support engineers. It may take the whole day to solve them. 20 minutes to spend on bug and the rest of the day for table football.

Most problems are expected but hard to solve, and this is the most unfortunate category. Because these problems spend the rest of their miserable lives in a backlog, never reviewed, never analyzed, never mentioned during stand-ups and at the end killed with cleaning up of scrum boards.

The most challenging ones (according to corporate etiquette we prefer to call them challenges, rather then WTF) are unexpected and hard-solvable problems. They even don’t go to a backlog. In most cases just because nobody knows what to put in the title of issue, except “a new shiny bug”, it takes time to investigate. Some developers call them phantom bugs, put a stamp “Unreproducible” on them, other developers just ignore the existence of these bug at all. All developers, to be precise.

But the hardest problems are that, you have no idea about. And this is a real challenge, but not that one from a book of company rules. Solving these problems makes you grow, become more mature and finally stop being a junior developer. I personally hate them most of all. Basically because nobody pays for solving them. But also because it makes me feel almost as miserable as bugs in a backlog. They are never fully solvable, in most cases they avoided, and it’s called best practices in books and video-courses.

Most developers I’ve worked with put persistence problems in a backlog, secretly hoping that someone would delete them (problems, not developers, but who knows) or data storage system would be changed. An unfortunately persistent layer is persistently stable, changing DBMS is rarely an option. Although sometimes I feel almost personal pain because of these left-forever issues, life is life and development costs money.

It’s not a problem, it’s a challenge

This time wind of change blew somewhere between persistence and back-end: the problem occurred¬†too often to send it to backlog and too scary to start actually working on: deadlock. In my previous experience I met deadlocks not more then ten times, in all cases it occurred in heavily used systems with thousands of simultaneous calls, in all cases the root cause was hard to find, in all cases deadlock was solved on database level, applying magical combination of indices, in all cases DBA was blamed in all humans sins. This time things were drastically different: our system is on under-development stage, and we barely have any data on production, the tests run on almost empty environments, testing only simple “super” happy flow scenario, we use default setting of MS-SQL Database running in Docker, we use Hibernate as ORM, services are relatively small and business logic is not sophisticated at all. What can go wrong?