I write code, too

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.

Before:

real    1m24.276s 
user    0m49.620s 
sys     0m8.320s

And after:

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][Add][Edit]

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.

For that to happen, tools cannot be an after thought. One of the rocking things about 1.27 and the TOE feature set is that this was really my first major feature set developed from the ground up with a real strategy. Tools were a part of my consideration from the outset. It was painful implementing them in the end just because I’m not a great web/javascript programmer, and I have no experience with pre-existing libraries or applets I could have used to build what was needed.

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.

31 Comments

In the business world it’s reporting instead of tools.

It’s the last thing thought about in the design, first thing dropped in the project to meet deadlines, and the first thing demanded by the users after go live so they can see what is happening and why.

Reporting is the suck.

Everywhere I’ve worked its the same, we don’t have time for no stinkin’ tools. Then on cue all the manual crap people are doing instead soaks up way more time than developing the tools who have taken.

I agree. And I guess I’m odd in that I enjoy making tools. Unfortunately the powers seldom are interested in budgeting for them.

I got an engine in Alpha right now, sans tools and they keep nickle and diming me for small content changes. I try to offer to teach them how to do those themselves but they seem to have that “I’m an idiot and wouldn’t know how to do that” block. The ironic thing is, the content is completely greek to me and without being told EXACTLY what to change, I am useless.

I want to take it to the next level, too, and do WYSWIG stuff and script generators, not just for internal use, but for end user administrators. But there’s no way they’re going to let me.

When I ran the show, tho, the rule was, if you put it in an INI file (or later, the registry), you must also have a user interface for it.

In the company you keep doing these sort of things, it’s usually the case that you’re the smartest guy in the room only as long as you’re using your definition of smart.

Once it switches over to someone else’s definition, you’re not quite the genius you thought you were :)

The 1st phrase I used up top is important, of course. In most life situations, we’re surrounded by fricking morons.

After years of interacting with them, I’ve grown used to the idea that coders are all idiot savants. I don’t treat them that way (you know, I hide my pity and stuff), I just expect it. I find it helps to grok what’s going on.

;P

…@/

KFS1, a brilliant and so very accurate posting. Definitely in the top 5 posts you’ve done.

Snail wrote:
After years of interacting with them, I’ve grown used to the idea that coders are all idiot savants. I don’t treat them that way (you know, I hide my pity and stuff), I just expect it. I find it helps to grok what’s going on.

And that would be a good case-in-point demonstration of the shoe on the other foot, a former Rat too, who treats coders with suspicion and the assumption of idiocy. Caused by the case I was highlighting, and the same doubt that still nurtures fear of “the code” and “the tools” amongst CRS producers today, with the exception of Bloo, who left and worked at GearBox and TargetWare and saw good tools and well-placed developers working on what they’re well suited to working on, and the possibilities that presents.

The programmers CRS hired weren’t neccessarily idiots, its much simpler than that: the majority of them weren’t qualified for the tasks they were given and the others then frustrated at being treated at the same level as someone less than half as skilled at the same task.

“Idiot savants” is a failure to correctly diagnose “no good at my job, good at their own job”.

robusticus wrote:
I try to offer to teach them how to do those themselves but they seem to have that “I’m an idiot and wouldn’t know how to do that” block. The ironic thing is, the content is completely greek to me and without being told EXACTLY what to change, I am useless.

Hmm – I’ve had experiences like that in the past and in hindsight I’ve found it to be the manifestation of an emergent communication gap, some part of the process that the user-perspective has formed a clear interpretation and understanding of different from my own; or they’ve managed to incorporate everything up to a certain level and you’re pushing a button that’s on a different floor.

Eventually I came to find that as a signal for it to be time to sit down and have a user train me to use the system without me saying a word, absolutely not giving them any help.

It really comes back to the core of my point – users don’t want to see inside the tools they use, its not helpful to the work they need to do with the tool. They’re going to see your app in whatever light makes it most meaningful to their tasks, and especially when you have a team of people using it, their peer interactions are going to reinforce that world-view on your app.

Within our code, we use the term “CP” everywhere to describe the entity which contains multiple facilities, in practical terms, a City. That didn’t survive first contact with the players, who use CP to mean Capture Point.

