I’ve worked in a wide range of environments, from being a one-man-band to being a member of both small and large teams, and what I’ve learned is that bad practices happen everywhere. It's inevitable.
What really matters is whether actions are taken to solve these problems.
What I'm going to list are what I think are the most common issues, some of which apply at an organizational level and others which relate to how a Dev team delivers code.
Permitting interruptive interactions across your team
Regular interruptions are probably one of the most common problems, especially within smaller teams and open concept offices.
If a developer is working on a specific problem, they're on their own mission with their own specific train of thought.
Any interruption when they’re in the middle of what they're doing is a big distraction, and it'll take them a lot of time to remember what they were doing before they were interrupted:
"What was that function returning again?"
"Why did I declare that variable up there?"
Everyone does it, myself included. We probably don't even realize it. And don't get me wrong, here at Uberflip we are always up for team work.
If another developer is stuck on a problem and needs some help, or if the question has a quick answer related to the project I am working on, I am cool with that. If the Customer Success team comes up with an urgent bug that needs someone to take immediate action, of course I'll put whatever I am doing on hold.
However, when something is not urgent then it would be better to send a chat message, an email, or schedule a meeting. Try to discourage walking up to a developer and tapping them on the shoulder for trivial matters.
At Uberflip, we try to prevent interruptions by providing developers with the option to use laptops. If someone needs some quiet time or they really don't want to be bothered, they can take their laptop into another separate room. This way they'll still be available if someone really needs them.
Failing to prioritize bug fixes versus new features
Writing new features is crucial, we get it.
The product has to constantly improve and existing customers need to see new things to keep them from churning. The problem - especially in small teams - occurs when the decision-makers are all about new features and don't care for existing bugs. You might think this is unusual, but it does happen a lot.
If the bug is not a blocker and it can be fixed manually by the Customer Success or Dev team, then they think it's okay if someone has to manually step up and fix the problem for the customer. Every. Single. Time.
During my career, I have seen procedures for “common” support requests. They listed step-by-step what to do in the back-end of the software if a customer experienced one of those problems.
I don't know how many hours I’ve spent on these fixes, sometimes even running SQL queries on production. Occasionally the Dev team would bring up that we should get to the root of the problem and figure out the bug. However, since it wasn't an easy fix and it would have required a decent amount of work, the organization did not want to invest the time of one their developers on such an issue.
With a growing Dev team at Uberflip we are always able to take into account existing bugs and fix them, while constantly improving our product. On top that, we have decided to make Friday our “Bugs’ Day”, where all members of the team have to try and focus on fixing bugs instead of working on their current project.
Neglecting thorough QA and code reviews
These are often underestimated, or done the wrong way. When developers do their own QA, then it's very likely that something wrong gets pushed to production. They might not take into account all possible scenarios, or just not be aware of some side effects.
Code reviews are also important. It's the best way to spot silent bugs (harder for QA to catch) and to reveal bad practices or bad performing pieces of code that, although working and therefore passing QA, would still be released.
Skip these two practices and chances are you'll probably release some code that will have to be reviewed and fixed within a day.
Here at Uberflip all the code that gets committed is reviewed by two other developers before being verified at a QA stage. Check out Keri’s article to learn about our QA and bug reporting process.
Documenting too much or too little
Last but not least, documentation!
All developers hate having to write documentation. They feel like it's a waste of time.
But the main benefit of documentation is clear when developers have to dive into some code they have never seen before to fix a bug or implement a new feature. If the code is not documented, it's more likely that the developer will spend more time figuring out what the code does, rather than applying a fix to it.
On the opposite end, we have some developers who document every single line of code. That's a bit overwhelming.
For example, the line of code:
$user = $model->getUserById($id);
...is pretty self-explanatory. I don't see the need to add a comment saying “Fetching user by id”.
Comments should be used the right way: for variables and functions declarations, blocks of code that are hard to read, unusual hacks that the developer had to use to get around a problem, and so on.
Comments are very expensive to maintain, so when you write them, keep in mind that if the code will change, the comment must also change; the last thing we want is documentation describing something that doesn't even apply to the code.
This was just an introduction to the way I see bad practices. Many people would prioritize things differently or might not even see a problem altogether with what I mentioned earlier, but these ones are, in my opinion, what affected me the most during my career so far.
In the end, avoiding bad practices in an organization comes down to common sense, and it has to be a team effort.
Which bad practices do you consider to be the most damaging in software development?
About the AuthorMore Content by Roberto Montebelli