Design Patterns: The solution path


Design Patterns: The solution path

How do you develop softwares? Which patterns or techniques do you use? Maybe TDD, DDD, BDD, DAO, three or four layers, MVC, Web API, WFC, SVC, WS, this or that framework or another letter soup?

Unfortunately, at the end of the day, in real life, what we really use is the trial and error, turning it into the most common “technique” of developing used nowadays.

I believe this kind of practice does not improve the developing standards, preventing it from getting better. The trial and error will always allow gaps or bugs, poor structuring and/or performance problems in an application.

Have you already considered that software developing could be like playing the Diablo in harcore mode? Or building a house? Or making a surgery in a patient? Where there is no space for mistake and every action is carefully thought out, planned and calculated.

The lack of responsibility when writing a code lets people lazy, writing anything in sloppy way and then making a “test” to check if it works, making a debug to find the error and applying the specific “fix” without considering the whole code. The “do this way now, release and after we will make it better” has come to a rule and the code has never been reviewed again.

Let’s suppose it is just like building a house and we start to throw a lot of bricks in an empty land, like a crazy one and then trying to shape that pile of rubble in sort of a house. It is not hard to imagine that it will result in a fragile and dangerous building, and it will take much more time than necessary and even so, we can not be sure that the roof will not fall over someone’s head. It’s even worse if someone asks to add a second floor on that house!! No way!!

If you are treating your application like a “wild beast”, in other words, when you press “run” and you have no idea what will happen? It’s a signal that there is something extremely wrong in the developing or planning manner. Your code can not be unpredictable, after all, it is a precise and rational science. Rule your code.

I look forward to seeing the day arrive when we will create a software in the same way which a civil engineer plans a building, or like a doctor takes his/her actions, considering risks and not accepting failures. That does not depends on random tests or on luck factor.

Nowadays, the existing patterns show the way to a solution for this problem, but they are still far away from being a definitive solution.