Is design dead?

Todays blog is baout a very interesting article I was reading the article is called “Is Design Dead? “by Martin Fowler (the same guy that did the last one) and I found it really interesting. What is really good about this article is that it talks about different perspectives when we work in a project. First of all you might be interested in an agile practice such as SCRUM or XP. But first of all what is an Agile process? The most important thing is to know that there are no such thing. There are only Agile teams. The environment that are described are environments for a team to be agile. They are used to improve the teamwork within an organization and also it makes the customer an essential member to the team, this is, we will be able to consult the customer any time in order to assure that the work is being done correctly. What this is really called is evolutionary design, it means that the design of a system grows as the system is implemented, we can consider this as good or bad, bad in the way that it will probably insert many bugs in our code, but good because we will have less work to do, which is what any agile practice will want to.

But there is another perspective in the development of a project, a more design-ish one, which is called planned design, it is done the way that design is done first in order to acquire all the possible problems that may surge in the project, this way you may be able to use techniques such as UML, but there are also some risks, the most important one is that diagram are usually left behind and the projects continues without updating any previous diagram that has been used.

This way, my opinion is the same as the author of this article, there is no such thing as which is better if Extreme programming and its evolutionary design or the use of diagrams and its planned design, we need to get a middle point between this structure, first of all if we are going to use diagrams we must assure a way that they will actually be used by the team, the main reason to use this kind of artifacts is to consider them as a way to communicate the changes to the team, so certainly, a main factor to acquire this feature is to keep them simple, the main use of this diagrams after all is to show a purpose of design before it is actually implemented, this way all the team may question why is it done in certain way. Extreme programming in the other way must be balanced too, we must consider the value of simplicity with the YAGNI ( You are not going to need it ) and the other common slogan of extreme programming which is "Do the simplest thing that could possibly work" while this is work, we must search for a balance, maybe a module won't be needed later, but we might know the cost of such module, this way we can actually estimate how much is it going to take us to develop this, in my opinion and as a recommendation if you know about the module and you know it will be needed later on the project, then go ahead and develop it, if you don't know anything about it then just take an Extreme programming approach and develop it later when it is actually needed.

Great Reading.