I’ve been with Blade Games World working on Jumala for a couple of months now and I’m having a blast. The team is fun and the work is very interesting. However, as is often true in startups, there’s just so much work to do that infrastructure and tooling has sometimes gone by the wayside. I can understand that – things that contribute directly to attracting new users and impressing investors always rank higher than things that don’t – but it’s also true that the only way to go fast is to go well. I thought I’d write a series of blog posts about the things I’m doing to help the Jumala team go fast. There isn’t going to be any genuinely new thoughts here but I hope my rehashing of the same old thoughts will help others who are still in the same boat.
No time to sharpen the saw
It’s always amazing to me how much time a team can waste doing things in a very error-prone and tedious manual fashion just because no one makes the time to stop and write a script to do it automatically. I mean, we build software for a living, right? We sit around all day writing code that makes computers automatically perform jobs and solve problems for other people but we find it difficult to do the same thing for ourselves.
I fall into that pit quite often myself. I’ll find myself repeating the same manual steps over and over again, having to remember how to do it every time, and probably overlooking or messing up some parts, and part of my brain says, “You know, we really ought to write a script to do this for us.” The rest of my brain responds, “Shut up, we’re too busy too fool around with that right now and just doing it by hand takes less time than building some automated widget.” Well, yeah, that’s often true for a one-time event, but by the third or fourth or twentieth time I’m muddling through the same problem by hand, the first part of my brain starts snarkily reminding me that if I’d just scripted it back in the beginning I’d be way ahead on time now.
If you did it twice by hand, script it
Of course I don’t want to waste time building tools that won’t ever pay back what I invested into them. Many times I do something by hand that’s truly a one-time task and that’s fine. But quite often those “one-time” tasks pop up again and again and I discover to my chagrin that they’re not so one-time after all. Whenever I find myself doing the same manual thing that I’ve already done twice before, I’ll try to find a way to automate it or at least put it on my hit list of things that need to be automated.
It’s important to recognize these scripting candidates early, before they become invisible. Most of us are creatures of habit and if we do something often enough, even if it’s inefficient and dumb, it becomes invisible and “just the way it is.” It takes real discipline (or a fresh set of eyes) to catch these sorts of things and realize that there’s a better way.
I’ve already written about one example of this sort of thing in regard to setting up and configuring new installations of Windows. That’s something I don’t do often so it never seemed like something that was worth automating, but at some point I realized that my list of configurations and customizations had gotten so long that I’d starting writing them down in a manual “script” so I wouldn’t overlook any of them or forget how to do them. Um, yeah, time to automate some of this nonsense.
At Blade I’ve run into several manual processes that had become “just the way it is” to the team. For example, we sometimes want to point the game client to different server environments depending on what we’re working on. The process of redirecting the client to a different server involved loading the project in Visual Studio, editing multiple URLs in the settings files, building the project, and running it. Oh, and you had to repeat this for three different projects in order to get everything redirected. And of course the settings files were checked in to source control so people had to remember not to commit the edited versions with their next changelist.
Fixing this one wasn’t completely trivial. I spent a few hours figuring out how the Jumala settings system worked and how .Net configuration files worked (hint: the file attribute of the appSettings element is your friend). It was difficult to make the choice to invest that kind of time when I had so much real work piling up. But at the end I had a Powershell script that I could invoke with the same of an environment and it would redirect all components without modifying any files under source control. I added the script to source control so the whole team could use it. The savings we get from that script is only a minute or so every time anyone uses it but it’s already paid for itself and it’ll continue to save minutes forever.
Resist Stockholm Syndrome
It’s important keep your eyes open and to think critically about your processes at all times. If you don’t, you’ll eventually succumb to Stockholm Syndrome and begin to accept or even even defend the very things that are holding your productivity hostage. It’s certainly true that you can’t always fix everything all at once and sometimes you have to pick your battles. But what I’m really talking about here is developing a spirit of continuous improvement, looking for ways to eliminate waste, and investing for the future as well as for today. What’s holding back your productivity? What manual, tedious, error-prone work can you eliminate with a bit of scripting? Fix it – you’ll be glad you did.
SaintGimp 
Niice blog you have