At Eleven Winds, one of our core beliefs is that it’s critical to make sure we have in place the best possible processes, culture, and methods of team communication, and that these will be the keys to our success. We’ve gone through some trial-and-error and have come up with this short list of practices and processes that have the biggest impact on our end goal, which is creating maximum business value for our clients.
This idea comes from the concept of blaming the system, not the individual. With that in mind, here are some of the best ways we’ve found to go about this.
Do Code Reviews
Jeff Atwood makes a big claim when he states that “peer code reviews are the single biggest thing you can do to improve your code”. I couldn’t agree with him more. I could write a whole post on how and why code reviews make such a big impact, but here’s a quick overview:
- The reviewer will catch some bugs. Obviously. This will result in less bugs in production code.
- Reviews spread knowledge of the code to other members of the team. Code reviews ensure that every piece of code is at least partially understood by more than one person.
- Junior and intermediate developers will learn a lot from the feedback of senior developers
- And most importantly: developers who know that their code is going to get reviewed will produce better work, especially if the reviewer is someone they respect. No one wants to show their own subpar work to someone they respect. For most people, this is powerful motivation to produce the best code they can.
Use Great Tools
There’s a near infinite number of tools that are designed to make software development easier. Great tools make developers happier, more productive, and typically take care of the more tedious aspects of the work, leaving more developer time for the important stuff.
This also applies to hardware — developers today expect dual monitors, SSD’s, and large amounts of RAM. Anything less will just make it more difficult for developers to get real work done, leaving them frustrated.
Have Coding Standards (and adhere to them)
A set of standards help to keep code clean and ensure all your developers are on the same page. A code base can be difficult to read when there are different styles littered throughout.
Automated tests become absolutely critical in the maintenance phase of a software system when you need to make sure that a bug fix or a new feature doesn’t break any of the already-existing code. Without automated tests, you have to either manually test all the existing functionality, or not bother testing other aspects of the application. Needless to say, manually testing takes far too long and is error-prone, and not testing at all(or testing very little) will lead to new bugs being introduced.
Writing a set of unit and integration tests and then setting them up to run automatically with every build allows software teams to ensure that old code is never being broken by new code, without having to resort to extensive manual testing every time.
Rather than blaming individual developers for introducing another bug with that latest update, we’ve improved our processes by creating a substantial set of automated tests to prevent it from happening again.
Deployment processes are often complicated and error-prone. With applications that have large user bases, deployment errors can cause all sorts of issues including downtime. These can result in user dissatisfaction due to the service interruption and general embarrassment for the makers of the software. One way to ensure that these types of situations continually crop up is to make sure the deployment process is as manual and arduous as possible. If you’re trying to avoid these types of situations on the other hand, try allowing your developers some time to automate their deployments. You (and they) will be happy you did!
Have Dedicated Testers
To be clear, when I refer to a “dedicated tester”, I don’t mean someone that spends their time testing an application by manually clicking through screens. Rather, I’m referring to someone who is in charge of quality control and makes it their mission to make sure as few bugs as possible get through them into production. They would do this by focusing on building extensive sets of unit & integration tests for all existing and new functionality.
Now, I mentioned that it’s ideal for this person to be dedicating all or most of their time to testing. This is because the context-switch that’s required to go from developing to testing is difficult. They require such different mindsets and ways of thinking that a developer who spends 20% of their time writing tests may not do a particularly good job because they haven’t managed to fully flip their way of thinking. This can be particularly common when a developer is writing tests for code that they wrote,
because it can be very difficult to not write biased tests.
Use a Bug/Task Tracking System
This one may be obvious, but it’s also essential. Good software teams are organized. You can blame your developers for forgetting about that bug that was found two weeks ago, or you can use a bug tracking system to ensure that it never happens again. Having detailed notes in a bug tracker also means that they’re available to anyone on the team, rather than just being in Johnny’s head and inaccessible when he’s out of the office or on vacation.