Posts Tagged lean software

When we first started doing Scrum a couple of years ago, there was some discussion about the role and place of the architect in an agile process. Some of the initial literature we read did not mention an architect at all. Building and delivering software in short sprints seemed to encourage a very hands-on approach to software development, trying, building and refactoring in a very iterative way.

However, developing in sprints did not mean that we could all just “dive in” and design as we pleased. On the contrary, by adopting a process where the requirements can change every sprint, it becomes even more important to have some kind of architecture that is just as flexible. In fact, it is the ultimate test for any architecture: a couple of sprints down the road, how easy is it to go in a different direction, to really change core aspects of the system?

Some important lessons we learned here are:

1. Build your software out of reusable, loosely coupled components. Components can easily be refactored, rewritten or thrown away with consequences that are easy to oversee.
2. In the age of libraries and frameworks, be very selective about using big frameworks, especially if you only use 20% of them. Usually at some point, the added complexity of the other 80% will bite you.
3. Have components communicate using service interfaces that are as “small and simple” as possible, and implement them in the simplest way that makes sense. Like with performance optimizations, don’t prematurely optimize until you know something is a problem.
4. Prototype the most critical or complex components in your application. This is where the experience of senior engineers and architects can really make a difference.
5. Keep things simple. For example, building and deploying an application should be as easy as possible. I’ve seen too many cases where you had to follow a long list of steps to get “something that works”. Besides, in your continuous build, you want to produce working artifacts automatically, on every build.

In the end, it’s the role of the architect in this process to make sure the whole team shares the same technical vision. This can be achieved by working closely with the team (an architect should really also have all the engineering skills to talk with any member of the team and really understand what they’re doing), explaining the important aspects of the decisions that were made. It makes sense to document the architecture and design a wiki, using any means necessary, such as taking photos from whiteboards. Make sure these documents are actively read and maintained by the whole team. One thing you definitely should not do is sit in a room for a couple of months and write “the architecture document” in splendid isolation. That is the best way to ensure it will never be read or used.