4 Steps to Help Plan and Execute Your Software Development Process More Intentionally

TLDR: make a game plan before you start coding

1. Write a design document with your intentions for the feature and share it with your colleagues

This should include:

• Existing feature sets that will be effected by your changes/additions and a game plan for testing those later on. More specifically, how your code will work within the current system. If there are any concepts that are at odds with how things are currently operating, bring them up with huge red bold font so others can help brainstorm on how to tackle the issue.
• Any specific changes to the database/data model
• How you are planning to break down the feature into PR’s that are short yet comprehensive (i.e., for an edit-profile feature branch you might break up your PR’s like so: profile-data-model, profile-unit-tests, profile-ui) .
• A plan for unit and integration testing and a list of areas in the application that should be targeted for testing

A google doc should suffice in sharing it with your team. The best part of sharing it is that everyone has different experience/exposure to the code base so they may foresee an issue that you overlooked or ask questions that force you to think more critically about your task. Include QA in this process as well!

Another fun thing to include in your design docs is diagrams/visual representations of your plan. This can help solidify the concepts in your mind but also aid in explaining the plan to others as they can physically see the representation of your thoughts.

2. Break up the feature into front end and back end tasks and choose which one to start with

Some people prefer to mock out all the UI first, then prepare the data models but I usually prefer the opposite. The reason is because it’s hard to foresee any hurdles that you’ll come across in the backend that may force your data shape to change. So instead of guessing what your data will look like or wasting time adding dummy data, I find it easier to start with the back end and work my way to the front!

3. Start coding your first task on the list

Notice how coding isn’t until step 3 — one very difficult lesson I’ve learned over the years is that the most important part of software development is not the coding but the planning that precedes the code. Everything should be well thought out and solidified in your mind and on paper before the first line of code is written. By doing this, you’re able to avoid a number of bugs and plan how to integrate you feature more seamlessly into the existing code base.

Also, if you’re using Github, make sure you’ve made a feature branch off of master and then branch off of that feature for your first PR (Master → feature-branch →task-1). This way you can keep your feature’s code contained from master but continue to make smaller PR’s as you go that are more digestible for your team to review.

4. Write tests as you’re coding and make sure to run integration tests throughout the process

Focus on the target areas for testing that you outlined in your design document. One thing I struggle with in testing is getting tunnel vision and only testing the direct areas of the application that my code touched. This is a very bad practice that has haunted me many times. If you’re coding a feature that updates a user’s profile or username, don’t just test that single flow, look at every single place that there is a read or write to the user document or table and be certain that those areas area still functioning as desired.

Also, don’t forget to test on different environments. Sometimes testing on your local env will run smoothly but the data differs in staging and everything breaks. If you merged your feature branch to master and deployed it to staging, check it on there before you ping QA to let them know it’s up.

Final thought:

Before you make a PR, go through the code you wrote and review it as if you’re reviewing someone else’s code. I always find that when I’m reviewing other people’s code I catch all sorts of mistakes or opportunities for optimisation but when I’m actually coding, I follow the path of least resistance and forget those ideas. Reviewing your own code can put it in that light for yourself to optimise!