I’ve made the mistake of trying to tell players “No, CP means city” but in the end my common sense woke up and I try to avoid using the term CP in our forums/game and tru to use “City” and “Facility” instead.

I wrote that way to make a point. Not to signify my own feelings on the issues :)

…@/

Within our code, we use the term “CP” everywhere to describe the entity which contains multiple facilities, in practical terms, a City. That didn’t survive first contact with the players, who use CP to mean Capture Point.

I’ve made the mistake of trying to tell players “No, CP means city” but in the end my common sense woke up and I try to avoid using the term CP in our forums/game and tru to use “City” and “Facility” instead.

I feel that pain. I get so much flak for putting the official, correct version on the wiki.

Btw:

MY main beef with coders and code in general is the sheer unreliability of estimates when you’re doing cutting edge stuff.

I don’t blame anyone for it, it’s the nature of the beast. But it’s hell to try to manage. *Especially* if you’re not a coder yourself. Which leads to the other point, which is that a coder who’s actively engaged in that job and who can also manage at the same time is, like….damned hard to find.

Which leads back to the “idiot savant” rep, which leads back to the sort of realms in which coders tend to excel and the ones they don’t, which would include not recognising that whole bit about not always being the smartest person in the room. Which leads back to your point about toolmakers.

Whereas, for instance, someone who is skilled at managing will have a very good grasp of the smartest person in the room being, ya know…relative :)

What skill I have for working with code and the writing of it, I had to work very hard for. I don’t think in the same terms. Managing people and personalities, I had a successful 20 year career to fall back on, one I was talented at…it comes alot more naturally to me.

Since I’m not really all that interested in doing things that don’t involve cutting edge stuff…you see my conflict.

…@/

How does your terrain editor work? I’ve read about the horror stories that DOC had in the early development stages where he was working on terrain like 20 hours a day for a couple weeks because it was so hard to use.

It seems to me it would have to have some type of database that stored all of the geography of the land, and then you would design a building and “drop” it multiple places on the map. Then if you changed something about the “master” building, all of the others would automatically update? Like object oriented?

Just curious man, the game operates on such a large scale that it’s interesting to know what is under the hood!

Agreed again. Though, there is some level between the end user and knowing how to implement a bridge facade pattern. This I think in games is known as a designer. So tools for that level to shape the tools the end user uses.

Different from producers? I won’t tell you what the equivalent to them is in my world but a bunch of us coders invited one to play a deathmatch game once and well, I doubt he ever has since. I even used only the knife, versus y’know, the usual array of everything up to tactical nukes. Actully, nevermind, the map we played did have a nuclear device. “No, really, you’ll get better at it, just keep trying…”

And… my theory is, you have to make the tools fun for it to work. Even if you’re making tax software. Instant gratification helps too. Optimization is a fun game to play, but very challenging.

Ah, it’s Friday, my bug count is 0, and there are big puffy clouds, blue sky and a beer. Good times.

Understood Snail, you just spoke what it wouldn’t be fair for me to put in the mouth of others but whom I believe feel that way towards coders :)

The terrain editor is based on DEM data and text files representing small areas of land. It uses Visual SourceSafe – via a command line tool – to grab the neccessary files for the area you are working on from source safe, and later to check them in. Moving into a new area can take several minutes and due to idiosyncrasies it can get itself deadlocked and crash leaving the terrain in an unpredictable state.

I keep trying to persuade the guys to let us do it with a new kind of STO that we give a persistent, DATABASE back end and an application that can pull the data down into the format the client understands for building patches.

