Last time around, I presented the idea that "software craftsmanship" might more approachably be framed as gap analysis. With that mindset, I started a discussion about how you could recognize the sorts of gaps in your team and code that the craftsmanship movement and its practices can help address. Today, I'll continue in that vein with some other gaps that you should watch for.
Developers Reluctant to Touch Certain Parts of Codebase
“Oh, no, that means we’re going to have to touch the batch processing module, and you definitely don’t want us doing that. You’re better off just forgetting about this feature request. But if you go ahead anyway, we’re going to need to work on that and that only for the next six to nine weeks.”
Have you ever heard (or said) something like this when asking about a feature or change? Those are the words of a developer that’s afraid of a particular piece of code. Developers are afraid of code when it’s extremely perilous or unpleasant to touch that code. When one or both of those things are true, you typically have a pocket of bad code.
Keeping your code clean is all about not having pockets of code like that. Developers should be agreeable to making additions and modifications wherever they are needed and without much worry about their actions. If you’ve grown used to situations where parts of the code base are untouchable, there’s a better reality out there for you to pursue. Your situation is not inevitable.
Manual Steps and One-Off Tweaking
Does building the software happen via a single team member getting files from source control, doing some magic on her local machine, and then having a deliverable software product ready to go? Are deployments affairs that involve lots of copying files, tweaking server settings, and doing random things to the database? When a new team member comes on board, does he spend two or three days installing software, editing the registry, and doing a whole litany of other things to prepare to work on the codebase?
If any of these things are true, you can improve substantially. Like other subjects here, none of these are inevitabilities. Having a good software development operation is about a lot more than just writing good code. Your team should be automating everything it does to make itself more efficient, including builds, deployment, and setup.
Frequent Need to Undo Apparent Progress
Is it common to hear about the team doing a deployment only to roll it back? How about having conflicts with source control or merge problems that result in progress being undone? Is it common to hear someone say something like, “Let’s go back to an earlier version of the code when things were working?”
A lot of false starts and backtracking indicate deeper underlying issues. While this sort of thing might be needed every now and then, it shouldn’t happen with any regularity since it means by definition that the team is spinning its wheels and wasting its time. It is certainly possible to get out of this trap.
No Mechanism for Automated Testing
If you ask the team how it tests its work, is the answer something along the lines of “we give it to QA”? If playing a little with the application in their dev environment and chucking it over the wall to QA are the only means the team has for testing the software, there’s plenty of opportunity to improve.
There’s a lot of buzz around automated testing and, specifically, test driven development in the software craftsmanship community. And rightfully so, in my opinion. Test driven development and automated tests provide all sorts of benefits to the group that uses them. But having automated testing simply because a lot of people think it’s a good idea isn’t a particularly persuasive reason.
It’s important to automate testing efforts because it makes verification of the software more efficient. It might take a human days to run a regression analysis on an application following some changes, whereas a testing tool can do it in minutes, or even seconds. If your team isn’t automating its testing, it’s sorely missing a much higher degree of confidence in the stability of changes.
And Many More…
This is by no means an exhaustive list of signs that your team could benefit from some of the practices adopted by those billing themselves as “software craftsmen.” No doubt there are plenty more that you could think of, if you chose. And there’s also no doubt there are improvements that could be made having nothing to do with the software craftsmanship movement. But improvement has to start somewhere, and if your team is suffering these pain points, this is as good a place to start as any.
