Let’s talk about project management!
“Don’t even think about it Sam, just don’t”
Aww, but it’s the fun kind I promise! The kind where technology does all the work!
“… I’m listening”
Good! I shall regale you of my vision for a perfect automated future!
“… Okay, but tone it down a little”
… Fine.
The Premise
I saw an article about Trello which reminded me that I had tried to use it in a group at Uni to do a kind of Agile development feature tracking sprint tracking thing… And it had fallen flat on it’s face because it’s such a manual process it’s just additional overhead with no real gain (at the scale we were working at any rate, I’m sure it has it’s uses).
Which got me thinking. You know what this sort of thing needs? An incredibly overzealous amount of integration and automation.
So I whipped up a quick mental image of how I’d want this sort of feature tracking type thing to work.
By combining an IDE, Activity Tracker, Source Control, and an actual feature management program, you can have a pretty good, pretty reliable, reasonably friction-less setup.
Here’s how it works:
The IDE
The backbone of development, you need a thing that lets you do your thing (from plaintext editor, to IDE-ish, to a full-fledged IDE). But you also need it to have an automatically configurable window-title based on an external data source, which I will explain the reasoning for at a later stage.
Well alright then!
The Activity Tracker
This bad boy is why you need the configurable window title. The Activity Tracker will sit there and pay reasonably close attention to the window you have in focus, so it can track all your activities (and time taken doing them). If it’s a fancy one that reads the window title as well as the process name, it’ll give you an additional layer of specificity! This is important in distinguishing between “You were coding” and “You were coding this thing“. I will explain how this is useful at a later stage.
Fiiiiiine, I’m doing it.
The Source Control
This is that external data source I was talking about earlier for the window title. Preferably using something like Git, but definitely something with cheap branching. Dedicating a branch to a feature is a time-honoured practice, and setting your window title to the branch name is a good way to indicate to your fancy Activity Tracker, what feature you’re working on!
“Okay, I think I see where you’re going with this… You’re thinking hook the Source Control to the Feature Manager and the Activity Tracker to automagically associate what you’re doing at any given time with a feature, and track the amount of time spent on it! Right?”
Oh hey, I almost forgot you were here!
You’re a pretty eager beaver, I like that!
But I’ve gotten in the habit of explaining the thing as well as how I’d use it… You sure you don’t want me to explain the wonders of Git? Shouldn’t take too long…
Okay Okay, God you’re impatient!
The Feature Manager
This little guy is just like Trello. You have features, you have dependencies, you have effort calculations… All that good/boring stuff! You can even organise it into sprints and the like. The big difference is that it talks to the Activity Manager and the Source Control to take the weight off you manually updating and tracking things!
“Aah, now we’re getting to the good part!”
Heck yeah we are!
The Prestige
Damn that’s a creepy movie, but I digress!
This is the part where everything comes together!
Have the Feature Manager create a branch in Source Control for every feature you add, and add a feature in the Feature Manager for every branch you create in Source Control, since you’re (meant to be) doing that sort of thing anyway, why not hard-link the two!?
It’s a lot easier to remember to switch to a branch than it is to create one! Not to mention easily creating a documentation audit trail for changes/progress. You could also read the level of frustration in the commit messages to help gauge levels of difficulty for future features.
Using the Activity Tracker, you can link the amount of time spent with the IDE having a window-title of ‘branch-name’ to specify to within a reasonable margin, precisely how much time you actually spent actually working on the feature associated with that branch! And by you I mean automagically having it communicated between the two systems, because automation!
So now, all you need to do is check out the appropriate branch (or create one if the feature is brand-spanking-new), get to coding in it, and all the rest will be sorted for you! Heck, you could even go so far as to MORE tightly couple the Feature Manager and Source Control to allow branching off feature dependencies (only 1 source allowed to base a branch though)… But an even tighter level of coupling could involve periodic auto-merges of those dependent branches into your feature’s branch!
“Why, the only limit is your imagination!”
Epilogue
Sadly, yes…
Realistic limits not so much I’m afraid, this isn’t actually a thing…
But crikey it’d be neat!