But that touches on a very, very, deep, very infected scar for them :(

Yep – making tools fun is always a good thing; I wish I could find the link, but I read recently how someone got bored one day and decided to give his application a friendly little custom icon. That was the only change he made, but he noticed a significant increase in the amount of time the team the app was for left the app running. I want to say 75% but it could have been 35% – wish I could find the link.

I’m fairly sure that if I invested any amount of time in the presentation of WireTap its growth rate would increase.

Given the strong positive correlation between patches with new toys/eye candy and subscription inceptions/retentions, I wonder where the game would be today if it’d been done from the beginning with faster, easier modeling and terrain building, and it’d been possible to do a patch a month with toys/eye candy whether or not there was mechanics/code patch content ready for that patch cycle?

I understand the comfort of a low-effectiveness but survivable operating procedure when there have been scary experiences with nearly non-survivable situations, but I’d think someone at a senior management level would want to look beyond that comfort zone and be encouraging development of a plan to break out to something more effective.

Another instance of CRS-speak from the early days that causes player confusion: “vehicle” = any live game object, including infantry, planes and naval vessels.

“I’m fairly sure that if I invested any amount of time in the presentation of WireTap its growth rate would increase.”

It will grow, here a little preview of something that will come:

I hope I can start on monday with my open beta, but the time gets very tight.

Greetings,
Drave

I imagine the obstacle is more involved with manhours and the competing priorities for same now and projected outwards than any atavistic fear of new-toolness :)

…@/

Atavisticus!

Yeah, that’s how we do it – with SQL Server 2005. Ca-chunk the XML (about 120K very lightweight for me). I do the VSS stuff manually and the DB also has a very efficient, basic versioning system in place, that I don’t have to mess with.

One of the main foci at Austin GDC this year was creating tools for tracking/reporting but also for usability testing, ‘is it fun?’ testing. There was some really excellent stuff that has turned me on to even more stuff we should be doing, and it really validated all the things I use to say when I was here the first time about things we needed to do, but got shot down (and it was nice to see some of those ‘shooters’ come around, too). A wonderful week of “I told you so!” :) But also, “Thor’s balls, that’s an awesome idea we should implement tomorrow!” and “Finally! Someone has figured out how to do this thing I’ve always felt needed doing but that I didn’t have the tools or background to get my hands around the deal.”

Interestingly, some of the advice on tracking and reporting and hooks for that stuff, etc., was contradictory between different speakers, so you will have to do your own analysis, but hearing from them helps you to analyze these things better.

Now I just need to learn me the skills necessary to do all the stuff I want in the spare hours I don’t have.

I’ve often wondered how “is it fun?” would be tested in a marketing context where the product is (intentionally, beneficially) inclusive of multiple gameplay concepts and attractive to multiple player types, some of whom consider the participation of other types to be antithetical to their own fun-receipt.

The time I’ve done coding has run into much of the same challenges… But I think coders in general don’t have the ability to rationalize their ideas well to management.

I’ve watched colleagues go to the Boss and say “we need a tool for this!” and have the boss shoot them down. I’d spend a few days putting together some figures and boiling it down to a bottom line, and telling the manager “If we made that tool, we’d recoup our costs in 2 months; nothing but profits afterwards.”

My tool-generating requests seem to always get approved for some reason, and my colleagues are just labelled “whiners.”

I know a weasel. He is a producer.

Your gaantfu may be strong, but doubling a schedule is a tough sell for something you may or may not even want. Oh, and software estimation is a 5th year ding for a software engineer. By the 10th year all such things become irrelevant for the most part.

It isn’t about priorities or cost, it is about how quickly can I can get the bare minimum to you and capitalize on an opportunity.

Drave wrote:
“I’m fairly sure that if I invested any amount of time in the presentation of WireTap its growth rate would increase.”

It will grow, here a little preview of something that will come:

I hope I can start on monday with my open beta, but the time gets very tight.

Greetings,
Drave

The spam filter ate this for a long time, so I thought I’d re-paste it :)

Did someone mention typos in depot names ;)

