New year’s resolutions for software developers

Published in

Codacy

6 min readDec 21, 2016

Here’s a list of most common issues developers face with symptoms and solutions so you can enter 2017 with something more than a gym subscription.

Over the past few years I’ve been meeting with lots of different companies while working on Codacy. From smaller to large enterprise companies, every team seems to face combinations of the same set of problems.
Below are the most common problems developers and teams are facing.

Some of the biggest problems identified on Codacy’s ebook: ultimate code review guide

Technical debt

The number one problems developers face is Technical debt. This is according to our survey and ebook. There are many reasons why technical debt is a problem for developers

It is never a requirement but it’s mandatory: No one ever asks to pay back technical debt as a feature. You’re supposed to manage it as part of your development. It is your burden to carry. And you have to take care of it otherwise you know what happens (illustrative left image)
It is hidden: many times you can’t quantify your technical debt which makes it invisible and very much gut feeling many times.
It is a heavy burden that few people understand: few people in any organization are capable of understanding the reasoning behind having cleaning sprints and not be shipping new features all the time.
It can put your project to its knees: you already know this.

In summary: can’t cook in a dirty kitchen, as you cook the kitchen gets dirtier, no one cares about the kitchen being dirty just give me food.

Symptoms:

Delivering new features requires a lot of effort
Team spends more than 50% of their time either fixing bugs or maintaining older code

Solutions:

Dedicated time between sprints to clean code
Be transparent about the true velocity of the team taking technical debt into consideration
Pay as you go, don’t let it accumulate

Resources:

Workload

One of the biggest problems development teams are facing is big workloads. This many times is a combination of hard requirements in short periods of time. To individual developers it is many times a reason for burnout and stress. The company needs to ship code with unreasonable deadlines, few people push back because of the necessities of the business and developers get a lot of work to do.
Many times this is a temporary period (crunch modes) where important deadlines must be met. However this is a serious issue since it will cause Burnout after a while and that can hinder you from working for a while. For this reason, it’s the #2 problem developers are facing today.

Symptoms:

Too many “crunch” modes
Burnout feeling
Not being able to ship all your features; not all stories are finished in a sprint
unhappy developers;

Countermeasures:

Good planning and transparency: It’s great to talk to your manager or team leader about the lack of bandwidth to solve all technical problems you face.
Power through but explain this is not sustainable
Take some time off between sprints or after a long push

Resources:

Management

In the survey we made, this was a bit surprising. It put it as a gag but got surprising results since developers say management is their #3 problem.
Management problems can include many aspects and cause other problems. It can be that the development managers are not handling the team well by pushing too hard or not understanding enough of the technology or requirements. It can be that product/project requirements coming from above are unreasonable and don’t make sense. It can include project management and problems inherent to it. It can be a bad personal relationship with the people on the top.
But almost always, this will be caused by bad communication. Bad communication and not establishing expectations can lead to frustration.

Symptoms:

You don’t have a good relationship with your manager
Management keeps pushing unrealistic deadlines/features/product
There’s climate of frustration in the development team
Too many meaningless meetings filled with buzzwords and hashtags

Countermeasures:

Communicate better. Have a good conversation with whomever is needed. Bring attention to issues.

Resources:

Speed of delivery

Not surprisingly, this is the number #1 problem for VPs and Directors of engineering. It makes sense because this is one of the most important metrics for those roles. Speed of delivery can be defined as the time between the creation of a ticket to the time is ready to be pushed into production. Many times there are many layers between the delivery of software and putting it in production for a developer. There’s QA, there’s deployment processes from Devops teams, depending on the platform there can be timely releases (e.g. web vs mobile). There are many causes for bad speed of delivery. It can be that the team is not delivering at a good speed (this in itself can have many other causes like project being complex, riddled with technical debt, etc), unreasonable deadlines, long review processes, hard dependencies between pull requests, badly defined requirements which makes the team re-do their tickets, bad processes in place, #agile, etc. This is an easy problem to spot but hard problem to diagnose in many teams.

Symptoms: normally easy to spot as it’s coming from management

Countermeasures:

Try to identify the root cause of not delivering software in time. This by itself can be a hard process because self diagnosis is hard. Use metrics to understand the problem. List all of problems leading to bad velocity and divide and conquer.

Resources:

Code quality

The final listed problem is code quality. Code quality can be a variation or even seen the same as technical debt. Inferior code quality can contribute to technical debt. You can measure code quality in many ways. A good summary (taken from Quora) is:

Follows a coding standard, uses linting
Clear and understandable design and implementation.
Well defined interfaces.
Ease of build and use.
Ease of extensibility.
Minimum extra dependencies.
Tests, examples and good unit test coverage
Documentation, better yet — self-explaining code.
Up to date means to contact the developer.

Almost always, bad quality is caused by shortcuts. The pressure to ship makes developers push less than great code that will haunt you later on in life.

Here’s a great way of looking at the required quality of your code regarding maintainability:

When producing software, think of your support engineering team. The support engineers will have to read those lines of code, reason about them and be able to identify possible bugs. Write code for them and you’ll do a great service to your team. If that team is you, then it’s a self serving best practice

Symptoms:

Bad code quality shares the sames symptoms of technical debt.
People not being able to understand code
Bad code coverage
Hard to extend or add new functionality

Countermeasures:

Good code review practices
Adopt best practices in your development
Document, test and use build tools
Make sure everyone in the company is on par with required standards of a code base
Use Codacy, our tool to review code automatically and manage code quality

Resources:

Honorable mentions

Below is a honorable mention list of problems developers from our survey:

Changing specs
Documentation
Learning
Legacy software
Project / Stakeholder management
Size & Complexity
Spec definition
Team dynamics
Testing

From all of the team in Codacy, we wish you happy holidays and a great new year filled with only the best code decisions possible!

Thanks for reading! If you enjoyed it, hit that heart button below and/or share! Would mean a lot to me and it helps other people see the story.

BTW: we’ve released a new ebook recently:

New year’s resolutions for software developers

Technical debt

Workload

Management

Speed of delivery

Code quality

Honorable mentions

From all of the team in Codacy, we wish you happy holidays and a great new year filled with only the best code decisions possible!

Thanks for reading! If you enjoyed it, hit that heart button below and/or share! Would mean a lot to me and it helps other people see the story.

Written by Jaime Jorge