Given that we're now in the hot days of July (not really - thanks polar vortices!), I figured a blog post looking at the last six months may be useful to see where things have gone and where things are headed.
January 1 began with me back in Chicago after a Christmas vacation to Northeastern New Mexico to visit family. I was in the middle of two crowdfunding campaigns to raise funds to take The Pnakotic Atlas and Fresh Comics to some pop culture conventions in 2014. At the office, I was semi-supervising one employee and gearing up to hire another. The big IC project (pseudonym, see below) I was managing technically was just about to hit its stride, and I was preparing for the sprint to the summer. At home, I was playing a ton of Unreal Tournament 3's Warfare mode, having discovered it while practicing my deathmatch skills after some thorough thrashings from Willie.
June 30 ended with me in maintenance mode on The Pnakotic Atlas and Fresh Comics. The C2E2 convention went well for the Atlas, but some May shenanigans from Google put a halt to my year-long project to pitch the app to convention runners. At the end of June, I was wrapping my head around restarting my Shion automation platform. At the office, months of a self-imposed caffeine-fueled deathmarch had produced the majority of the IC mini-apps, and my two employees had taken a solid share of the burden, producing apps of their own. My UT3 interest had faded a bit - having largely mastered all the Warfare maps - and I resumed playing an older reliable time sink: Halo Wars.
Let's go through these items in more detail.
Personal Projects: Fresh Comics, The Pnakotic Atlas & More
The major theme of 1H-2014 for both of these apps was getting the word out and doing what I could to boost downloads. To that end, I set up two crowdfunding campaigns to raise funds to pay for a booth at three local conventions. Due to a lack of experience and salesmanship on my part, I didn't hit the goals for either of the campaigns, but elected to take the apps on to the shows anyway. The original idea was to exhibit at a new show called Chi-Fi in March, C2E2 in April, and the Chicago Comic Con in August. Chi-Fi melted down and did not end up happening. I took the apps to C2E2 and pitched them to convention goers. Plans to attend the August Chicago Comic Con have been shelved until I get a better handle on some other issues related to Fresh Comics.
C2E2 was an excellent convention for The Pnakotic Atlas and a poor one for Fresh Comics. First of all, I found it extremely difficult to pitch two largely orthogonal apps from the same booth. Given that I had prepared some swag to give away and sell for The Pnakotic Atlas (4 wonderful woodblock prints from Greg "Rain" Rebis and a 16 postcard set from artwork in the app) the visual message communicated was 95% Lovecraft. This was great for that app - we sold and gave away a lot of postcards and sold through all of the expensive items. Unfortunately, Fresh Comics wasn't such an easy sell, because of its minimal booth presence and the changing convention demographics.
My main goal for Fresh Comics was to get it in front of convention runners, and pitch it to them as an app that they could pay me to configure for their shows and spend an order of magnitude less on a convention app than they would otherwise. When I exhibited the app in 2012, the bulk of my conversations were with convention runners who wanted exactly that. In 2014, I was unable to speak to a single convention runner and this part of the show's mission failed completely. I had pretty good placement right by the entrance to the show floor so either the Atlas portions of the booth drowned out the Fresh Comics message or those folks didn't come to the show. I suspect that it was probably a mixture of the two.
Since C2E2, I've been working on marketing The Pnakotic Atlas more and to start branching out into other methods of outreach, including selling the surplus postcards from C2E2 and putting together some plans for the overall project as a whole. As currently constituted, The Pnakotic Atlas is a mobile map to places in Lovecraft's fiction. Given that I'm past the 25% mark in terms of illustrations (100+), I'm contemplating pivoting the project slightly and making it more of general illustration project for the Lovecraft fiction. Given that the texts are public domain (until someone steps up and proves otherwise), there may be an opportunity to produce some illustrated electronic editions of HPL's work. I haven't made any decisions and probably won't take any concrete steps one way or the other until later in July.
Fresh Comics received a kidney punch in May from Google when the Mountain View company decided that I was infringing upon others' IP in Fresh Comics and suspended the app from the Google Play Store. Given that they refuse to identify which IP I'm allegedly pirating, responding to their charges and getting the app back up on the Play Store has sucked up the majority of my Fresh Comics energy for the past couple of months. I've sent along marketing communications that I receive from several companies' press lists that explicitly state that I'm allowed to post covers and images, but that hasn't cleared whatever invisible bar they need for me to clear in order to reinstate the app. I've been working with folks within the company to get a human being to talk to, but those efforts have yielded no fruit and as soon as I have some spare bandwidth, it looks like I'll be removing that app from the Play store and making it an Amazon App Store exclusive. This hurts my prospects on the Android platform because interested users will have to download another app (Amazon's digital store) and create another set of user credentials before they can install Fresh Comics, and I expect that alone will effectively eliminate Android as a viable platform for my earlier plans.
Since the app's suspension, I've been debating whether to keep on as I've been doing, try and sell the app, shutter the effort altogether, or pivot Fresh Comics into something else. For the past several months, the user downloads have been underwhelming, and a clear assessment of the project indicates that the value in the project itself is not in the apps alone, but rather the infrastructure that supports the apps. In particular, freshcomics.us has achieved decent search engine rankings for various local queries. Furthermore, now may be a great time to ask the question of whether the original problems solved by the app are still relevant (offline access to comic release information) and whether a responsive website can serve those needs as well or better than the current crop of apps. I have a lot of thinking ahead of me in the weeks ahead.
(Update, July 8: Less than 24 hours after I published this, an appeal I'd made earlier in the morning [before writing this post] was accepted by Google and Fresh Comics is back up on the app store. My original plans are now back on track, if a bit delayed. I have zero reason to think that this post had any impact, but I did want to provide an updated picture to readers of the paragraphs above…)
In addition to Fresh Comics and The Pnakotic Atlas, I've designated 2014 as the year I put Shion back on its rails and continue developing my environmental automation system. 2013's release of Mavericks (the latest Mac OS X) introduced some changes that broke the desktop-mobile integration between Shion and Shion Touch and I haven't gotten around to addressing that issue. I've been holding back as I make some big picture decisions about the direction of the project as a whole. When I started it 5+ years ago, it was purely a Mac & iPhone project. The entire thing is programmed in Objective-C and those implementation decisions have limited my ability to move it to other platforms.
The plan moving forward (as of this weekend) is to rewrite the system, using the existing Objective-C codebase as a reference implementation. Since cross-platform availability is a priority, the new system will be largely written in Java. The choice of Java is driven by a need to have strong concurrency baked into the base system that is predictable between platforms. Objective-C has some nice concurrency baked into recent framework releases (Grand Central Dispatch), but those are Mac-only, and I want to target Windows and Linux as platforms that can talk to the home automation hardware. Consequently, the overall architecture will start to resemble more of a client-server arrangement. A Java server will manage communication with the devices, while native user-facing interfaces will provide the look-and-feel. Assuming no major interruptions, I'm looking to break ground on the new version this week.
In May, at the height of my Google frustration, I began another project I'm calling (in my head) Aetherial.Net. It began as an effort to renovate my long-overdue personal site and I've used the project as an opportunity to scratch some other itches and begin to build out an always-on personal assistant to help me manage all of the balls that I have up in the air. I won't go into details here - see the rest of the blog - but overall, this has been a big success. Tools and features I've implemented have already made my life easier and more effective. Practicing the advice I gave graduating Des Moines seniors earlier this year (see below), I'm working to make this system 1% better each day.
Work Projects: IC, Purple Robot, MoodText/HealthySMS
At the office, my attention has largely been focused on the IC project (full name redacted in order to not pollute future SEO efforts), which started last September and is testing the viability of combining a suite of "mini-apps" with a recommender system as a method of suggesting helpful treatments to people with depression and anxiety. My overall focus has been to procure or produce 13 self-contained apps that can be fed into a Netflix-style recommender and shared with patients. About this time last summer, we planned to adopt a new development approach: instead of creating each app serially (one after the other), we put together a scheme where one technologist would work with one clinician as a team to produce an app. The pair would work together with minimal outside interference and when the app was at a release stage, it would be presented to the overall team for comments and revisions.
That plan went off the tracks fairly quickly as the internal developers tasked with working with a clinician were pretty quickly pulled off the project to work on higher-priority projects. By December, there were only two of us working on the apps, and the other fellow was splitting his time between his IC app and another high-priority effort. Consequently, it fell on me to shepherd 11 (of 13) apps from concepts to 1.0 versions since the beginning of the year. Later in the spring, we hired another developer to join the team and she's been helpful in creating a new app of her own in addition to taking over the maintenance of three other apps I initially created.
While we encountered a developer shortage early in the project, the latest frustration has been keeping clinicians on apps. Due to the funding nature of the university, only a handful of the original app builder pairs have stayed the same. While swapping out a developer is a fairly straightforward process, switching clinicians has been trickier since decisions made by the prior clinical team are seen as invalid or suboptimal by the new clinicians. This inevitably makes my life miserable because I'm now in a position where I have to take an app that was largely signed-off as complete and ready to go and begin revising and reworking it while still trying to hit an ever shifting deadline for deploying to patients. These changes are acceptable the first couple of times, but by the third or fourth one, it becomes an issue. The major problem that this causes is that it creates a lack of developer investment in subsequent code rounds. If there's a good possibility that the work you're doing now will be thrown away when a new clinician comes aboard - and the odds of that are good - there's little reason for a developer to take personal responsibility for their work if it's going to be thrown away later. The rational approach is to do the minimal amount of work to get to a point where decisions can be made and if the cobbled-together version passes muster, then start working on it to imbue it with quality, attention, and robustness.
This is at odds with how I prefer to build things. The goal that I strive for is to have a work product that I'm proud of as soon as possible, and to get that in front of people as soon as possible with the understanding that there will be issues, things left to build out, and more work ahead in the future. This is very much an open-source "release early, release often" approach that attempts to evolve software from a strongly-designed base instead of a big-design upfront approach. When I started work on this project, I wanted to demonstrate the validity of the early release/quick iteration process, but institutional issues (few stable app teams) coupled with barriers to getting the app out to the general public (clinician insecurity, involving the IRB in what should be solely a QA process) has organically resulted in a worst-of-both-worlds development outcome where I've been responsible for producing high-quality early versions of apps without being able to take advantage of the positive feedback cycles of public involvement in the subsequent app development. I've been trying to keep things on track with a significant amount of outside-the-office effort, and we're in much better shape than we would be if I had stuck to a strict 9-to-5 schedule. Of the 13 apps, 11 have reached (9) or are nearing (2) release quality status, leaving two apps in "no clinician" limbo. I owe good bit of gratitude to my developers for taking on 5 of the 13 apps, and RedBull and Netflix for providing the energy and background distraction needed to make it through the late nights to shepherd the rest to where they are now.
In the next week, I'm looking forward to pushing the two remaining apps to release-quality status. Looking back on the experience over the last nine months, I was unable to test my theory that sufficiently-motivated developers and clinicians working with a minimal of outside interference would be efficient operating in a parallel arrangement than a team of clinicians and developers knocking out apps sequentially in a serial fashion. The test failed through no fault of the approach, but because of an inability to maintain internally organizational consistency. As the team of developers and clinicians fluxuated, the process became de-facto serial as a handful of developers (2 of us) worked with a handful of clinicians to get things done. Furthermore, I failed to hold the line on a QA-only public alpha/beta test of the apps, and this personal failure resulted in the elimination of my testing feedback loop as it became important to collect as much data as possible in the off chance that a paper might be derived from it. I'm not entirely sure what the research question motivating such a paper might be, but once we started collecting non-QA data, then IRBs, consent forms, and other distractions came into play. I think we finally found an acceptable middle ground - a non-public open-invite beta test (that's your invitation) - but I'm far behind where I wanted to be in terms of app revisions out in the wild.
Looking back on the experience, I'm not entirely sure that I would have had the agency to manage the project with an iron fist and execute it as originally conceived. The major issue is that I'm just staff and it's difficult to unilaterally impose those project management decisions upon the principal investigators who are ultimately in charge of the project's success or failure. I took a personal stake and local responsibility for this project as a way to show that my approach is viable, but ultimately it's not my name on the grant. During the remainder of the year, an open question that I need to answer is whether it's possible for a technologist to take (and hold) the decision-making responsibility for a project in a university research setting or if I need to adapt my development processes and expectations or find an alternative position where I can (generally) exercise my experience and passion to a fuller extent than has been possible.
In contrast to IC, my work on Purple Robot has been much less stressful and more rewarding from a personal perspective. To recap, Purple Robot is an Android app that is the intellectual heir to the context-sensing and automation work that I did in graduate school. It's an Android app with a full compliment of sensors combined with trigger engine (conceptually adopted from Shion) combined with JavaScript and Scheme scripting environments that allow the system to automate user interactions. The app itself is probably the most sophisticated thing I've produced and owning to its scope and complexity, I've managed to retain de facto control over the app and its evolution. My design decisions have been validated by numerous deployments in the field both by internal CBITs clients and external folks around the world.
Thus far, the theme for 2014 for Purple Robot has been on improving its robustness and extending its sensing capabilities. I've begun taking advantage of the Scheme engine to explore metaprogramming options and this work has been reinforced by my independent efforts on behalf of the Aetherial.Net work. (The presence heat map is the first of many uses of Purple Robot in my grand cyborg experiment.) Overall, the app's improved significantly in terms of quality and I'm neck-deep in work to improve some of the development processes around the app, including automated builds and the incorporation of an internal unit/functional test harness to verify that things like user interactions and timed events are functioning properly. (Off-the-shelf testing systems are not up to this task.) In later work this summer, I'm looking forward to migrate its data-upload protocol from a purely JSON-based format to a hybrid of JSON and binary representations. The binary representations have become necessary as we look to capture and analyze higher-frequency (10 Hz+) events coming from audio and hardware sensors.
The final work-related time sink for the first half of 2014 has been a project called MoodText and (later on) HealthySMS. Building on the years of experience I've accumulated doing SMS-based data collection, this project has been focused on porting a group-psychology SMS-based intervention from my legacy SMSBot platform to a pure Django platform using Twilio. The original iteration of this project was completed last year using SMSBot configured to use Twilio instead of a native Android device to send and receive texts. Given Twilio's outstanding API and reliability, I've been working to simplify the project from a hybrid Django & Twisted system to a pure Django system. The simplification was made to bring the development into a single system and way of doing things and to serve as a more robust platform for building extensions in the future. This project has gone on a couple months longer than I would have liked, but the overall work product is a significant improvement over what it's replacing. SMSBot still has its niche, but this project grew in a way that didn't make use of SMSBot's core differentiators (and resulting complexity). I worked closely with the external client on this one, so other than the delays, I'm very happy with the value that I've been able to deliver here and I think that this work will serve them very well in the years ahead.
My major goal for July is to close out IC and MoodText and begin to clear my mind for the fall's project. I have some interesting work lined up on the Purple Robot front involving prosthetics, and it looks like some other Northwestern researchers are interested on building some research around the sleep app I created for the IC suite of apps. From my developer's perspective, I have some interesting work ahead of me.
From a managerial perspective, I'm now managing a team of two and I've been debating whether it makes sense to consolidate around those two and try and build a crack team of native developers or whether I need to start investigating opportunities for doing some empire building of my own in the interest of career advancement. The major issue at an institution like Northwestern is that it's structurally misconfigured to reward and retain software development talent. Advancement in the organization is a function of the people reporting to you, not the value delivered. One of the main reasons that I'm managing two developers is that's what was needed to move me up the pay ladder to receive a salary that makes my employment there worthwhile. The problem that this creates is that now more of my time is spent managing subordinates instead of delivering value. This arrangement works out if the amount of value that the subordinates deliver exceeds the value I'm no longer delivering due to managing management overhead. This arrangement makes no sense if the overall value delivered drops as communication and management overhead overwhelm available development time and deliverables suffer. (There's also an organizational incentive to build in some redundancy, but the benefits to the worker being made redundant are mixed at best.)
If I were working in a technology area where there were plenty of developers available and the amount of time needed to become productive was small, this wouldn't be an issue. However, what I'm trying to build is a bit more ambitious than that. Purple Robot, IC, and MoodText are not the kinds of projects where you can drop off a developer from the street and expect them to start being productive. Purple Robot requires deep experience with the Android system and non-trivial experience integrating with language engines and outside network services. While the IC suite appear to be apps that could have been created in a cross-platform JavaScript framework, many of the apps have specific time, media, or integration requirements that require a moderate level of Android experience. MoodText may be the one project that may have been doable by a junior-level (Django) software developer, but not in the timeframe delivered. Overall, I'm extremely proud of the team that I have, since by design, their roles are intended to be challenging and non-routine.
When I came aboard with CBITs, I explained to Mark (CTO of CBITs, and a great guy) that my goal wasn't to join an Army platoon of developers, but I wanted to build up the Seal Team 6 of software developers. What I meant by that is that the team I wanted to be a part of would be smart, flexible, and determined and able to take on challenging projects that would confound other teams. My belief is that to be a valuable part of a research effort, the technologists have to be as adaptable and flexible as the scientists and doctors that we serve. While there will be many cases where a simple CRUD app will accomplish a research objective (that's great), there will also be times where a more creative and ambitious approach is needed. That's where I wanted to continue to work. In my own consulting practice, I worked with researchers and helped them innovate in their research by innovating technologically. For Ericka Menchen-Trevino, we created a system that captured the web activity of a subset of Chicago voters. For Micere Keels, I created SMSBot to be a completely text-driven tool for low-income new mothers with new babies. For Patrick Hseih, we created a survey engine that allowed researchers to run behavioral experiments within their surveys to understand exactly how respondents behaved when we wanted to ask them a few questions. Once you do something original and creative that hasn't been done before, it's addictive.
Transporting this ethos into an institution like Northwestern is challenging mainly because of financial concerns. Once I have trained a developer to be a robust and creative technologist, their next rational step is to take that training and experience and strike out in the real world on their own projects or work for someone else willing to give them an instant 30-50% raise. Consequently, if I kept a small team, I'd continually be training new talent and hoping to get just enough productivity out of them at the high end to make the process worthwhile. I don't know if I can do that with two or four developers in the current institutional configuration.
The alternative is to investigate some "empire building" of my own. The fundamental idea behind this is that within CBITs, a crack team of developers probably won't have the amount of work needed to keep them busy at the right scale to make the books work. It seems like the key to building your empire is to convince a higher-up that you need to be the monopoly providing a particular service and use that authority to round up the business to keep things afloat. This has happened to us on the server front. I'm no longer allowed to provision and configure production servers on my own - that has to go through another group within the institution. (There are some valid reasons for this kind of centralization, and there some major problems that it's causing.) If I went the "empire building" route, I'd have to convince someone higher up that I was the best party for providing nontrivial mobile solutions and the institution should route all that work my way. I'm mentioning this strategy for the sake of completeness, the actual implementation of something like that would put me in conflict with my colleagues at CBITs and I doubt that there's enough development of this kind happening within the medical school or Northwestern in general to make it a worthwhile endeavor. If I were successful in doing something like this, the result would probably look something like my old employer at A&RT, and it would probably make much more sense to just go work for them instead of reinventing the wheel, poorly.
I apologize for the long digression, but I figured it was worth elaborating upon because one of my goals over the next six months is determining the compatibility between where I am at now and my overall career arc. Make no mistake, despite the frustrations, I feel like I have a pretty good job. I'm doing interesting work and being paid fairly (if not optimally, given competing outside opportunities). The issue is how to deal with the ceiling that I'll be hitting soon and whether I start to find opportunities to match my ambitions or if I scale my ambitions back to fit the available opportunities. I can use my job as the lever by which to budge the world or I can treat it as a funding source for outside efforts by which I try to make a mark. I'll be watching to see how the job and other opportunities evolve in the months ahead before taking any significant actions.
Miscellany
Outside of personal projects and work, I haven't had a whole lot of time to devote to other concerns. The main exception was when I travelled to my old high school to deliver a commencement address. I'm extremely honored that they asked me to speak and I hope that I delivered what they needed. I'm not a regular writer, so this was my first return to any sort of serious writing, and it was a challenge. It's part of the reason that I resurrected this site, as I figure that practice blogging (even if it's a dying art form) would be a way to stretch those muscles and improve my written and spoken communication.'
In terms of diversions, I've been attending films regularly and I've seen a couple of theatrical productions. I have yet to begin that exercise regime I keep thinking about, but I have been enjoying (re)building some upper body strength using a pull-up bar I've installed in my office doorway. I'm not quite ready to tackle the jungle gym like a ten year old, but it's nice to know that I can still do some pull-ups.
Looking Forward
Needless to say, the last six months have been a bit of a rollercoaster. For the latter half of 2014, I'm looking forward to a bit more stability and predictability. Other than the projects described above, I'm not adding anything new to the personal projects roster and once IC is in a decent shape and out the door and in the hands of clinical folk, I'll be glad to turn my attention elsewhere. I've already begun July with an eye towards getting out and enjoying things a bit more - next weekend, I'll be heading out to Six Flags. Me being me, I'm going to have some additional fun with the rides this time and come back with some accelerometer profiles for each of the rides I'm on. It should be a fun, yet productive diversion.
(Photo credit: sdasmarchives @ Flickr)
comments powered by Disqus