test.ical.ly | getting the web by the balls

Jan/13

25

2 reasons not to over-engineer your structures

complex-structureDevelopers know this best probably. If you start a new project you put a lot of effort into organisation. You organize your files in a folder tree, your code in repositories and branches, your data into tables and more tables, your workflow into tool supported processes, your development cycle into methodologies.

And only a short time later you throw it all away.

 

You can find this in far more situations than only in development.

Topologies, taxonomies, company organigrams and so forth.

Whenever you start something from scratch there will be the impulse to create structures that according to your previous experience will help you in the long run.

Lets say you want to build a network for your friends and contacts and you want to be able to search for them by their home addresses. You realize that not all of them live in the same city as you do and some even live in different countries. Your database experience tells you that you should avoid redundancies at all costs so you create tables for countries and cities separately. Now you write some code to list all of your friends per country and some more code to filter for specific cities. The forms you use to create a new friend item will list all possible cities and countries so you can pick atomic values rather than free text entry with the risk of typos.

Then some time later you will find that al the structure you have created is clean but rather complicated and what’s more it’s almost empty.

Your country table knows over a hundred countries to choose from but your friends really spread over just three of them.

We often tend to over-engineer structure to prepare for situations we haven’t reached yet.

While it is a good thing to be prepared for the future you shouldn’t do this by creating structure for two reasons.

  1. A complex structure that is left unused for the better part will make whatever it is you do less attractive for users to play with or for you to work with.
  2. As your project grows in substance you will likely find that the structure you thought off initially is not quite what you need.

My personal rule is this:

Structure follows substance – not the other way around!

Developers should also know this as the YAGNI principle: You ain’t gonna need it!

Instead you should embrace constant change and prepare to be flexible. Create the structure you need at that moment. You will be able to achieve much more when you accept that nothing will last forever and could be replaced at any moment.

·



<<

>>

Theme Design by devolux.nh2.me