Scmbug helps write software in a disciplined way [1]. It ties what changed in the software source code with why it changed.

This helps establish a software change management process. Scmbug connects a source code version control system with an issue tracker, and this connection helps track changes, plan what to work on next, and trace problems back to their root.

The most noticeable change in your workflow is that Scmbug rejects source code commits (a) missing a bug number in the commit log, and (b) against bugs you shouldn't be working on. Rejecting commits is instant. You get an error immediately if you are changing software when you are not supposed to.

If it feels somewhat silly to use software that forbids you from writing software, know that it feels less silly than not remembering what you were thinking when you first wrote the software. You make many decisions you soon forget when you're programming and at some point you can't tell how to backtrack or what to do next.

With Scmbug you can find your way back. You leave a trace back to why you wrote each line like Theseus left a thread back to the entrance of Minotaur's labyrinth. You also leave a trace towards the opposite direction. For each bug you file, Scmbug inserts commit logs in the bug as comments so you know what changed in the source code to fix it.

The biggest benefit may be that Scmbug keeps the momentum going. It gets you to act when you discover a bug. Since Scmbug doesn't let you commit source code unless you first file the bug in the issue tracker, you simply start typing to file one. That's a step you tend to skip when you can change source code without constraints, which may lead to sweeping a bug under the carpet or giving up if the bug looks hard. And that's probably where Scmbug helps most. You nearly always have some thoughts on what the problem is. Since it's easier to keep typing if you already are, by filing the bug you stay keystrokes away from also typing how you plan to fix it.

The surprise is, by the time you type a plan, you also work up the willpower to continue.

That's what it takes, constraint and to keep typing. This seemingly minor mental push is a big advantage for a mind swimming in problems all day. You start with the innocuous thought that filing a bug is easier than fixing it and you end up working the courage to mount an attack.

Another advantage is Scmbug narrows your focus to the point that context switching to other bugs becomes unthinkable. The trick here is that being forced to provide a bug number makes it hard to look other bug numbers up. Since you can't remember all bug numbers, you don't, and you don't switch between them. You recall only a couple and keep working on those. That's a great way to stay focused on a hard bug and make a big breakthrough. It also makes it easier to keep working on the last bug you committed against because it's still in your shell history. Pressing the up arrow in your shell retrieves part of the commit command, containing the bug number you need in it.

Because Scmbug forces you to have a bug list, it also lures you to start programming if you are just sitting down unmotivated and tired. A bug list serves as a bait to start, if only for the cheap thrill of crossing something off. For interesting software that takes time to write, starting isn't only half the battle but a daily battle.

Figuring out what to do next isn't the only benefit of Scmbug though. It also helps figure out how to backtrack.

I noticed Scmbug changes how I choose what the software I'm writing should do. It forces me to stop and think. Since I can't make changes at will, I have to justify why I'm making them. I stop to find a bug number for a change and soon can't help but think: why am I doing this [2]?

The habit this develops is to pull back and look at the big picture. If I'm tempted to go down an unpromising path, I'm pulled back to the todo list that is my issue tracker, and most times, I notice soon enough. And if I'm already working on something interesting I often realize my assumptions are incomplete. This leads to filing new bugs about what I just discovered, which helps make progress in my design before I resume programming.

So not only does Scmbug deter you from writing bad programs, it also helps you think through writing the good ones.

If you habitually stop to ask why when programming, you'll often find that for a big class of problems the answer isn't that a better solution would be impossible, but that it'd be a lot of work. The discovery this leads to can be unsettling. That what often stopped others who faced the same problem, and what's stopping you without daring to admit it, is looking the problem in the eye: gathering sufficient willpower to attempt the better, laborious solution.

That to me is the most surprising result of Scmbug. It uncovers your willpower. If you can't stop to ask why, you lack in willpower. Scmbug doesn't stop there though. It develops your willpower, step by step, so you someday tackle bigger problems. Once you've solved small, laborious problems over a week, it becomes easier to imagine solving big, laborious problems over a month. Bigger problems start to feel within reach.

Develop the habit to ask why a lot and someday you reply: why not?

Scmbug can't always protect a change management process from developers aiming to subvert it. It can't help if you commit changes for separate issues against the same bug number. But it catches honest mistakes. If you want to write software in a disciplined way, Scmbug gets you halfway there.

Of course Scmbug can only help with thoughts circling in your mind. It'd be miraculous if it also generated ideas but unfortunately it doesn't. There are other ways to do that.

There are two parts to Scmbug. Integration glue is added as hooks in your source code version control system like CVS, SVN and Git that lets Scmbug control commits. The glue talks to a server daemon to integrate with an issue tracking system like Bugzilla, MantisBT, and RequestTracker.

The latest version 0.26.22 is available here, there is a user manual [HTML single] [HTML multiple] [PDF], and an issue-tracker.

Scmbug now has enough of the features one needs that I haven't worked on it in a long time. Many companies installed Scmbug at the time I was writing it.

Neither DynAMOS, nor UpStare, nor Scmbug itself would exist without the first version of Scmbug.


[1]  Discipline isn't as helpful when starting to write the software. If you're just exploring ideas it's better to indulge in what seems interesting even if you don't know why. Discipline is helpful later, after a direction becomes clear and there's a lot to do.

[2]  It may seem odd not to know why you're doing something but it happens a lot when one bug uncovers a swarm of others. You have to stop and understand the root cause. Then you need to rethink why you should fix any of them or why not change direction completely.

It also isn't odd not to know what you're doing. When I get interrupted I sometimes forget where I was. The difference there is I read the last comment in the bug and remember.