Chapter 5: Should we make a funeral for our beloved stage Design?

Design; one of the stages we hate (or love) the most has became irrelevant. Or maybe that's what some people say.
Is design dead?
Well, the first paragraph of the article made me think that the headline was click-bait. Starting off saying "... involves a lot of design, but does it in a different way than established software processes", made me re-think of the title. A clearer approach could have been "Design is evolving", however, I agree with what the author is implying; classical design phase is being replaced by evolutionary design, thanks to the XP outburst.

Later in the article, the author states the big difference between planning design and what XP allows us to do with dynamic design. As they are “counters” to each other, each has its advantages and disadvantages (the author implying that evolutionary design is better) I think that getting a balance of both should be the goal. Yes, I love evolutionary design (as it is easier and requires less time before coding), but I also think that planned design is needed as it can lay a foundation of what we want and what we will build.

What I propose is a mix of planned and evolutionary design, and the way I think we can archive this is with a carefully made Planned design, allowing evolutionary design and XP to kick in. Of course, it must be done smartly, as each methodology counters each other, but we can still make room for the latter method, with an initial design that allows easier change, without having a “sloppy” foundation. The initial design should also permit big changes without affecting much in the rest of the design.


Planning something dynamic may sound counterintuitive, but it is possible with enough creativity, as we can make our foundation fool-proof, not as a “definitive design” foundation, but as a design that allows itself to be transformed without letting the main objective of the design fall though. If we can accomplish this type of hybrid design, we can then get smarter, faster, and more carefully planned projects. 

 References:
Fowler Martin (2004). Is Design Dead? Available on: https://martinfowler.com/articles/designDead.html

Comments

Post a Comment

Popular posts from this blog

Chapter 4: Architectus Reloadus vs Architectus Oryzus

Image
So, who needs architects anyways? Here lies one of the most important roles in the software world the unstoppable Architectus Reloadus. After reading the article, it reminded me of an image picturing 2 groups of people; each group having either a boss or a leader commanding them. While the boss was just instructing where to go and what to do, the leader was working with its group. This is the same analogy we get in the article with the 2 types of architects mentioned, the  Architectus Reloadus  and the  Architectus Oryzus . Architectus Reloadus  is the architect that proclaims himself as the  most important part of the project , as the design is made only by him, leaving the other developers to follow. While the  Architectus Oryzus  works within the team to improve the team’s level so they can approach harder and more complex issues. In other words, the Architectus Oruzys  is a guide, skillful enough for being the anchor of the team, and clearly selfless, as he works at the
Read more

Chapter 11: Metaprogramming

Image
The last article read was “An Introduction to Metaprogramming”, an interesting article where Ariel explains the concept and some examples of metaprogramming. Starting of describing the different types of metaprograms, like compilers, interpreters, parser generators, assemblers and preprocessors, metaprograms come in many shapes and forms, which main goal is to eliminate or reduce error-prone programming tasks. I have heard of this concept as a utopic approach to things, however, I haven’t seen metaprogramming first hand. At first, I thought it was a really complex way to do things, but after reading the article, it doesn’t go that deep into weirdness. Beginning with the first example; it clarified how the concept of metaprogramming works, a script that wrote another file with the code expected. While the ruby snippet shown was not some other world stuff, but the example is pretty clear, we can write codes through code. Now, the second example goes a little bit deeper
Read more

Chapter 9: Microservice Architecture: A whole new Architectural world.

Image
After reading the article, I started relating microservice architecture with the activity we made when we talked about components and Lego bricks in class: This type of architecture is made of smaller and independent services that are linked together to form a concrete service. With the image below, we can see a clear representation of how this is conceptualized. However, there is a small detail that separates microservices from monolithic services; while the later gathers all functionality into a single process, the microservice separates each part of the functionality into a separate service, allowing scaling with distribution of the services, replicating as needed. This is the aspect I liked the most; low key planned modularity for software architecture (or at least that’s how I see it) There are a lot of interesting features of this type of architecture (with a heavy approach to encapsulation, as I dare to confirm), such as Componentization via Services, Organized ar
Read more