Bruno Peeters Technical Blog

A lot of projects struggle with the fact, when and how much time needs to be spend on software design and software architecture. Although these are two separate things, they are entangled with each other.

I once had the discussion with a software developer that no time should be spend at all on software architecture. To him writing down software designs and architecture where not needed at all, it would turn everything into concrete. The design and architecture would grow naturally while coding. Assuming that, architecture and design would imply that once written, you never could change it. As we will see later on, leaving out the design will even lead to software that can’t be changed later on.

On the other side, there are projects where pages of documentation regarding the architecture is described. To find out what the good balance is and when to spend time at design and architecture within Agile, I started to look what exactly the two area’s tend to fulfill and how they could be embraced by Agile.

Software design

Let’s start with software design. I see the difference between software architecture and software design as follows: software design focuses more on creating an abstraction of the building parts regarding an user story. Software architecture focuses more about the main concepts used within the software, and that are most of the times harder to change.

Most people mistakenly think that there is no room for software design within agile. As Martin Fowler states in his blog post “Is Design Dead?“, this is not true (note that Fowler uses the context of Extreme Programming, but this is for sure also applicable to agile in a broader sense). If you would discard design and just start implementing, leading to evolutionary design. As Fowler states, this will lead to a bunch of ad-hoc decisions, which eventually make the code harder to change. When more changes are done, the design deteriorates, and so it will become harder and harder to make changes effectively to your code base.

So if we want to prevent this, we should plan our design. This means we start to think about the problem, make an abstraction of it how to build it – the design – and start to build/implement it.

This upfront thinking and designing of your code, will be done when you’re defining user stories. User stories within agile have a certain life cycle, beginning from where they are created until when they’re ready to be implemented. During time-bound planning sessions, the team will get more information regarding an user story. Within this stage, requirements become clear about the user story and ideally we should know how we want to implement the user story. Diagrams can be added to the user story, giving a clear picture to fellow team members how to implement the user story. When everything is (till an extent) clear, it will be ready for implementation.

This being said, software design should be done during the period when you prepare the user story until it can be put within the sprint backlog. When you still need to do your software design during the sprint, you will fall into evolutionary design, which means in the end harder to maintain code. Also don’t go in all the small details when creating the design, just create enough context to keep on going. When you are uncertain about the feasibility you’re going to design, you can define a spike within the sprint to test your concept with a small application.

When you are uncertain about the feasibility you’re going to design, you can define a spike within the sprint to test your concept with a small application.

Fowler also points out that designing software often is a cultural problem. He states that designers become designers due to the skill and experience they achieve. So it also will take time for less experienced developers, to gain the skills that are needed to design software.

Designing never stops

Also take in mind that designing your software never stops. Perhaps to changing requirements, the current design doesn’t allow us to be able to keep up with these changes. Then refactoring needs to take place to support these requirements.

Also it can be for example that the design turns out to be poorly designed; changes take a lot of time and bugs are hard to find. This is also a sign that you need to refactor your code and change the design.

Design documentation

Complex mechanisms, or other designs or scheme’s that will help the team to increase it’s efficiency may be written down. Use a wiki to put down your designs, so other team members can contribute to it.

One of the difficult things can be that the design and the code go out of sync. The reason can be for example that a member isn’t aware of a certain design that affects this change, or due to pressure one says the design will be updated later on (taking up technical debt).

Software architecture

Besides software design there is software architecture. What is software architecture? Software architecture is most of the time referred to as the architecture of a house, which is my perspective not totally true. In case of a house, when you created a kind of fundament your house stands on, chances are less that you easily could change this fundament.

On the other hand, within software we can change most of the times quite easily the database we’re using. If it is all structured quite well, that means the interfaces with the database stays the same, we can replace the current database with another one. So software architecture compared to the architecture of a house, doesn’t quite go along here. Therefore software architecture can be better seen as a map of a city; it continuously changes to the needs of its environment. Due to the agile nature of software, that holds more closely to the source then the comparison to a architecture of a home.

Why do we need software architecture?

