Generic placeholder image

Technical and Architectural Debt

Few days ago, I read a very interesting article from John Brondum and Liming Zhu: Visualising Architectural Dependencies. Its title is all about visualising architectural dependencies, but its introduction is amazingly interesting (the rest is too, but it is more technical). First it will give you a very strong definition of what technical debt is: “Technical debt has been used as […] a metaphor in situations where compromises are made for short term gains, at the expense of the longer-term viability of a […] system.

Read more
Generic placeholder image

Horizontal and Vertical in software architecture

As the image above suggests: I like to use DDD to give some verticality to the app and design patterns to give some horizontallity to the app. You potentially use design patterns every day as a software engineer (or at least I hope for you). In mobile development the star patterns are actually MVVM-C (in iOS world) and MVP (in Android world). You can find few other examples in this good book: https://www.

Read more
Generic placeholder image

Developers: Be proud to fail

The concept of failing is generally not something you should be proud of, but in fact in IT development this is something you should consider as positive. Let me explain why. First let’s define what it means to fail. Failing in our case as nothing to do with creating bugs, failing is about detecting potential mistakes in advance and blocking the delivery process. For example, you fail when you can not compile, you fail when your unit tests fail, you fail when your PR is not validated, you fail when your metrics are not compliant, you fail when your CI tells you it can not build, you fail when your CD can not deploy.

Read more
Generic placeholder image

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.

Read more
Generic placeholder image

Monolithic vs Modular

It is very easy to develop a complete app all in one file. Of course it’s a very bad practice and it should (must) be avoided. But it is not because you create tons of files and classes that you gain anything in your app. Of course you now have tons a small classes and you have now very small pieces of code which is a good starting point. Unfortunately it’s like building a huge castle made out of small bricks but all your bricks are fully glued and thus all your code will move in one piece (once you have build your castle you will have to move it all at once).

Read more
Generic placeholder image

4 + 1 View Model of Architecture

The concept of 4+1 view was introduced by Philippe Kruchten in his paper: The 4+1 View Model of Architecture. To make it simple, it’s a way of creating multiple point of views for the development of a software. There are 4 “simple” views and one that glue them all together. The first four one are : The pogical view The process view The realisation view The physical view The one that glues them all together is the use cases view.

Read more