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 the workflow is that Scmbug rejects source code commits that are (a) missing a bug number in the commit log, and that are (b) issued against bugs one shouldn't be working on. Rejecting commits is instant. I get an error right away if I'm changing software when I'm 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. I make many decisions I soon forget when I'm programming and at some point I can't tell how to backtrack or what to do next.

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

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

The surprise is, by the time I type a plan, I 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 my 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 I can't remember all bug numbers, I don't, and I don't switch between them. I recall only a couple and keep working on those. That's a great way to stay focused on a hard bug and make a breakthrough. It also helps keep working on the last bug I committed against because it's still in the shell history. Pressing the up arrow in the shell retrieves part of the commit command, containing the bug number needed in it.

Because Scmbug forces me to have a bug list, it also lures me to start programming if I'm just sitting down unmotivated and tired. A bug list serves as bait to start, if only for the cheap thrill of crossing something off. For interesting software that takes time to write, starting isn't just 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 the design before I resume programming.

So not only does Scmbug deter from writing bad programs, it also helps 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 enough willpower to attempt the better, laborious solution.

That to me is the most surprising result of Scmbug. It uncovers one's willpower. If one can't stop to ask why they lack in willpower. Scmbug doesn't stop there though. It develops your willpower, step by step, so you someday tackle bigger problems. Once one solves 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 often forget where I was. The difference there is I read the last comment in the bug and remember.