This is a cross post from Deep Focus Technologies, our development partner on LiquidPlanner’s iPhone App.
Delivering projects on time with LiquidPlanner? There’s an app for that.
With the possible exception of the equator, everything begins somewhere. – Peter Robert Fleming
It was the beginning of the summer and I was sitting with Charles Seybold and Jason Carlson of LiquidPlanner to discuss the possibility of building a mobile application to support their SaaS project management system. It was fun to be working with Charles and Jason again — we’d worked together at Expedia while they were incubating the ideas that would lead them to leave Expedia and create LiquidPlanner.
From the beginning, the passion for the product and the details came through and we quickly sketched out and talked through an initial design for the application and the API (currently in beta) that would sit behind it to provide access to LiquidPlanner. The team had a solid vision for what they wanted the app to do both in the initial incarnation as well as over time. Following the principles that launched LiquidPlanner, we focused on the functionality to deliver in version 1.0.
I headed back to the luxurious offices of Deep Focus Technologies, to work on turning the white board sketch into an initial set of wireframes so we had something more concrete to visualize. More discussion, refinement, and a schedule in LiquidPlanner and we were ready…
The project got the green light and I began work in earnest. Back at LiquidPlanner, Brett had a super-early release of the API — we were almost ready to begin hooking things up.
LiquidPlanner’s REST API is as easy to use as any REST API, but developing the app was made easier by a few of pieces of software upon which I relied heavily.
The first was my data framework. For most of the summer I had been developing an application using sqlite3 on the iPhone that supported CRUD within the standard UI framework. The application hasn’t been released yet, but the framework that sits under it keeps finding its way into released code.
The intention of the framework was to support a variety of data providers, all rendering and providing update facilities through a common set of code. The first test: was the framework able to support a REST API instead of sqlite?
My display framework combined with Justin Palmer’s httpriot, had me up and talking to the LiquidPlanner APIs in less than a day. Basic functionality quickly took shape, and over next several weeks the application became began to resemble the things we had planned to build.
Also extremely useful for developing this type of application was the combination of Todd Ditchendorf’s HTTP Client, Tuffcode’s HTTPScoop and some Apache request forwarding trickery. This setup was my x-ray vision, allowing me to manually play with requests, as well as inspect the traffic to and from the iPhone emulator as it ran my code. This visibility was invaluable as it could easily expose problems in the application’s messaging.
Working With the Team
LiquidPlanner has retained some of the habits that initially made our former employer what it was — rapid execution, focus and eating your own dogfood. This time, the dogfood was both the application and the API supporting it. There are always challenges when working toward a moving target. We used LiquidPlanner’s built-in chat feature and tasks to communicate changes, drops and track work items including a specific set of work items, rumored to exist, apparently called defects.
I enjoy opportunities to work with small, focused teams. There’s an experience of progress that doesn’t exist everywhere. It seems that people who live in that world every day might sometimes forget what the rest of the world is like, but I doubt they’d want it any other way. Everyone focuses on the goal and there is little to get in the way of progress.
As the work progressed, I would spend a couple of days in LiquidPlanner’s offices, focusing closely on user feedback and interactive design/development sessions. The rest of the week I was meeting with other clients or working at my home office. Either way, the schedule required to run my business and make the expected amount of progress on the project required occasionally being out-of-sync with LiquidPlanner’s office hours. I relied on the information in the LiquidPlanner system to maintain connections between where I was and where others on the project were going.
As the milestones passed, the application became increasingly more functional. The work and tracking I once did on the web app was soon working on the iPhone.
The software development process at LiquidPlanner revolves around the product; it is the product. Team uses the system to store documentation, for tracking defects and to constantly chatter about what is happening. They use it for tracking releases and making scope decisions as the work moves beyond the time allotted for the current sprint. The system has become the center of their process, and the iPhone app was designed to become a growing part of that evolving system.
The tool supported functionality throughout the business. Chatter between PR, sales and marketing communicated status on projects in progress. Creative brainstorming and tasks for upcoming blog posts had their own places and schedules. Work in progress and work waiting for a future start was all there. If there’s work to be done, it finds its way through the system.
We developed and tested the app until we had the initial product goals finished and submitted it to the app store in October.
The only thing more rewarding than watching something grow from some scribbles on a whiteboard to a released product in a short period of time, is knowing that customers are using that software to make their projects easier to manage and to help their people be more productive.
– Matt, DeepFocusTechnologies.com