Maastricht-Esloo Bridge (Elsloo)
Oplade-Koln Depot (Köln)
Oplade-Koln Depot (Köln)
Kaarst-Düusseldorf FB (Düsseldorf)
Dormagen-Dusseldorf Depot (Düsseldorf)
Neuss-Dusseldorf Depot (Düsseldorf)
Bergeim-Kerpen FB (Bergheim)
Brühl-Koln Depot (Köln)
Kaarst-Dusseldorf Depot (Düsseldorf)
Bergheim-Koln Depot (Köln)
Hüurtgenwald-Duren FB (Hürtgenwald)
Schleiden-Netterheim Depot (Nettersheim)
Erkelenz-Mochen.Gladbach Depot (Monchen.Gladbach)
Duren-Aarchen FB (Aachen)
Roermond West-Maasiek Depot (Maaseik)
Wiltz-Bastonge Depot (Bastogne)
Luxembourg-Grevenmach Depot (Grevenmacher)
Roermond West-Maasiek FB (Maaseik)
Waalwijk-Oosthout Depot (Oosterhout)
Oostehout-Breda Depot (Oosterhout)
Oostehout-Waalwijk Depot (Oosterhout)
Jodoinge City (Jodoigne)
Givet-Phillipville Depot (Philipville)
Givet-Vireux Depot (Vireaux)
Bearaing-Wellin FB (Beauraing)
Wuuztwezel City (Wuustwezel)
Givet-Phillipville FB (Philipville)
Flavion-Phillipville FB (Philipville)
Philipville-Metttet FB (Mettet)
Mettet-Phillipville Depot (Philipville)
Sechault-Someppy Depot (Sommepy)
Walcourt-Phillipville Depot (Philipville)
Somzee-Phillipville Depot (Philipville)
Mariemburg-Phillipville Depot (Philipville)
Krabeendijke-Walsoorden Depot (Krabbendijke)
Aalst-Ninoven Depot (Ninove)
Ternmeuzen-Antwerp Port (Terneuzen)
Terneusen City (Terneuzen)
Brakel-Gerrardsbergen Depot (Gerardsbergen)
Ath-Gerrardsbergen Depot (Gerardsbergen)
Ath-Gerrardsbergen FB (Gerardsbergen)
Ijzendijke-Ternuezen Depot (Terneuzen)
Gent-Oudenaard Depot (Oudenaarde)
Gent-Zottengem Depot (Zottegem)
Oudenaarde-Dienze Depot (Deinze)
Aalter-Tielt Firebase (FB)
Armentieres-LaBassee Depot (La Bassee)
Maningham-Hesdin FB (Maninghem)
Boulogne-LeTouquet Depot (Le Touqet)
Whistable-Margate FB (Whitstable)
Whistable-Canterbury Depot (Whitstable)
Whistable West Armybase (Whitstable)
Saaburg-Trier FB (Saarburg)
Breda-Moedijk FB (Moerdijk)
Oosterhout-Moedijk FB (Moerdijk)
Veere-Vlissingen Depot
Bavay-Maubeauge Depot (Maubeuge)
Niederkassel-Koln Depot (Köln)
Köln-Neiderkassel Depot (Niederkassel)
Neiderkassel-Meckenheim FB (Niederkassel)
Vohwinkel-Dusseldorf Depot (Düsseldorf)
Lohmar-Nierderkassel FB (Niederkassel)
Lohmar-Koln FB (Köln)
Overath-Koln FB (Köln)
Vohwinkel-Dusseldorf FB (Düsseldorf)
Chauny-LaFere FB (La Fere)
Essertaux-Pois-de-Picardie Depot (Poix-de-Picardie)
Poix-de-Picardie North Amrybase (Armybase)
Fressenneville-Abbevile FB (Abbeville)
Gamanches-Oisemont Depot (Gamaches)
Wittlich-Berkastel-Kues Depot (Bernkastel-Kues)
Monfaucon-Clermont-en-Argonne Depot (Montfaucon)
Griendsvenn-Venray Depot (Griendtsveen)
Griendsveen-Rips Depot (Griendtsveen)
Venray-Griendsveen Depot (Griendtsveen)
Rips-Griendsveen Depot (Griendtsveen)
Frenes-Etain Depot (Fresnes)

Hey Drave, your app looks interesting, and I see it’s in Java. I came at it from a different angle. You can try it out here:

http://www.pentatronic.com/wwiiol/wwiiol.jnlp

Damn, SLR. That is one sweet app. Very polished, I like it. Great stuff.

Thanks, hope you find it useful. I’ve still got a fairly long todo list but it’s coming together and it would be interesting to share some ideas with the other people writing apps and web pages.

I just fixed a bug related to very recent captures so you’ll probably get an automatic update next time you run it.

Trackbacks and Pingbacks

[…] is, as I implied in my confession of sin, we programmers don’t tend to use our code, we maybe just test it a bit (but I won’t […]

Leave a Reply

Name and email address are required. Your email address will not be published.

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

You may use these HTML tags and attributes:

<a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <pre> <q cite=""> <s> <strike> <strong> 

%d bloggers like this: