SWPD #004: Effectively Planning New Development

In this issue, I’m going to explain why planning should always be your first step when working on a new plugin or feature.

man wearing black and white stripe shirt looking at white printer papers on the wall
Photo by Startup Stock Photos on Pexels.com

When you start a new plugin or feature, planning will save you a tremendous amount of time. Some of the worst mistakes of my career can be attributed to how much time I spent planning.

Jumping directly into a project and writing code is usually the worst place to start.

Spending time upfront to effectively plan will uncover hidden risks that can be minimized before they derail a project.

Unfortunately, a lot of developers have a tendency to jump straight into code without planning first.

Planning doesn’t feel like forward momentum in new projects

Often planning is skipped for reasons related to the overall project budget:

  • Writing a project plan takes too long
  • Project timelines often prevent space for planning
  • Planning doesn’t feel like making meaningful progress

Planning is the most important work you can do because it saves you development time, identifies risks before they cause issues, and verifies requirements.

Here’s how to approach it, in 3 steps:

Step 1: Gather all the requirements

Requirements define the project.

So gather together everything that this plugin or feature requires.

  • Will you need to create a custom database table?
  • Will you need an external cache like Redis?
  • Will you need a robust queue system?

Asking these types of questions will help you identify just exactly what’s required by the project.

Try to think of everything that is involved from multiple angles and be specific.

This also includes the technology and software stack that will be used.

Be specific if this project will require an upgrade from PHP 5.6 to 7.4.

Then list them out at the top of the document.

Step 2: List and outline all major components

This is where you really begin to break things down.

Start by listing out all of the primary features with their own heading in your document.

For each, provide a brief overview of what the component is and why it’s necessary.

Then give a quick summary of how this component will be implemented. This is a high level overview so don’t spend time describing the classes or functions being used. List out the system.

Here’s a template you can use:

Feature: [Title/Description]

Overview

This is where you explain what the feature does and why it is necessary in the project. Try to provide any context that might be needed. Be extra specific if you are not the one implementing the feature.

High Level Approach

In general terms, provide the approach that should be used when developing the feature. Try not to be specific here, but list out necessary requirements.

Do specific functions need to be globally accessible? List them out, but don’t work out how they will be implemented.

Step 3: In each major component, identify risks

Risks can completely destroy a project, so you want to be very careful in identifying them early.

For each component section, you should also include the risks involved:

Risks or Known Unknowns

If there are any potential risks for this feature, list them out here. Is there anything involved that can’t be known beforehand? Does this feature involve a 3rd party service or API?

In Review

Planning is critical to the success of your project.

When you go on to develop each feature and component, you will already have the overview, a plan of action, and areas to be careful.

With a plan, you’ll save yourself time and your estimates should be more accurate.