So How’s It with Architecture - Up-Front Design or Evolutionary Architecture?

Table of Contents

So How’s It with Architecture - Up-Front Design or Evolutionary Architecture?

Where does architecture currently stand? We can say that there are two classic approaches:

  • The classical approach, which requires carefully planning as many details as possible (up-front);
  • The agile approach, which dictates making decisions as late as possible and developing architecture through refactoring.

How does this usually happen in projects? In many cases, a more or less detailed project is created in the up-front style and remains that way. On the other hand, relying solely on organic development of good architecture through natural evolution usually also fails. In large projects, it is extremely risky as it often leads to local solutions that should be rewritten at some stage (which usually does not happen).

In practice, a mixed approach works best. At the beginning of a project, release, or iteration, a concept and design of a solution is created, which serves as the basis and reference point for project work. This project does not have to be, and even should not be, exceedingly detailed. On the other hand, we should not assume that what was devised at the outset will be a perfect solution. Consequently, during the project work, we make ongoing local modifications to the design assumptions through refactoring.

By doing so, we obtain a natural process of architectural development. Initially, it is pre-designed, which prevents us from wasting time and resources on evolutionary wandering. We use evolution to improve the original design. If we link this with the process of Natural Order refactoring, we are in luck! More on that in future posts.

The process sketch looks as follows:

(Sketch image removed)

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

Disappointment, Focus, and Solutions for All Problems ;-)

Introduction

Many of us dream of a situation where we can work at a sustainable pace, having enough time for everything and being able to comfortably do our job. But it doesn’t work. I’ll tell you why.

Read More

Effective Understanding of a Topic

This time, the topic slightly ventures beyond IT projects. Recently, I’ve been doing a lot of research work where I need to construct a coherent extract of practical information from a multitude of knowledge sources. After extensive work in this area, I’d like to share a few tips that I’ve had the chance to apply multiple times.

Read More

A Manifesto Against Developers

A Manifesto Against Developers

I hate you because:

  • You focus on the features of your IDE instead of the features your client/user needs.
  • You consider typing at the keyboard as thinking.
  • You waste countless hours manually testing your code.
  • You spend more time struggling with frameworks than delivering value to end users.
  • You code for hours without asking yourself, “What am I really doing?”
  • You naively believe that technologies and tools will solve your problems.
  • You naively believe that a good algorithm is more important than a good understanding of requirements.
  • You naively believe that your intuition is enough for writing good code.
  • You naively believe that you can manage the complexity of the system piece you’re working on.
  • You agree to unrealistic deadlines.
  • You write poor code and rationalize it with various excuses (because there is no time).
  • In your head, you create code snippets without really knowing what needs to be done.
  • You guess what needs to be done rather than clarifying.
  • You mindlessly follow the technology you use.
  • You don’t understand the tools and technologies you use.
  • You isolate yourself in your piece of code, breaking contact with the world.
  • You think it’s all the fault of managers or clients and believe you can’t do anything about it.

… even though I love you because I am a programmer myself.

Read More