Development Tip 7: Skeleton creates a solid foundation for all projects

Many developers have been in “feature holes” or worse, their projects have suffered the fate of ” death by planning“. These are just two reasons we recommend that you build a skeleton first.

What is a Project Skeleton and how does it work?

All the polishing and user interfaces of a project are the meat and skin. You’ll see that a program does not do all that much without fine-tuning and beautiful graphics. This is the skeleton.

Imagine the “skeleton” for a project as a car. This will help you to understand the structure of the project. The car’s exterior is its shiny, polished paint. This would be the appearance and feel of a website. The radio, GPS, hand brake and radio are the interactive parts. These include the menus, search and settings that the user can access. While speed and reliability are important, they do not necessarily make the bottom line.

The purpose of a car is for the driver and passengers to travel from Point A to Point B. You can remove the exterior and all the comforts, and you will be left with a chassis, four wheels, an engine and a seat. This is all you need to get someone to their destination. It is another matter to do it safely and securely.

An eCommerce website allows users to search for products and then purchase them. An eCommerce website should only provide this basic functionality to enable the user to search for and buy a product quickly.

It would only require a list and checkout page, with minimal logic on the server-side. It would be a bit disturbing, and not something you’d want to share with end-users. However, the skeleton can answer any development questions. It is a solid foundation that you can build on.

Therefore, why not build a skeleton instead of building the entire project?

It is easy to get bogged down in details, such as race conditions, edge cases, tight design and cross-device compatibility when making initial plans for a project. These details are not essential to the core functionality. This could lead to:

• Unnecessary questions asked or relying on unreliable assumptions
• Programmers lack clarity, which makes it difficult for them to know where to begin or how everything will work together in the end.
• Fear of going in the wrong direction could lead to the project being abandoned altogether

This can be avoided by first creating a skeleton. This is why we recommend it.

Build a Skeleton with Less

Over-planning can lead to project delays or even death. The team can take a look at the whole project front-to-back, identify each detail, brainstorm possible solutions, and consider adding features along the way. Although this is a great way to brainstorm, it can also drown your project.

It is important to realize that not all features will make it to the final build. We advocate The Strategy for Starting with Less in a whitepaper. It’s important to organize the features after brainstorming.

• Priority 1: “This is absolutely necessary for minimal functionality.”
• Priority 2: “This is something that we really want, however it’s not essential to functionality.”
• Priority 3: “This would be nice to possess if the budget permits.”

After planning is complete, let the team know that this phase is over. The team can now climb out of the Death by Planning hole. You can then focus on the minimum functionality and start to build the skeleton.

The key to answering important questions is building a skeleton

The key to answering all your questions is building the skeleton

1. Are we making unfounded assumptions about the software or framework’s capabilities?
   • Perhaps the framework will be able to handle large amounts of content or function well under the supervision of a team. These speculations can be tested now.
2. Do we make unfounded assumptions about how to best integrate with an API?
   • Sometimes APIs are the most difficult part of a project. Once the skeleton has been built, it is possible to cross the API bridge. This can impact planning (further along in development), if a better API proves to be more useful, if the data is lacking critical information or if the API doesn’t seem necessary at all.
3. What plugins are compatible?
   • Multiple plugins can crash when using a framework that allows for custom plugins. Two WooCommerce shipping plugins caused major problems in a Fresh project. These issues weren’t discovered until the project was already in its final stages of development.
4. How deep is the skill level of the project team?
   • This is a difficult topic for some developers, as not everyone has the same skillset. It is important to identify any frameworks or stacks that require skills or knowledge that no one on the team can provide. The team’s starting skeleton will test their abilities and show whether they are competent.

Once the skeleton has been built, the team will be able to see the larger picture, answer questions and challenge assumptions. It is possible to make changes in the structure of data structures and plugins if there is a problem. A large part of the project would need to be modified if the changes are made.

Programmers will feel much more confident knowing that the skeleton is working correctly from end to end.

Make a Skeleton with the intention to discard it

The skeleton will eventually be thrown away. Don’t optimize it. Do not spend too much time looking at the long-term. Do not stress about finding the best solution. It is a waste of time to try to find the best solution without having sufficient knowledge.

If the goal is to maintain the original build, it is important to plan carefully and take things slowly. If the project is moving forward, these critical decisions cannot be made without being informed. It is better to create the skeleton knowing that it will be removed and that the final project will be constructed from scratch.

In The Mythical Man-Month Winston Royce is quoted saying that “plan to throw away one; you will, anyway.” Many systems and custom frameworks are scrapped simply because they were more efficient if constructed in a different manner. This recklessness and mindset are exactly what the skeleton may need to save time in the long term.

Keep it if the bare-bones project works well. You can add code flesh to the skeleton and create beautiful skin. Make it a worthy project. It’s your chance to show it off to the rest of the world. It is the skeleton which creates a solid foundation for all other things.