Here’s a list of most common issues developers face with symptoms and solutions so you can enter 2017 with a New Year’s resolution different than a gym membership.
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.
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:
- http://martinfowler.com/bliki/TechnicalDebt.html
- https://www.atlassian.com/agile/technical-debt
- http://www.ontechnicaldebt.com/
- https://blog.codinghorror.com/paying-down-your-technical-debt/
- http://blog.codacy.com/2015/12/01/prioritize-technical-debt/
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:
- https://medium.com/@karolisram/preventing-burnout-for-programmers-12b4968adbaa#.qwed0lvb3
- https://arc.applause.com/2015/07/02/software-developer-burnout/
- https://www.quora.com/Usually-after-how-much-time-do-software-engineers-start-experiencing-burnout
- http://www.cio.com/article/2442809/careers-staffing/how-to-talk-to-your-boss-about-being-overworked.html
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:
- https://www.quora.com/What-are-the-characteristics-of-a-bad-software-engineering-manager
- http://swreflections.blogspot.com/2015/07/dont-blame-bad-software-on-developers.html
- http://www.cio.com/article/2391872/project-management/12-common-project-management-mistakes–and-how-to-avoid-them.html
- http://workplace.stackexchange.com/questions/44511/how-to-handle-an-incapable-manager-bad-project-management-and-poor-programming
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:
- https://www.atlassian.com/agile/metrics
- https://www.ibm.com/developerworks/agile/library/a-vt/
- https://medium.com/@MentorMate/how-to-manage-your-software-development-velocity-78cddd1ccbb7#.ypf8h5mut
- https://www.quora.com/In-software-development-why-is-measuring-velocity-important
- https://www.atlassian.com/agile/how-to-deliver-quality-assurance-at-speed-video
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:
- http://softwareengineering.stackexchange.com/questions/139683/how-to-deal-with-bad-code
- http://stackoverflow.com/questions/2100009/how-to-cope-with-bad-code
- https://www.amazon.co.uk/Working-Effectively-Legacy-Robert-Martin/dp/0131177052
- https://www.amazon.com/dp/0201485672/?tag=stackoverfl08-20
- http://blog.codacy.com/2015/06/18/6-ways-to-formalize-and-enforce-code-reviews/
- http://blog.codacy.com/2016/10/20/code-review-etiquette/
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:
About Codacy
Codacy is used by thousands of developers to analyze billions of lines of code every day!
Getting started is easy – and free! Just use your GitHub, Bitbucket or Google account to sign up.