Many developers have experienced being stuck in a “feature hole” – or worse yet, their project suffers the fate of “Death by Planning.” These are two of the reasons why we highly recommend building a skeleton of a project first.

What is a Project Skeleton?

Imagine that all the polishing and user experience of a project is the meat and skin. It’s easy to see that without all the fine tweaking and pretty graphics, you’re left with a program that does just the minimum of what it is built to do. That is the skeleton.

To better understand what the “skeleton” of a project looks like, imagine the project as a car. The exterior of the “car” is its bright polished paint – this would be the look and feel of a website. The air conditioning, GPS, hand brake, radio, and other interactive parts would be the menus, search, and settings the user has access to. Speed and reliability are great to have, but like everything listed above, they are not needed for the absolute bottom line.

The point of a car is to get the driver and the passengers from Point A to Point B. Remove the exterior of the car along with the comforts and you are left with the bare minimum: a chassis, 4 wheels, an engine, and a seat. That is all that is really needed to get somebody to their destination. Doing so safely and reliably is another issue.

An eCommerce website, in comparison, allows a user to go from looking for a product to purchasing it. This basic functionality is all that is really needed for an eCommerce site to allow the user to find and purchase a product efficiently.

At a bare minimum, it would require only a list of products and a checkout page with a minimal set of logic on the server side. Sure, it would look disturbing – unprotected, far from something you’d want to give to end users – but that skeleton is enough to answer development questions. It’s a working, structural foundation to build upon.

So Why Build a Skeleton Instead of Just Building out the Whole Project?

When making initial plans for a project, it is easy to over-plan or get stuck on minute details such as edge cases, race conditions, tight design, and cross-device compatibility – things that are not critical to the core functionality. This may lead to:

• Asking unnecessary questions or operating on uncertain assumptions
• A lack of clarity for the programmer, making it difficult to know where to start or how the whole thing will function together in the end
• Fear that the wrong direction will lead to the project being scrapped altogether

Luckily, building a skeleton of the project first can help you easily avoid these issues. And this, in a nutshell, is why we recommend it.

Building a Skeleton Lets You Start with Less

Over-planning is a major cause of project delays – or even “deaths.” The team can sit down and analyze the entire project from front to back, pick out each individual detail, come up with possible solutions, and think of features that can be added along the way. This process is great for brainstorming, but too much can drown the project.

It’s best to understand that not all the features are going to make it into the initial build, let alone the final delivery. In a white paper, we advocate for The Strategy of Starting with Less. After brainstorming, it’s important to organize these features into:

• Priority 1 – “This is absolutely needed for minimal functionality.”
• Priority 2 – “This is something we really want, but it’s not critical to functionality.”
• Priority 3 – “This would be nice to have if the budget allows.”

Once planning is finished – make it clear among the team that this phase of development is done – the team can then climb out of the Death by Planning grave. Then, you can focus solely on the minimal functionality, and get to work on creating the skeleton.

Building a Skeleton is the Key to Answering Important Questions

Building the skeleton is the key to answering all of those questions like:

1. Are we making unwarranted assumptions about what the framework or software is capable of?
   • Maybe the framework is expected to function at a high capacity or be easily managed by a content team. Now is the time to test these speculations.
2. Are we making unwarranted assumptions about the best way to integrate with an API?
   • APIs can sometimes be the hardest part of a project. Once a skeleton is built, the API bridge can be reached and crossed. This can influence planning (further on in development) if a different API proves better, the data is missing critical information, or the API turns out to not be needed at all.
3. How do the plugins work together?
   • When using a framework that allows custom plugins, it is not uncommon for multiple plugins to clash. For instance, there was a Fresh project where two shipping plugins on WooCommerce caused critical issues. These issues were not discovered until the project was knee-deep in development.
4. What is the depth of skill of the project team?
   • This can be a sore subject for some developers as not all of us have the same skillset… If a framework or stack requires skills or knowledge that nobody on the team can provide, this should be identified as early as possible. The starting skeleton will challenge the skills of the team members and prove whether their skills are sufficient.

After the skeleton is built, the team can see the bigger picture, answer questions, and challenge assumptions. If there is a problem, it is still early enough to easily make structural changes, such as changing data structures or swapping out plugins. Otherwise, a great chunk of the project would have to be modified to match the changes after it becomes more fully realized.

Getting that skeleton working from end-to-end will give the programmer (much needed) peace of mind and proof of concept.

Build a Skeleton With the Intention to Discard It

Ultimately, you’ll throw away the skeleton. Don’t optimize it. Don’t spend much time planning for the long term. Don’t stress over picking the best possible solution. One of the biggest time wasters is trying to find the best possible solution before having enough knowledge about any of the solutions.

If the intention is to keep the initial build, there is pressure to take it slow, plan accordingly, and worry about the uninformed decisions being made. These critical uninformed decisions can only be informed if progress is made on the project. For these reasons, it is best to build the skeleton with the intention that it will be discarded and the final project will be built from scratch.

In The Mythical Man-Month, Winston Royce is quoted as saying, “plan to throw one away; you will, anyhow.” Too often, systems or whole custom frameworks get scrapped because they could have been more efficient if built in a different way. This mindset and recklessness is just what the skeleton might need to save time and resources in the long run.

If it turns out that the bare bones skeleton project works perfectly, then keep it. Add that code flesh and design that beautiful skin on the skeleton. Clothe it, make it a respectable project. Show it off to the world. Just don’t forget that it is the skeleton that creates a strong foundation for everything else.