How we brought a new App to life to help web-dev learners — devGaido

What a Long, Strange Trip It’s Been

Introduction

Earlier this year, it was January to be exact, Chance Taken approached me to ask if I would be interested in helping to coordinate a Chingu Cohorts “moonshot” project. Specifically, to develop an application that would fill the need of the Cohorts to efficiently locate quality learning resources to meet the needs of both new and experienced web developers.

At the time I quickly accepted this assignment with the thought that we’d have an minimum viable product (MVP) ready for testing in two to three months. However, seven months into this project we met the goal of reaching our first MVP release. Along the way we’ve:

• lost four members of the team due to the demands of their “real” jobs
• added three new team members and worked through learning about each others strengths and weaknesses
• renamed the app
• scrapped and rewritten the application three times
• learned technologies and tools including React Router, Mocha, Auth0, Nginx, and Docker
• had innumerable arguments over direction, technology, UI/UX, security, architecture and a myriad of other details

But most important of all, we’ve delivered a product we are proud of and the core team have become fast friends.

This article serves as a high-level retrospective on what we did wrong, what we did right, and what we learned along the way. The intent of this and future articles is to share this knowledge in the hope that other Web Devs can take advantage of our experience.

Building a Better Concept

In the initial stages of the project we spent a considerable amount of time defining the personas of our target users, what we thought these personas would want to achieve through the app, and the application capabilities necessary to help the users achieve their goals.

Initially we created fairly detailed documentation and wireframes to capture this information, but quickly found that we were spending more time writing and maintaining documentation than in productive design and development.

Lesson Learned — Be agile. Limit documentation to only what is needed at a given point in time.

As we started to gain clarity on what features the app would need we created a Kanban board in Trello to capture user sagas, epics, and stories for each idea and feature. The format of these user stories was:

Story 019–001–001 As a: End-User I want to: Be authenticated So I can: Have a tailored application experience and be assured that my identify and information is safe.

These stories captured what was needed, who it was for, and how it would help them with additional details maintained as comments on the Trello card. Unfortunately, over time we realized we had too many stories, were spending too much time formatting and managing them, which was not productive.

In retrospect the warning signal should have been that a numbering scheme was required to keep track of the stories and at the end of the day we weren’t referencing or keeping them updated anyway.

Lesson Learned — Keep it simple. You want to use project and product management techniques and tools that you’ll actually use.

We eventually migrated our Kanban board to GitHub Projects which is simple to use, unadorned so you can’t waste time prettifying the trivial, and imposes a limitation on the number of characters you can enter, which helps to ensure that your stories are clear and simple.

Building a Better Team

Having the right team is the single most important component of any project. This doesn’t mean that you need experts or superstars. In fact, there is an argument that loading a team with too many superstars is detrimental since that it also increases the risk of an adverse impact on the team from clashes between super egos.

It’s more important to have a team whose members exhibit the following traits:

• Be respectful of your team mates
• Willingness to listen and give careful consideration to opposing views. But, don’t compromise the product just for the sake “getting along” with the team.
• Show passion for what you believe in without being rude or abrasive.
• Be open to change and ways of doing things.
• Communicate openly and honestly. Do not be fearful of of expressing an opinion.
• Honor your commitments to deadlines and meetings.

Lesson Learned — If you are rude or obnoxious no one will remember that you’re the smartest person in the room.

On one occasion the devGaido team had a very passionate, three day discussion on whether or not to adopt Functional CSS. These discussions took the form of one 2+ hour conference call and multiple hours of back-and-forth on Slack. But to everyone’s credit there were no raised voices, no calling of names, and no disrespect. When the dust settled we had adopted a hybrid form of Functional CSS that has since proven to be quite beneficial.

More importantly, we were all still friends and the positive end result was the product of everyone expressing their opinion, presenting logical arguments and examples, listening, and adapting their viewpoint to something different, yet better in the long run.

