Working on a team can be tough.
It’s necessary for rapid, effective development- a team can work much faster and has a much larger knowledge base than a solo developer. It’s also necessary for security and building a robust application- a team of eyes will spot issues and possible improvements that a solo developer might miss. So I understand the many benefits.
But it also has pitfalls. We are working on a .net API for our Angular application. As part of this API, an admin can change the email address in a user’s account (which also serves as their username). During testing, we found that edits to the email weren’t “taking”. We could update anything else, but when trying to update the email, the dreaded “500 Server Error” message kept popping up.
So I started digging. The error in the stack trace shouted at me: “Object not set to instance of an object” – which, though past frustrating experience, I learned is a null pointer exception. Somewhere in the API’s Put method, we were referencing a property or method on an object that had never initialized.
But I just could not see it. I started working as a developer solo- which can be difficult in it’s own way, but one advantage is that I (usually) know where I put things. Where I initialize variables, where I add logic, etc. Not always- sometimes lazy present me really screws over frustrated future me- but generally it’s pretty quick to find the path of my previous thinking. I couldn’t see the error in this codebase by looking, so I started logging to the console (see previous post!). Eventually, I got to the null object- a duplicate call to a method we use to get a user info object.
We work with another team remotely. They do great work and having worked solo, I appreciate that they each have a head full of tips and tricks and knowledge that I may never have. But sometimes they might not examine anything too deeply before starting on the coding. They receive a job and a prototype or existing file and build it/update it with new functionality- they don’t necessarily analyze what’s already there for conflicts.
In this case, they had been tasked with adding a feature to the .net code to allow an admin to edit the access level of an account (employee vs admin). When they added this to the update method, they ignored the code above that covered updating the rest of the account. The method variables were up there- including the one that instantiates the object representing the user being updated. This is done with a reference to their unique user id (which is never changed). In the new code, an attempt was made to create a user object by referencing their email address.
And there’s the bug. You can’t get a user by email if they’ve just changed that email (or if you get really unlucky, and that email already exists in the system, you’ve got an even trickier bug). The fix to this bug was ridiculously simple- remove this 2nd user object and update the calls below it to reference the original user object. Works like a charm now. Finding the bug was trickier- it was hidden in the middle of a method and the reference to the user was not named something obvious (it was called “roles”). When I scanned the code, “roles” didn’t really register as being involved in an email account update, but it was the culprit.
A team can put processes in place to mitigate the issues of distributed development- but it requires some extra work.
- A style guide and naming conventions is a great step. Make sure all your devs are on the same page by putting the requirements on an actual page (or a virtual one).
- Take it a step further and create a set of linting rules to enforce the guide- maybe make an update pass all the checks before you can push to git or svn.
- Do code review sessions- instead of moving forward with new code every day, take the time to review what was written yesterday. Just because something compiles and outputs what you want doesn’t mean it should be in the final product.
This can be tough to sell to a supervisor- there’s no real immediate benefit as far as project progress or new tasks checked off a list- but it can really save time down the road. Sometimes, it takes one developer to push for such a shift- a shift that will make your and your co-worker’s lives easier.