A lot of my work at CRS has been developing tools, although I’ve rarely been officially tasked with doing so. Sometimes, it seems like I’m a tool developer who writes code too.
What’s the difference? Tools are just code too, right?
Silly little ‘tooling’ factoid:
In 2002, I was shown how terrain updates were loaded onto the server. The process was long and complex. I’ll come back to that. It took aproximately 18-24 minutes to upload a terrain, and there were some serious omissions in the data. The whole process took upto an hour.
Most importantly, any object that was changed – say a building the terrain editors moved a few feet, rotated or correct a typo in the name of a depot – it got new IDs that would have rendered something like a capture history defective.
In 2007, all of the manual steps in preparing the terrain have been scripted and it takes between 1 to 5 minutes, including a manual review of logs, to package and prepare the terrain.
I’d already massively improved the import utility, but I got the coding urge last night to make some “I understand this much better now” tweaks, maybe 15 minutes in total. Largely about eliminating some “can cause problem” redundancies and fixing a problem in our QA process that allowed something bad to happen in 1.27.
Naturally, I wanted to make sure I hadn’t suddenly worsened it so I timed the two versions of the import utility.
real 1m24.276s user 0m49.620s sys 0m8.320s
real 0m12.129s user 0m8.398s sys 0m0.195s
As best I can tell, 5% of that time is writing status updates to the console, and another 10% is writing log messages.
There is a catch. The old version is compiled with -O2, the new version wasn’t compiled with optimization…
real 0m8.355s user 0m6.218s sys 0m0.114s
It’s easy for me to become complacent about my ability to develop tools. As the server guy, I’m the only person that uses this tool and its gone from “does its job painfully” to “does its job excellently” and I’ve never had any real problems using it…
Today’s map reset should have taken a handful of minutes, but old habbits die hard and the memory that you could only manage the game while the servers were down hasn’t entirely been erased.
When I first started here, there was a palpable fear – outright terror – at the thought of tools and automation. I’m not a tools developer and many of the tools I’ve developed I’ve developed primarily for my own use. There are a few that I’ve really polished up to be “idiot proof”, and those are the ones that have most benefited our development pipelines. Some of the others occasionally bite us in the butt – such as today when the brigade deployment tool transpired to be still limiting Allied brigades to CPs owned by specific countrys.
Unfortunately, some of the remaining toolaphobia lingers because people are so badly burned by tools that they have very short patience and tolerance for tools, and so they want nothing to do with their development.
Too many programmers develop against their users. Take the term “idiot proofing”. Your users are not idiots. If they make dumb mistakes with your application, I would put good money on which of you the idiot is and we would not be better friends for my coming away richer.
The whole point of a tool should be to obviate the need for a user to have any understanding of what is involved from getting from A to B. If you think the user is an idiot for not understanding the application, you’re an idiot for not understanding the usage of your own work.
Reality is that tool development is its own discipline, and too few programmers realize that. Sure, we can cobble up something that shines some light on a dark corner of our product or provides access to the wiring of some otherwise unmanageable component. But to be a good tool developer is to understand usage: tools do not exist to allow a user anything, tools exist to make something usable. A tool that merely exposes is just an interface, real tools enable, real tools are utilities.
Sure, you can pound the dents out of your car with a mallet if you know what you are doing; but if you only own a car to get you to and from work, why should you have to become a metalworker and mechanic?
Part of CRS’s deep rooted fear of tools comes from the early days when poorly developed tools demanded the knowledge of their programmer to operate correctly. If, say, using the tool was a minimal part of your job – to let you do something it might otherwise take a programmer to do – it could quite likely cause destruction and catastrophy quietly and happily, trusting that you knew all the ramifications of every action and option.
We, as programmers, often fall on the axiom that “the compiler will tell me” – things like uninitialized variables or when we mix up types. But when we’re putting together a tool, we don’t grant the user the same courtesy? We really don’t have social skills, do we?
I was helping a friend from the UK diagnose a problem he had with a website. I was setting up some data and got distracted. When I looked back at the page a few minutes later, I glanced at the status bar. In, and only in, the single context I happened to have been interrupted at, his site used the status bar. It said “Note: This will remove all existing values”.
In the context, that wasn’t the least alarming, I was clicking a button I thought would create a new record – so having all fields erased would make sense.
No, this “Note” was actually telling me that when I clicked “OK” the entire database would be erased. On a data entry page, he had 5 input boxes and three boxes:
New :- Nuke the database entirely and start over.
Add :- Add an empty entry, ignoring what I’ve typed.
Edit :- Look up the entry I’ve entered fields for and let me edit that.
On other pages
New :- Add an empty entry, ignoring what I’ve typed.
Add :- Add the entry I’ve typed and bring up the edit page to let me furnish the rest of the details.
Edit :- Look up the entry and edit it.
I didn’t pounce on him, instead I got him to walk me through something – we added a couple of other entries first, and then came back to the problem page, and he instinctively clicked New, typed in his new record, clicked OK to return to the record list and bam – database gone, just like his “idiot” users had been seeing.
To his credit, the girls who had been suffering at the hand of this “little oversight” were graceful in accepting his apologies ;)
When I started at CRS, there was some friction around my expending development time on tools. CRS were in Chapter 11 and these two sentences were pretty much Jack and Jill: “The last thing anyone has time for is developing tools”, “Every tool in this place is BROKEN”.
Good tools, usable tools, user-usable tools, applications that have specific utilitarian functions rather than having a swiss-army knife of potentially dangerous uses, are the ultimate value to a development team. CRS would have had more time for development – of all types, period – if they had developed the tools to facilitate it.
But it really came together because TOE tools were a part of the deliverable, down to the paratroop brigades and air/naval support forces. If we had taken the approach of the early days and built TOEs first and worried about managing them and operating them later, I doubt those features would have fallen out of the development process as automatically and freely as they did.
Before you go assuming that CRS’s entire toolset is a steaming pile of manure, that’s not the case, its a matter of extremes: most of our production and art team have had their life-long outlook on programmer’s tools irrevocably tarnished by a couple of exceptionally abominable apps – most predominantly the terrain editor. There really aren’t any polite words to describe just how truly, truly awful it is. Its a miracle that anyone who has ever used it can bear to be in the same room as a microchip.
Design for instrumentation and tooling from the outset. Design for vacuum-usability by individuals with no interest in the elegance of what they are using, only its usability and while you should make every nuance and facet exposable and accessible, don’t put it where an uninterested user can confuse it for something they are supposed to use.