Packaging & namespacing

This post is part of The Software Architecture Chronicles, a series of posts about Software Architecture. In them, I write about what I’ve learned on Software Architecture, how I think of it, and how I use that knowledge. The contents of this post might make more sense if you read the previous posts in this series.

The architecture of a system is the high-level view of that system, the big picture, the system design in broad strokes. The architectural decisions are the structural decisions in the system, the ones that affect the whole code base, the ones that define where everything else will be built on top of.

Amongst other things, architecture is responsible for deciding the systems:

  • Components
  • Relationships between components
  • Principles guiding the design and evolution of components and relationships

In other words, these are the design decisions that are more difficult to change as the system evolves, it’s the foundations that give support to feature development.

Continue reading


Lean and Agile in Software Development

As this post is quite long, you can get it in PDF here.

Some time ago, at the company where I am currently working, I suggested that we could create some posters about Lean and Agile so that people would keep it in the back of their heads on their day to day work. I also made myself available to explain, to the IT department, what Lean and Agile are all about, but because of lack of time, that explanation ended up never happening.

Lately, I’ve found that there are some people around me that have the desire and need to know a bit more about Lean and Agile, about what they stand for, how their practices should impact our day to day work, and what’s there to gain from it. So I decided to write this post in an attempt to cover that.

I’ve talked about Lean and Agile before, in a post titled What is Lean and Agile about Software Architecture but it had a very restricted spectrum. In this post, however, I want to take it a bit further.

Continue reading