Change or die...

Change or die...

When you start designing an app, you of course need to define use cases. Uses cases are a way to describe the user’s requirements but they are more than this. A good use case first analyse the need of the user, then describe it in understandable words for the developer and gives a way to test that the need of the user is covered.

As soon as the use cases are defined, it is time to start implementing them in terms of code. One could start implementing right away in a cowboy mode. Cowboys are good when Time To Market and budget are crucial elements (you need to see fast and without taking care of quality). But as soon as the question goes to lifecycle and investment in time, one should start asking questions like: will my app change in the future, will I use it for a long time, will I need to pivot, will this code base be used by new developers?

All those questions are about one word: “Change”

If you think that what you are developing is going to change, then you will have to deal with some software architecture. It can be as simple as definig a simple design pattern like MVVM-C, od even simpler, like MVC or MVP, or it can be much more complex and refer to specific pattern for specific cases. The most important thing is to stick to what you have decided to do. As soon as you start to compromise, it mostly mean that you are slowly moving to the darkside of development, the side where model are going through all your layers, where boundaries are blurry, where duplication is hidden in what looks like not duplicated, the side where you will start losing time when you thought you were gaining some at the beginning, the side of the technical debt.

I once heard that technical debt is not really a debt as long as you can handle it. It becomes a debt when you can no longer pay for it. This is nicely said when you have a little of money to lose or when you need to borrow a little bit in order to invest in something before fixing your debt. So this is for wealthy people and wealthy companies. For smart companies or companies that do not want to pay for nothing and throw money out of the windows the solution is definitely software architecture and on a daily basis.

You need to be sure that your architecture is always correct!

Resource: