Pramatr Blog

Over the past few years, I’ve worked on numerous projects that have grown very quickly but have lacked a structured approach to development. The code is grown somewhat organically, being used in ways never imagined and bent into shapes it was never supposed to make. In the very worst cases, it ended up with Spaghetti Code that is self-obfuscating and unintelligible (even to the original author).

To help prevent this situation, teams need to embrace processes to help introduce structure and discipline to software development. This can be daunting to some teams at first, but it’s a far more productive and appealing than a team that is constantly under-pressure with various fire-fighting activities.

Kent Beck has said previously that he is not a great programmer but just a pretty good programmer with great habits. I’m a firm believer in that statement, and I think that any team that doesn’t try to develop those habits is starting from a weakened position. I’ve worked on both projects that embraced change and tried to improve their development process and also those that didn’t. I would sooner work on the former type of project every time.

With that in mind, there are very simple changes you can make to a project to help foster better habits. None of these techniques is new or groundbreaking (at least anymore), but I am still amazed at the number of projects that still don’t embrace them. There is plenty of information on these techniques out there, so there is no excuse if you want to do some more reading.

1. Use an automated build system. Whenever you find yourself performing a common task, add it to your build file.
2. Use code conventions. If everyone has their own style problems are guaranteed. Merging code with differing styles is never going to be fun!
3. Make automated testing part of the development process. Code developed without tests isn’t finished and can’t be signed off.
4. Promote Test Driven Development, not everyone will want to do it and not everyone will understand it. Work with the team to understand how it can help their development, focusing more on writing automated tests and less time ad-hoc testing and reviewing log files.
5. Accept that some people won’t initially buy into automated testing, but ensure that they are writing tests. Whenever they aren’t writing tests, understand why they aren’t doing it. Review the tests that are being written and also measure unit test coverage. Don’t use the coverage report as your only metric though. Anyone can fake up better coverage, focus on writing good tests and the coverage will follow.
6. Help the team understand different testing techniques. When to use them and when not to!
7. Refactor code frequently to adapt to changes. Refactor as you go and make it a core part of the development process. Use your IDE’s refactoring support to make things easier.
8. Don’t ignore warnings in your project, instead treat them as errors. If you continue to ignore them, the project will soon have so many that they will become virtually meaningless.
9. Enforce your architectural rules in a meaningful way. Long architectural documents might look impressive, but a team needs something more interactive when developing code.
10. Learn your teams code smells, help your team spot them, fix them and avoid them in future. To improve quality in future, you have to learn from the mistakes of the past.
11. Prefer simple elegant solutions over complexity. Writing complex code isn’t big or clever. If another developer tries to impress you with some complex solution they’ve just developed, give it a second opinion to see if it actually needs needs to be that complicated. If everyone owns the code, they are just as responsible for it’s maintenance as the original author. Do you really want to maintain something you don’t understand?
12. Review other developers code frequently. Not only will this give the code a second opinion, but it will ensure that more than one developer has knowledge of the code. Reading other peoples code is a skill in itself, the more code you read the better you become at reading it!
13. Promote Continuous Integration of code and introduce a Continuous Integration build system. You need to be running the quality reports and tests frequently, otherwise they just won’t get run. You want to know as soon as possible if something is broken. If someone breaks the build, their first priority is to fix it.
14. Add a PMD task, a PMD/CPD task and a FindBugs task to your build file. Run the tasks frequently and fix up the issues they highlight. Start with a strict rule set and tweak it fit your code base.
15. Encourage your team to run the tests and review the quality reports before they commit changes. Ensure you review the reports frequently (at least at first).
16. Encourage your developers with targeted reading. There are plenty of good books out there, let them know which ones they need to be reading to improve their skills.
17. Learn from people who have been there and done it. There’s nothing wrong with making your own mistakes, but some mistakes are more expensive than others.
18. Encourage your developers to share! If they’ve read about something that might help your team you want to know about it! The team needs constant feedback to improve and adapt to change.
19. Don’t try to implement everything at once! Incremental change in your process and code is the best way to succeed. It’s very tempting to fix everything at once, but in my experience it just doesn’t work. People need time to understand the changes you’ve made and the effect it has on their work.
20. If something isn’t working for your team, don’t bury your head in the sand and ignore it. Discuss it, address it and learn from it! There is no point trying to pretend a process is working if it clearly isn’t, in many ways you might as well have no process at all.

This is by no means meant to be an exhaustive list and as I said previously none of it is new or groundbreaking. Hopefully you’re already doing some (if not all) of these already and you are seeing the benefits they deliver. This is a list that has worked for me in the past, and one that I am currently working through on my current project.

Agile development processes embody many of these best practices and provide an À la carte approach to improving software development. A good reference and starting point is Extreme Programming, there are also many excellent agile mailing lists.

As a final note, it’s vitally important that you remember these techniques are applied to help the team improve their process. I strongly believe there shouldn’t be a finger of blame when the build is broken. Whoever breaks the build fixes it, end of story. If the code quality or coverage reports indicate things have actually gotten worse overtime, discuss with the team what went wrong and why. You need to address these issues as soon as they arise, fix them and move on. If someone isn’t following the process, work with them to try and understand what the problem is. If you can’t get them back on track, Peer pressure can also be a valuable last resort .