The starting line

The list of features for the first version is set. The screens are designed. The tools are picked. Time to get coding! Where to start, though? Like any project, we’re going to have to split it into smaller bits to make it more manageable.

A good strategy is to go one feature at a time, working on all 3 parts (HTML, CSS, and JavaScript) for each of them before moving on to the next. This still leaves pretty big chunks of work that can be divided again to:

• make sure all issues are covered,
• get a sense of progress.

Thinking of the features

To help to divide the code further, we can think of each feature this way.

At its core, every app is made to manipulate some data it stores. For TaskFight, that would be the list of tasks, as well as the list of matchups and their results.

Through it's UI an app provides users features to "view" some of the data.

1. The UI reads some data
2. And then presents it to the user

Most UI also provides them features to modify the data, through interactive elements for users to act upon.

1. It reacts to the interactions
2. And updates the data

This gives 6 areas to divide the work on each feature further into. Each feature will require varying amounts of work for each of them. For example, reading the list of tasks from the data will be pretty much “here is the list I’m storing”. But accessing the rankings after the fights are done might require recomputing the rankings from the outcomes of each fight.

Divided as such, everything feels way more manageable.

But which feature comes first?

This leaves one last decision: which feature to go with first? First thought is the order in which the users will encounter them. For TaskFight, this would be something like:

1. Add tasks
   • Everything goes fine
   • Prevent duplicates
2. Delete tasks
3. Navigate to the matchups
4. Pick task with most priority
   • Pick winner
   • Navigate automatically to next matchup
5. Navigate to the rankings
6. Read rankings

TaskFight is small, so this order will be perfectly OK.

For larger projects, though, it might be a bit too simple. Not all features are created equal. Some of them might provide more value to users or the business. Some of them might be riskier than others. This would make a good case for starting with them rather than going with the first feature users would use.

Step #0

The list above is actually missing one thing that’ll need to be made. If you remember, the screens of the app are displayed in a common layout: branding and reset at the top, navigation at the bottom. Not really a “feature” to be used by users, but this needs to be addressed.

And this would actually make a good place to start. This would give the app some foundation over which to fit each feature.

So after the tools are set up, we now have a nice plan of attack to bring the app to life, one feature at a time. Like most plans, though, it’ll have to be adjusted as it hits the real world. Especially the split of the work when working on a specific feature will probably not be followed as tidily as laid out. It gives a good direction to follow, though.

Time to write some code, finally!

Thanks for reading

Hope you enjoyed it. The journey is now over and the app will soon be released. You can subscribe to the newsletter to get notified when it'll get opened :)

Keep me updated