Your software’s architecture is not MVC

Everything starts with a simple CRUD, you add the migration on the database, create the entity, insert a controller, a couple of views and everything seems fine. Then one feature after another the controller begins to grow, and begin to be more and more complicated and difficult to understand.

Rarely the software you are developing is just a CRUD, even if initially seems like this, every business domain has its own set of rules more or less complicated.

Then you realize that the framework architecture is not really perfect for your software, and you are right, because your architecture and your framework architecture are not the same thing, design your software is much more than deciding if some lines of code should be in a model or in a controller. You probably need classes to represent the concepts of your software domain, that are not pages, database tables and routes (that are the domain of your MVC framework), but maybe invoices, taxes, cost calculations or whatever your domain is about.

There are a few presentations that helped me to understand better how to put in practice these ideas:


Don’t ask your customers which features they want

Some years ago I used a soulseek client for linux to download music. It was an open source software, so when I experienced some bug I report it to the kind developer that fixed the issues. One day I thought that the UI would be much better with an option to hide some components, I opened an issue for this enhancement that was accepted and done. When I tried the updated software I discovered that my suggestion was wrong, now the UI was too crowded, it was much less comfortable to use… I slowly stopped using that software.

It may seem strange that when my suggestion was heard I was not satisfied, but this is not uncommon, because customers know their own pain and needs, but are not expert in suggesting the right solution. They are expert in their problems, but it’s much harder for them to evaluate all the trade-offs that needs to be considered.

To avoid this problem you need to understand why they want that feature instead of focalizing on what they want, and starting from it find the best solution that could satisfy the customer. So for example if you want to know in which direction develop your software, use something like UserVoice is a bad idea, because you will have a long list of features without any simple way to understand the reason they are needed, a better way is to interview some of your customers with questions smarter thanĀ  “Which features do you need?”, as Nelson Joyce suggest in this post.