At MojoTech, we’ve worked on many projects. While each presents unique challenges, over time patterns emerge. Healthy projects ship on time and work as expected, and they are built by empowered teams who respond quickly to changes. On the other hand, unhealthy projects ship late (or not at all) and frustrate teams, clients, and users. Worse still, it’s often difficult to recognize a project trending toward unhealthiness. Bad habits and small changes without an immediately observable negative impact on the project often go unnoticed. By the time a problem is observed, deadlines have already been missed, and the team is already frustrated.
Let’s talk about some trends to watch for, and what to do about them.
Project problems, probably
The most insidious problems result from imbalance. Absolutes are (relatively) easy, just ask the Sith. Balance, on the other hand, requires observation, reflection, and adjustment. Balance requires experience, which is notoriously difficult to train. So if you find yourself on an unhealthy project, don’t fret. Recognition is the first step on the road to recovery.
If there isn’t any code review, you’ve found your first problem. Before merging code at MojoTech, we must review it. It helps keep code quality high, while offering an important opportunity for team growth. Most often this responsibility falls to the tech lead, but we encourage the whole team to contribute.
Having many open pull requests can indicate a poor balance between review and production. Slow code reviews can also indicate a poor balance between code quality and the pace at which features are delivered. Constant regressions can indicate low quality. If there are many regressions, and the pace of feature delivery is still slow, it’s likely you should stop delivering features and work on paying down debt.
Be wary of quiet clients
It’s all too easy to consider a feature done when it’s been merged, but features aren’t complete until a client has used them and given feedback.
Deploy early and often. Use the software you build, and encourage clients to use it as well. Working software communicates more effectively than specification, and even incorrect implementations prompt valuable feedback. Prefer tools that make deploys easier for your whole team, like Heroku. Time not spent fighting with your deploy scripts can be spent developing features or fixing bugs.
It’s also important to remember that many clients don't know what a healthy project looks like. They just know what a done project looks like, so even if they seem happy week after week, they’ll become unhappy in a hurry when you miss a big deadline. You must hold yourself accountable, and ensure constant communication with clients.
Listen to your code
In order to respond to changes, we must first observe them.
Capture (and read) logs. Tools like Logentries or Papertrail make this easier. Logs aid debugging (especially sporadic issues) and can draw attention to problems that aren’t easily visible from a user’s perspective. For example, logging an error in a function that frees a resource could reveal a leak.
Monitor performance. Use application performance monitoring tools like New Relic to gain insight into application performance. They can reveal systemic issues that are difficult to catch during code review.
Track exceptions. Bugs make it to production all the time. Using tools like Sentry, Honey Badger, or Airbrake helps find them before clients.
Of course, it’s not enough to just see data; the real value comes from acting on it. Choose tools that make action easier, and make sure that your team has the appropriate level of access. Balance your ability to collect data with your ability to act on it. Imbalances frustrate teams. Too little data hinders troubleshooting. Too much data is noise. A healthy balance helps catch bugs and keep the team engaged.
It’s unlikely you’ll ever strike a perfect balance, and that’s okay. Every project is different, so avoid complacency and seek the balance that works for you. Your team and client will thank you.