Thursday, June 25, 2015

Practical Theory

In the past, I was part of a project focused on redesigning core business functionality. My approach was influenced by fundamental theory. I ended up redesigning the underlying complex database into third normal form. It had 40 tables. When I presented this to the team, the reaction was mixed. From surprise to frustration, I heard that 40 tables are way too much and we need simpler and scalable design.

In following months, another team approached this problem from fundamentally different manner more focused on code first approach. This team initially produced key-value based database with 20 tables. This solution was finalized for implementation.
Now we are close to the implementation and over last few months, the team working on this project had to add lot of additional tables to address functional and non-functional requirements. Finally, this data model is ready with 51 tables.  Lot of core features like data validation and integrity are bolted on to the initial model.

Point of this post is not to turn this into A Vs B design discussion, but to highlight the fact that proven design principals and practical theory like relational algebra; category theory etc. saves lot of implementation headaches and eliminates / minimizes complexity.  In my opinion, quite often this proven strategy is neglected for short term gains, inter/intra team dynamics or just lack of respect for theory.  What you think? What is your experience? 

No comments: