4 minutes reading time (742 words)

When is something done?

When is something done?

March 29, 2016

By George Demmy

The version 6.8.5 release of TerraGo Publisher, Composer, and Toolbar begged the question: when is something done? This is, of course, a topic that has been explored in sundry blog posts and those LinkedIn articles titled something like 9 Ways To Know Your Stuff Ain’t Done, but it is something that can be subtle and highly contextual.

Two states that are pretty easily recognized are clearly not done and clearly over-done. Scattered Legos and Skylanders and things which belong in a hamper mark a room whose cleaning is not done, and no amount of protesting that it’s mostly done changes the state. Billowing smoke and stabs of flame from the frying pan marks eggs that are over-done. With software, done depends on context, though I will say pretty unconditionally that if it’s not ready to go into the installer or be deployed to a service, e.g., everything needed to clear QA complete and where it needs to be, then that’s most definitely not done.

The purpose of almost any software company I can think of is to deliver value to its customers through software products and related services. If the definition of done were something to the effect of “the penultimate expression of every feature and function that a customer might reasonably profit from”, no software product would ever ship except, perhaps, the Unix echo utility. So, recursively applying the purpose of a software company to a definition of done that are mutually compatible, we come up with something like a minimum viable definition of done, or shippably done, wherein if the feature and function can deliver net value that cannot be realized today, then it’s probably shippably done. Although this seems straightforward enough, there is some subtlety in the definition.

A shippably done feature has to deliver net value – it’s got to cost less in time/money/heartache/effort to learn and implement than it delivers in value. Early adopters and people with more cutting edge requirements are willing to accept a narrower net difference between cost and value than more casual or conservative users, so there is an added dimension to this. At TerraGo, one of the things we’ve always have prioritized is our early adopters and people who push the envelope. And to the dismay of our QA team at times, we let stuff out the door that lets people do things they cannot today, if they’re willing to put a little elbow grease into it, or put up with what I might characterize as idiosyncrasies. But at the same time, we do not cater exclusively to early adopters, so just because something ships means we can drop it and move onto the next cool thing – we need to work to make the gap between value delivered and cost wider by reducing the feature work better, more clearly, more completely, more robustly, etc.

We shipped our GeoPackage feature attributes, which is a combination of a creation component in Publisher and a consumption component in Toolbar, as soon as it demonstrably worked and could deliver value that could not be delivered today. It was the first time that anyone could create a dataset and contextualized it with a map at the push of a button in ArcMap. Similarly, we shipped our PubPy bindings which allowed programmatic creation of GeoPDF documents from ArcPy applications very soon after we implemented the capability. While that initial delivery of net value was done, the features were far from comprehensive, efficient, or complete. The 6.8.5 release addresses the latter part of the issue. Whereas, it was possible to generate GeoPDF documents with GeoPackage feature attributes in previous versions, it was slow. It is significantly faster in 6.8.5, and we’ve created GeoPDF documents with one million embedded features as part of our testing – something that is simply impossible with PDF object data, and would be inaccessible even if it were possible. While you could create GeoPDF documents from ArcPy applications with PubPy, now you can frob the layer configuration from PubPy as well. Are these features done? Well, not completely, but they subject to a process of continuous refinement until such a time that the effort to improve them will not yield commensurate increases in net value to our customers. The done we focus on is that of incremental net value, and when we can deliver that increment, it’s shippably done, we ship it, and begin the next iteration.