Building an Application: Part 1, Setup and Background

#Application Development , #Scoped Application , #GitHub , #Helsinki Release , #GTD

Dave Slusher

4 minute read

david_allen.jpg

I have been working on a skunkworks project with ctomasi, josh.nerius and a few other people for months now as a low level background task. One of the downsides in working in an evangelism role is that sometimes you do lots of things to communicate about developing without actually doing any development yourself. In order to change that, we carved out a problem space that all of us were interested in, had an opportunity to improve toolsets and would be something that we ourselves would want to use every day.

We opted to use the ServiceNow platform to build an application for the GTD organization method from the mind of the brilliant David Allen. All of us on the project use some implementation of it and none of us love our current tools. This seemed like a rich space to mine for the opportunity to bring us onto a tool we all liked better than our current. I personally was using an Evernote based solution, but OmniFocus and other tools were in play. In fact, no two of us used the same thing.

The first thing we did was work out a list of use cases for the application. The upside to implementing GTD is that much of the design is already done. There is no discussion about the priorities, for example, or that there is a review phase. It just comes down to the implementation details. All of us threw in use cases important to us to make this a tool capable of being a daily driver. These included:

  • Ability to filter down lists to specific contexts
  • Quick entry of new tasks (Ubiquitous capture in GTD terminology)
  • Convert emails into tasks
  • Ability to delegate and track tasks
  • Notifications around changes done by others, upcoming due dates
  • A template system for creating recurring tasks

A List of actions

There were many others, this is just an example to give a taste of the types of features that were on our minds. Given that set of use cases, Chuck went off and created an initial cut of the data model and a framework for the basic operation of the system. Because of the timing of the project, we were able to begin on the Helsinki release. This made Service Portal available as an option for some of the user interface, and gave us the ability to use a GitHub account as the backbone for our changes. We set up instances for our dev and production, and then each of us connected our personal GitHub accounts to our own development instances. One note of caution, we learned the hard way that when you update from source control, it has the potential to scramble data since it uninstalls and reinstalls. Because of this, we pull to our development/test instance from source control and then promote to production via update sets.

All this is background to get us to the subsequent posts, where I will talk about some of the programming challenges we ran into and how we addressed them. Our goal is to make this available to the world eventually. Although we are close, we are not quite at the point where we consider what we have as a releasable V1 product. I will post an update when we make that available. At some point in every post like this, people will ask for a pointer to the GitHub repo. For the same reasons it is not quite releasable yet, I’m going to hold off on publicizing that repository at this moment. However, it isn’t private and there are tools on the internet for the really motivated if you know what I mean.

Progress on this application moves in fits and starts because it is no one’s top priority (or even top 5) but sometimes we devote some time to it anyway, frequently over evenings and weekends. I hope that people find value in following along with our progress and our thought patterns. The very first time we did the Live Coding Happy Hour was for this project, in fact. It was a reaction to the slick demos we frequently work out. We wanted to do the opposite because we felt there was also value in showing the struggle, the problems you can bump into and how to work your way out of those. This blog series is from a similar mind set, walking along with how we pursue the project. With any luck, you will take something away that you can use in your own application development work.

As always, feel free to leave any comments on this post. This series is for y’all so please let me know what you do and don’t find valuable so I can dial it in as I proceed. Next post: how to deal with incoming email (aka, getting to the fun stuff!)

Series so far:

Comments