Building an App Series Part 2: The Product Development Life Cycle
Imagine you’ve become proficient in all of the technical skills required to be a software developer. You and your friends have an awesome idea for a product that has the potential to make millions. Where do you start?
In this series of articles we will guide you through the entire product development life cycle. Traversing the product development life cycle from the idea stage, to a finished product can be filled with pitfalls and unnecessary redundancies. Our goal is to show you that planning ahead, with plenty of specificity, reduces the chances of encountering inefficiencies that slow down development progress. As developers, it is our job to plan ahead and maximize our efficiency when building an application.
Over the next 10 articles, we will focus on the creation of a code resource aggregator called CodeBuddy. CodeBuddy will be open to the programming community, available for anyone interested in coding, programming, or design. The inspiration for CodeBuddy revolves around the disorganized nature of maintaining and organizing programming resources. CodeBuddy will allow users to organize their resources by categories and search for pertinent information in one central location.
CodeBuddy will also depict the product development life cycle from an agile-minded developer’s perspective. Before we dive right into code, let’s discuss fairly recent changes in product development and how they have impacted both developers and users.
The Manifesto for Agile Software Development
The idea of agile software development devolved from dissatisfaction with the widely used waterfall model of the 1980s and 90s. By adhering to waterfall methodology, developers followed a sequential path from the ideation phase down to implementation.
Software developers and clients had very little interaction except during the ideation stage of a product’s life cycle. If a client came back to the developers at the conclusion of a project and asked for a change, developers would have to reconfigure the application according to the client’s request. Then, the designers would have to make their changes to support the new or updated functionality.
Recognizing waterfall methodology’s inefficiencies, developers reconsidered and reinvented the product development life cycle. In February of 2001, a number of software developers from all over the U.S. assembled at a Utah ski resort to philosophize on the merits of leaner development strategies. With the Manifesto for Agile Software Development, they developed standards that have forever transformed the software development landscape:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right,
we value the items on the left more.
The 4 tenets of the Manifesto for Agile Software Development shifted the focus of software development towards continuous customer collaboration and user-centered architecture. Constant collaboration with customers allows developers to create dynamic, flexible plans. Flexible planning practices also provide transparency for customers when it pertains to deadline and budgetary adjustments.
With this pivotal transition away from rigid, mechanical planning practices, developers gained more control over the product, and more importantly, their time. When building software, it is critical to understand that time is expensive. Reducing the amount of a time a developer has to spend on a feature maximizes efficiency, both occupationally and financially.
What’s Your Problem Statement?
The ultimate goal of any web application is to solve a problem. How do we figure out what problem to solve? Well, we define aproblem statement.
A problem statement answers why a web application needs to be created. It also gives developers the required insight necessary to complete the project in accordance with best practices and client specifications. There are three important components to understand when formulating a good problem statement.
- The first component of a problem statement identifies a problem that has not been adequately addressed. For example, “Vikram is hungry.” This sentence identifies the object that has the problem (Vikram) and describes the specifics of the problem (he is hungry).
The second component of a problem statement describes the conditions that hold us back from getting what we want or what we want to achieve. For our test case, “Vikram is a vegetarian and is currently at a barbecue contest. All of the food at the barbecue contest is made of meat.” The condition here is that Vikram cannot eat any of the food he is currently surrounded by.
The third component of a problem statement describes what needs to be done in order to realize a resolution to the overall problem. For our test case, “Vikram needs to leave the barbecue contest and find the nearest place that serves vegetables and tofu.” Here, we identified a possible resolution to the problem that should be further explored.
Combining these three components, the problem statement becomes, “Vikram is a hungry vegetarian. Since he is at a barbecue contest where everything is meat, he should leave and find something he is able to eat.” This statement tells us what the problem is and proposes a possible solution.
For CodeBuddy, our problem statement is, “Many developers find the process of organizing and cataloging web resources to be rather tedious. We can never seem to find the time to sift through and prune our vast collections of bookmarks. Wouldn’t it be nice if there was a tool to help us with this task?” So we have our problem statement. But, how do we figure out how to solve this problem? Well, let’s ask ourselves some questions.
What is the ultimate purpose of the application?
Let’s start at the end goal and work backwards. This series will be focusing on the creation of an aggregator for coding resources; a web application that will be a one-stop shop for programming articles, books, and reference material. Users will be able to search the entire library of references to find tutorials on a variety of coding topics and solutions recommended by their programming peers. Users will also be able to organize the references they found helpful in their own personal lists.
Who are the application’s intended users?
CodeBuddy’s intended users are developers and designers of all skill levels. Also, because we love open source, CodeBuddy will be free and open source under the MIT license.
What is the most important function that every other function relies upon?
Before diving into building our application, it is important to clearly define the most important component of the application. CodeBuddy’s most important component revolves around the ability to add, organize, and describe code references. Once a reference exists within the application, it can be commented on, it can be voted upon, and it can be compiled into a personal list. Thus, our initial focus should revolve around setting up the Reference object.
Are there any specific integrations required by the client?
Many sites today utilize authentication with other websites. If you’ve ever signed in with Facebook or Google, you’re using this type of functionality. Because we might want to eventually integrate with these services, we’ll also investigate how to make this type of authentication happen.
User Stories
Today’s developers promote the implementation of user stories that ascribe to agile methodologies. Good user stories articulate the role of the person utilizing the feature, what the user wants to do, and the business value that is realized from their ability to do it. To create a good user story, today’s developers use the Actor/Action/Achievement format.
Say you wanted to search for the Game of Thrones books on Amazon. A user story would look something like this:
As a Game of Thrones enthusiast
I want to search for the books on Amazon
So I can see if the sixth book has been finally published
The “As a Game of Thrones enthusiast” component describes the actor’s condition. Describing who the actor is gives developers context as to who will be able to utilize feature. The “I want to search for the books on Amazon” component expresses the actor’s intended actions. Explicitly declaring what a user’s next interaction with the application will be gives developers insight into required features and functionality. Lastly, the “So I can see if the sixth book has been finally published” component expresses the desired result of the actor’s interaction with the application. Understanding the user’s intended outcome is paramount to providing an application’s intended users with a satisfactory experience.
Writing user stories for most features in an application is an integral component of producing a high quality product. But be warned: over-planning can cause plenty of headaches in the development process. Since developers value and rely on customer collaboration, components of your application will change along with the plans that managed them. It is important to note that change is the only constant in the software development realm.
When developers take the appropriate amount of time to consider user interactions, they increase the efficiency potential of an application’s build process. They know that it is nearly impossible to write every user story before building an application. However, defining the core user stories prior to initiating the actual build process is a critical component of a product’s development life cycle, especially when it pertains to time and resource management.
Acceptance Criteria
Developers write acceptance criteria that accompany each user story. Acceptance criteria further define the specifics of a given user story by describing the expected results of a given interaction. The user’s interaction needs to follow a set of rules in order to optimize maximum user satisfaction. Without these guidelines, the developer would have to guess as to how to achieve a user story’s primary objective.
If we look back at our Game of Thrones user story, we know the primary objective is to see if the sixth book has been released. Examples of applicable acceptance criteria would be, “I must be able to search from the home page,” or, “I must see suggestions for what I am typing in.” Now, the developers have a set of specific parameters that must be adhered to in order to satisfy the user story’s primary objective.
When all of a given user story’s acceptance criteria are satisfied, the user story is considered complete. In future articles, we will implement user stories and acceptance criteria to create functioning code that ensures our program does what we want it to do.
Wireframes
Designers use wireframes to encourage discussion with both developers and customers. Before writing code for the front-end, it is important to get incremental feedback from customers so that their expectations are met.
Like everything in the web development process, there are stages to wireframing. Developers refer to these stages as “spectrums of fidelity,” meaning there are levels of specificity in each stage. Designers typically begin with basic sketches that outline functionality and features for a given part of an application. Take the homepage, for instance. At the earliest stage of fidelity, we ask questions like:
-What components of the application should be featured on the homepage?
-Should we use a navigation bar at the top?
-Are there buttons that need to be added? If so, where should be put them?
-Where should the logo go?
For CodeBuddy, I’ve created a low fidelity sketch:
INSERT IMAGE HERE
The lack of color and detail is intentional. At this stage, it is important to solicit client feedback. Low fidelity sketches encourage client collaboration. With this level of fidelity, clients will instinctively have ideas about what they want and don’t want. Whatever feedback developers and designers can get at an early stage, the more opportunities they have to satisfy the clients. Also, clients will feel more involved with the overall development process.
As we progress through the design process and begin designing the front-end in earnest, higher fidelity sketches will be far more valuable. Adequately reflecting client feedback in higher fidelity sketches makes for an easier design process.
What’s Next?
Next time, we will discuss the merits of programming in Ruby. Ruby’s syntactic simplicity and functional readability is great for establishing a baseline programming skill set.
I encourage readers to think about some user stories we will need for CodeBuddy and some acceptance criteria to go with it. Here are some questions to get you thinking:
- How would you format a user story for creating a resource entry? What are some acceptance criteria you would want?
How would you write a user story for voting on the efficacy of a resource? What are some of your favorite voting mechanisms on the web, and how would you write them in terms of acceptance criteria?
Continue the conversation in comments and I’ll be sure to reply there quickly to any questions that you pose in the meantime.