An Aside: Before Code is Written

Most of my articles have been very code heavy but for this one I want to take time to discuss a bit about the process of developing a program, with the goal of documenting some of the non-code processes involved in creating an application. As a companion to Jody Haneke’s article “The Importance of Definition, and Redefinition in Agile Software Methodology”, this article looks at the phases of software creation from a developer’s perspective.

Definition Phase

The first step in developing an application is to decide what the application is supposed to do. It doesn’t have to be a complete list, but it should include all the functionality that immediately comes to mind.¹ This functionality is specified by a number of User Stories; they consist of a number of entities and they allow a number of different types of user to perform a number of actions with those entities.

Every application will have different entities and different types of user, but most applications are of a CRUD nature. CRUD is an acronym for Create Read Update Delete which are the actions that can be performed on entities. Every entity does not have to have every action, but every action should be considered. Sometimes only certain types of users will be able to perform certain actions on certain entities.

At the end of this process, you will have a list of “user stories”, each of which will define a type of user, an entity and an action that can be performed on that entity.

The deliverable is a list of these user stories along with a list of user types, entities and connections between entities.² (Users may also be represented by entities in the application.)

Design Phase

The next step is to draw out a wireframe. This is often done for websites, but it’s also important for mobile apps. Also during this phase, the processes involved in all the user stories will be augmented with the steps the user needs to go through in order to complete the user story.

These user story steps will start on a particular screen and will detail the actions the user must take in order to complete the story. (i.e., “from screen X, tap button Y, enter Z information, and so on until completion.”)

This phase will produce a list of screens, the functionality (inputs & outputs) available in each screen, connections between screens, as well as a path for each user story from above.

It’s important to remember that this is not a waterfall process. It is quite likely that new user stories will be discovered during this phase along with new entities and users. As they are discovered, a decision will have to be made as to whether these new stories and screens must be in the current version of the application, or can be set aside for a future version.³ If it is determined that they must be included in the current version, then update the wireframe and user story list to include them, and make sure that all stake-holders have buy-in regarding the added scope. These additions will affect costs and deadlines and it’s unprofessional to ignore that fact or try to hide it.

Build Phase

Now it’s time to decide in which order the user stories will be developed. During this process it’s important to take into account any dependencies between stories. If you have stories that deal with sub-entities of some entity then they need to come after the stories about the entities. Each story starts on a particular screen so it is sometimes helpful to group stories by the screen they start on. Lastly, it’s generally easier to develop stories in CRUD order for a particular entity.

The process of developing a user story isn’t just about writing code, each screen also needs a detail-design and decisions need to be made about application wide fonts and colors. All of this can generally be done in parallel; however, it’s best if the detail design of a screen comes before development so that code doesn’t have to be revisited.

And again because this is so important: Even during this process, new user stories, entities and users could be discovered (especially in regard to error paths through stories,) and maybe new screens will be required. If the stake-holders decide they must be in the current version of the application then update the previous deliverables.

1. At Haneke Design, where I am the director of development, we kick off a new project with a Workshop where a Designer, Developer and others sit down with the idea person to define the user stories, as well as design themes.
2. A side note about naming things. In order to foster communication in a team it’s important to be consistent about what things should be called. Naming is hard, but once you pick a name, stick with it. If you absolutely must change it, change it everywhere, including in code.
3. At Haneke Design, we cycle through this process for every version of the application in development, usually once ever three months but, depending on customer, it may be more or less often.