Now we’ve defined what software architecture is, do we even need it? Well, our human brains are limited at the amount of information they can process. Taking a higher level view of the software, defined within concepts, allows us to reason, better remember and discuss issues within our software.

I think everyone agrees that we should have some plan or idea before we start writing code right away. This idea is in fact our design, or one step below the software architecture, if we see code as low level and abstractions as something higher.

Architecture helps us to focus on what are important aspects of the software, and hide details that are not relevant. You will faster see errors and be able to fix them. It allows us to think deeper about the problem then when we are busy writing the implementation in code. While designing, we’re going to ask ourselves questions like “what if this or what if that?”. So it takes us more into the process of designing the solution that meets our problem. Also we find inconsistency much faster by thinking about it.

In it’s book “Design It! From Programmer to Architect”, Michael Keeling sums up these reasons why we need architecture:

• Gets you organized
  Get parts into components, that can be build by different people or teams and together form the application.
• Establish a language between technical people and stakeholders
  Translates the ideas of the stakeholders into something both can understand.
• Makes the quality attributes clear
• Helps you thinking about the problem
  By writing it down, you start thinking about the problem
• Evaluate
  When changes are needed, it can be discussed where the changes need to take place.

Besides the fact architecture helps you to structure your own thoughts, it also helps you to bring over the solution of your problem to other fellow programmers. In its book “Sapiens: A Brief History of Humankind”, Yuval Noah Harari describes the fact storytelling and be able to “believe” in something abstract. He describes that storytelling enabled the homo sapiens to work with a large number of people, which they don’t even knew and therefore couldn’t trust. For example big complex machines at ASML require douzands of engineers to work together for a common goal. By describing each other what needs to be done, within the bigger picture, people are be able to do this kind of complex jobs. It is not genes or other things one engineer gets from his family in order to complete this job.

In this sense also the software architecture allows us to describe at a higher level what the software is supposed to do and allows other homo sapiens or software engineers to work together performing this complex job like constructing a software system.

Creating your architecture

You best start at sprint 0 defining your architecture, and as little as possible. At least the architecture should be able to start the whole team developing the product.

Since we said architecture is about things that is hard to change, you probably better want to postpone choices you have to made as long as possible. Think of the fact how you want to store your data. If you put a interface in between the component that actually stores the data and the caller, you can later on switch from a file based system to for example a database.

The architect within a modern agile environment

By using the term software architect, people may think of a person using waterfall technique and describing the whole software upfront. Nowadays, when using scrum, the architecture is constructed along the way. Since nobody within the team has a specific rol, still a software architect within the team can be someone that is the person that is focussed more on the part of the architecture then others.

The role of an architect, can be seen more as a technical lead; someone who is coaching other programmers and helping where he or she can. Also this means having a look at the code base and detect where issues or other problems may arise. This also fits within the paradigm that all members in the team perform testing, but one person is especially good with testing and keeps an eye (or is responsible) for testing.

Michael Keeling suggests in its book “Design it!” also that when sharing the architecture among the team, the software becomes our system not the system. Also everyone understands the design and feels a responsibility for maintaining the design. It’s like knowledge sharing.

How architecture design fits within Agile

Martin Fowler states that architecture has to do with design within your software that are hard to change. So you want to define them as early as possible. If it is hard to change, it is a good thing to think of how you could make it easy changeable.

Each piece of software eventually has to need some design upfront, otherwise you will run into writing software having no structure at all. I once got the remark from someone saying that he didn’t want to set everything into stone when developing his software. By using Agile, you still have to think of your design before developing. The only thing is you don’t do the full designing and architecture upfront, only the bare minimum, since the opinion of the Product Owner can change. It is very important the the whole team has a common understanding of the architecture, and that it lives within their heads.

Within the following video, Molly Dishman and Martin Fowler describe nicely how architecture could be interpreted within Agile:

Conclusion

A can say we do need software design and software architecture. And it fits nicely in Agile as we saw. It should be done however within the right balance. Happy designing/coding :-) !