Lesson Learned — Don’t be afraid to express opinions and to argue for what you believe, as long as it’s done in a professional manner.

Building a Better Product

The key to building a better product lies in understanding your customers and their needs. It’s also important to continuously refine and test this with the customer.

The Chingu Slack teams proved to be a great tool and we used it throughout the development process to test our ideas and to react to new suggestions. However, Slack is just a tool. What really made a difference were our primary customers — the Chingu’s. This is due in part to the fact that they are vocal and willing to answer questions even before we shared that we were developing a learning app.

Lesson Learned — Build the app your customers will use. They are your best source for app requirements.

One of the main goals of devGaido, and in many ways the hardest to achieve, was to organize learning resources in a way that would be intuitive, would lend itself to simple structure, and would be relatively “future proof”. At least two major rewrites of devGaido centered on improving the path-milestone-lesson concept and it’s presentation.

In fact, one of these rewrites occurred at the start of the first MVP. Having been through such a long development process we felt pressure to release the MVP even though we weren’t totally satisfied with the way learning resources were organized. As a result Kim Kwanka rewrote a very large part of devGaido at the same time we were releasing it.

Lesson Learned — Don’t let deadlines overrule quality.

Throughout the development process we adopted the policy of not including features solely because they were “cool” or packages just because we “might need them”. Every thing that went into the app had to support the goal of meeting our users needs. This didn’t mean that we stopped trying to leverage technology though.

The devGaido application uses React, React Router, Redux, React Helmet, Mocha, Mongo, and a hybrid form of functional CSS. The devGaido runtime relies on the Cloudflare CDN, Nginx, and Docker. No one on the team was an expert in these packages, utilities, and technologies when we started. The team sought out technology to solve user needs and learned it along the way.

Lesson Learned — You don’t have to know it all and you don’t have to be an expert.

Building a Better Test

A key milestone in the life of devGaido was the first release of a minimum viable product (MVP). While we could have been successful just publishing the application URL and asking people to “kick the tires”. But since the first release of an app is arguably the most important it would have been unwise to do it in such a haphazard manner.

The devGaido team prepared for the first MVP release by creating:

• a YouTube channel with an introductory video
• a Twitter account
• a Chingu Slack channel for the MVP teams
• an overview document to communicate expectations and test goals for the users
• Issues log in GitHub for collecting bug reports

As important as these communication and tracking mechanisms are is the teams preparation to set aside time to monitor feedback from the testers, prioritize bug fix over the development of new features, and to promptly respond to users.

Lesson Learned — You don’t have to have an immediate fix for every issue or question, but you do need to respond so users know they are being heard.

The devGaido MVP #1 exceeded our expectations. Not only did we get excellent bug reports, but we also got considerable feedback that included feature requests for things we hadn’t thought about and advice on UI/UX and technical issues.

Lesson Learned — As a development team you can’t know it all. Your testers and users are your best resource for ideas.

We had also planning on a post-MVP #1 survey, but in the end it wasn’t necessary due to the dedication of our testers and the quality of their feedback.

It’s Been a Long, Strange Trip…

At the conclusion of the devGaido MVP #1 I asked myself “was it worth it”? Eight months of effort, hundreds of hours in meetings and pair programming sessions, multiple rewrites, and more than a few heated discussions.

ABSOLUTELY.

I’ve been privileged to work with people that are much smarter than I am and I’ve become a better developer for having known them. More importantly I’ve become friends with those on our team — Kim Kwanka, Francesco Agnoletto, Nick Papasavvas, and of course Chance Taken.

So what is next? We have a number of ideas for improving and extending devGaido’s capabilities and usefulness. We’ve also started work on MVP #2 and planning for MVP #3. In addition, more YouTube videos and Medium articles are on the way to share what we’ve learned. Please keep your comments and suggestions coming!

I hope you find this information useful and I look forward to any questions and comments you might have. Have a good day, afternoon, or evening and go do great things!