We just finished alpha testing for the event setup function. Our alpha testers gave us some fantastic ideas and critiques—thanks, everyone! Testing cycles don’t just point out problems and opportunities in product functionality. They also improve our understanding of how you think about your events and how you expect your software to behave.
While Brian makes updates to the code (and spends some time out of town), I’m moving forward on design for the slot/scenario/table setup function. We’re entering our next “sprint”—a block of time in which we develop a section of the new site. Sprints are part of a methodology called “agile development”. The idea is that you prioritize the project into manageable chunks, prioritize working software over comprehensive intra-company documentation, and rapidly iterate instead of exhaustively spec’ing. Put simply, you cut as much waste out of the process as you can without sacrificing usability or stability.
Agile is a development model that works well for small teams like Brian and me because it keeps both of us busy all the time. During each sprint, I test the things we built during the previous sprint and spec the things to build during the next sprint. This (theoretically) keeps Brian’s task list full of revisions and new coding. In a more traditional system, he’d be sitting on his hands a lot of the time waiting for a big pile of documentation from me—and then I’d spend a big stretch of time waiting for him to work through all the coding.
The slot setup design is pretty challenging so far but I think we’ve got some neat interface ideas that should make it easy and intuitive. Stay tuned!