How to Select Software Engineering Tools without Inciting Team Rebellion

Lately I've been thinking a lot about how we choose the tools we use to build software, and how important those choices are. I figured it might help others if I wrote down my own thought process for selecting development tools, so I published this post on Medium: "Choose Your Weapon: How to Select Software Engineering Tools without Inciting Team Rebellion".

This was my first post on Medium where I received help from others using their editing tools. Reviewers can add private comments using the same mechanism that reader use to make public comments. I received some great ideas from Tyler Fitch, and wording advice from my wife. The collaboration features worked great, although my wife missed the power-tools for tracking changes offered by Microsoft Word. This is also the first time I wrote the whole post in Medium, instead of saving drafts elsewhere then pasting it in, so I must really trust their editor.

Thus concludes my obligatory annual blog post. At this point I'm just writing on Medium and using my blog for editorial. Am I doing it wrong? Also, if you have any thoughts about selecting development tools, I'd love to hear them :)

Start the Conversation with a Programming Standard

A common topic in my software engineering courses is: "How do I help my team increase the quality of our software?" There are several best practices we can use to reduce defects in our code and ensure that it has all the good "ilities" (Readability, Maintainability, Testability, etc). One of the easiest techniques is to create a Programming Standard document.

What Are The Benefits of Using a Programming Standard?

Many good things can happen when you draft up a programming standard. I think one of the best effects is that your team will start discussing best practices and quality. One or two people can create the document then present it to the group for discussion. If everyone starts abiding by the guidelines, it can add consistency to your code base, making it seem more like the work of one author. The person maintaining the code five years from now will love you for it.

Also, you may want to start doing code reviews at some point. Numerous studies show that finding and fixing defects early is much cheaper than discovering them after you release. Code reviews can help spot problems before you release to QA. If your team has already agreed on a programming standard, you can use it to evaluate code. The religious debates about curly brace placement will have already occurred, so you don't have to re-hash those discussions during each review.

How Do I Get Started?

My advice is to aim for a one or two page document. Break it up into a few sections (e.g. Naming Conventions, Comments, Error Handling). Include a brief description at the start of each section that explains why the topic is important. Try not to use too much strict language ("Thou shalt never...") and focus on general guidelines ("Avoid methods with more than X lines of code").

If you're looking for examples, the book Code Complete by Steve McConnell includes lots of checklist and well-researched rules.If you'd like to see the programming standard I created in class, send me a note.

Do you use a programming standard on your team? Is it helping?