Code Quality: the key to agility in software development

One of my pet projects at the school of public health has been to try to bring my team to use enterprise grade development techniques and processes. It was made a lot easier by our move to AWS, giving us a good excuse to start using code versioning and continuous integration and Harvard’s IT Academy  which was promoting and training us at using AGILE software development. It was a fantastic opportunity and a great experience. We started from scratch and worked it all out as a team. I will not cover the entire process as this would take several posts, I will rather focus on one specific topic that I researched a lot and I think is a too often overlooked while being critical: Code Quality.

What follows is a curated list of articles and blog posts about Code Quality that, I hope, will help you understand how critical it is for any team that wants to become truly AGILE.

Why Code Quality matters?

How to improve your Code Quality?

Bellow are 3 types of improvements you can implement that will greatly improve your code quality. I listed them by difficulty of implementation ( both technical and human).

Style-guides and coding standards

TL/DR: Take some time to find a style-guide/coding standard that you like, follow it to the letter, enforce it using a linter/sniffer tool.  Your entire code-base should look like a single developer wrote it.

I’ve read a lot of arguments in favor and against coding standards. I’m all in favor. Having your entire team follow the same syntax is the first step to code that is easy to understand, review, modify and optimize.

Some examples of Coding standards:

Code/peer reviews

TL/DR: Evidences are overwhelmingly in favor of code reviews, so please make them an essential part of your workflow.

Peer reviews have so many benefits that I wont list all them there. However I will point out that to be efficient and not a waste a time, everyone needs to take code reviews seriously.

Architecture, design patterns and general methodologies

TL/DR: This is going to be harder to implement, but is the final required step to create truly enterprise-grade software.

That’s where, IMO, it gets a little more complicated. Because  the cost vs benefit of these techniques and methodologies may vary depending on the project. This will also require some discussion at the team level and will require your entire team to do some research, learning and more importantly change the way they develop. Finally they are a million of them: List of software development philosophies.

I think the key here is to pick one or two, implement them and slowly add new paradigms as your team matures and your project grows.

Some of my favorites:

Finally embarrassing Object Oriented Development and Test Driven Development is probably a good idea too.

A few good reads to give a little more context:

Conclusion

If you are starting from scratch, there is a lot to be done, but take it easy. One step at a time, don’t try to refactor everything on day one. Remember that is is supposed to help you to be more efficient on the long run. Yes it will take you some extra efforts and time at the begging and yes there is never a good time to do this…Do this incrementally, test new ideas on smaller projects.