Lessons Learned from a 1-week App

A couple weeks ago, 18F released a request for quote (RFQ) for Agile Delivery Services. This represented a new approach to federal IT contracting.

For typical federal proposals, you spend weeks or months writing dozens (or hundreds) of pages describing how you’ll deliver. (But maybe you are better at writing than delivering.) For this proposal, we didn’t submit paper. We submitted code. Specifically, we developed an application that ┬áleveraged the APIs at open.fda.gov. We had to do so in one week, which was later extended to about 2 weeks total.

Creating an app from scratch in 1-2 weeks is tough, but we did it! We’re proud of the app we created, and the quality of the code. Our top 5 lessons from our team retrospective were…

Whiteboard of "Went Well" with a thumbs-up image and "Better if" with a thumbs down image

retrospective categories from our whiteboard

  1. Slack Time is Great: We were originally marching toward a 1 week deadline, which was then extended before the week was up. That extra slack time let us add some fun features, including a cool tree visualization, that made the app feel more complete and polished. Lesson: Some buffer time helps teams – and running at 100% will actually slow production.
  2. Tests are a Life Saver: Our test coverage was very good. Sometimes it seemed almost heavy handed… until it really saved us… a few times. We were able to re-write parts of the codebase for new features and cleaner code, and could do so with the safety net of 100+ automated tests and instant feedback. Lesson: Good tests are like good brakes on a car, having them allows you to go faster with confidence.
  3. Pausing Makes You Faster: With the tight timeline, we had mini standups 2-4 times per day. Many times this stopped us from going down rabbit holes of analysis or doomed approaches, because we had to stop and coordinate every couple hours. Lesson: It’s better to work in the right direction than to work hard.
  4. Task Switching is Good: At various points, our “frontend” developer would contribute to “backend” code, and vice-versa. Specialization is great, but some times you need to switch gears to get out of a rut. Lesson: It’s hard to assign team roles to precisely, and pigeon-holing can kill productivity and morale.
  5. Design Matters: We are very proud of our prototype – what it does and how we made it. However, we didn’t have a designer on the team (in part due to restrictions in the competition – we weren’t being “graded” on design). Looking back, that would have been a worthwhile addition. Even having an extra frontend developer who could focus on UI polish could have taken our prototype up a notch, and made us feel even better about it. Lesson: A small investment in good design really helps to communicate the functionality of an app.

It is interested to reflect that many of these lessons are about slowing down to speed up. You can go faster by leaving some slack, spending the time to write tests, pausing frequently, and switching contexts.

prototype

You can view our prototype app at RxExplore.com, and view the source code on GitHub.

Recent Posts

Sorry, the comment form is closed at this time.