Flying Symbols

So, after all of 10 minutes of thought to naming, my girlfriend Melissa and I came up with the name Piki for the app, as a shortened form of Picture To Wiki. I’m planning on using my own preferred development process for this project, which is broken down into the following steps:

1. Definiton phase
   Figure out basic goals

   This is what the last post was detailing, the basic usage of the app. At this stage it’s more of a conceptual use case than a formal use case. Essentially, enough needs to be decided here to allow filtering of ‘better’ and ‘worse’ in the exploration phase that follows.

2. Exploration phase
   Find and verify enabling technologies

   This is where most technological architecture decisions are made, such as languages, libraries, communications channels. It consists of defining technical questions that we can use to decide which viable technology will be most beneficial, and answering those questions through a series of small demonstration apps. A primitive library can be developed in this phase to facilitate quick creation of the demonstration apps.

3. Workspace Creation phase
   Create full-package process for chosen technologies

   This is where you make a shell architecture that verifies the packaging system and supports all the app-external inputs and outputs. At the end of this stage, you should have a working installable. The reason for this stage to occur here is that often the packaging process itself presents unique technical constraints on the application, and before the final development, you should be aware of them. This is conceptually the final part of exploration and the first part of development.

4. Development phase
   Implement the features you’ve explored

   This is where the software architecture comes into play as you build out the application. You’ve already verified how to talk to everything, so the focus here is exclusively on how to make things talk together efficiently and intuitively, in a way that will support future goals.

5. Maintenance phase
   Create new features, refactor, bug-fix

   New features and certain refactorings can potentially follow the whole process again, but bug-fixes mostly stay at the outer fringes of the development phase.

I’d contend that this differs from both ‘Agile’ and ‘Big Up-Front Design’ approaches. Agile methodologies go straight to the workspace phase, or in worse cases, the development phase, and often suffers architecturally as a result. Big Up-Front Design typically tries to design before the necessary exploration.