DEV Community

Greg Jarmiolowski
Greg Jarmiolowski

Posted on • Updated on

Use a design methodology

Making design choices up front saves you headaches later. You can't make every decision in the beginning but you can set parameters and goals to guide later decision making.

Start simple with some conventions about how you organize code and how you arrange your applications. Some of these conventions can be carried across projects so there are fewer decisions to be made and regularity makes it easier as you go.

Before I start designing a system I try to get lots of input from potential users about how they work and what they need. I solicit documents and spreadsheets they use to get myself immersed in their data.

Then I start to create documentation for what I learned by defining terms first. Having an agreed upon vocabulary helps aid in the accurate exchange of information. Don't expect the customer to always realize when different divisions use the same name for different concepts. These concepts might even change depending on the time of year.

I borrow from Agile and create actors and stories. I get users together to play a game called Focus Mapping with the stories which helps everyone agree on priorities.

Once it comes to designing the database schema I look at the Data Model Resource books for anything I can reuse. Here it helps to think about data not in terms of the semantics but in terms of the shapes. This is where having some exposure to SHACL or GraphQL can help you see the different ways the same schema can be viewed. What you think is the shape for the entities might really just be one representation.

Of course normal forms are important but you need to be able validate the relationships and especially the shape constraints. Finding out you have a single attribute where you needed a list is one of the most common triggers for a schema change, and these changes often are the most work.

I'm a big fan of canvas systems. These can be great for defining up front some set of information and decisions that are needed to build the system. They also serve as a handy and concise communication tool. See examples here and here.

Find what works for you but have some idea of the process you are going to follow before you start wandering. Communicating this to clients also sets the stage and helps you know up front where there might be resistance or where information you need may be hard to obtain or validate.

Top comments (0)