Sunday, April 17, 2016

Does software architecture matter?

Short answer, of course it matters! It is in fact crucial, and not just for us geeks. Software houses seem to agree, and a strong indication is that ‘software architects’ and related job titles are paid handsomely. What I doubt is how the software architecture is communicated, if it is considered important from all the involved stakeholders (do they even know they have “stakes” on it?) and how ‘honest’ the developed software application is to its envisioned architecture.

Here would be a good place for a definition of software architecture, but which one to choose from the numerous that are out there? For me all of them are probably correct from the perspective and the context they were produced. From IEEE’s “fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution” to Mr. Martin Fowler’s “things that are hard to change” and everything between (or beyond).

For the point I want to get across the one that seems to fit the best is that a software architecture provides a common (enough) understanding of the system and allows us to reason about it, decide on the trade-offs and keep us on the right track while developing.

I said common enough, because as Mr. Fowler has mentioned “software diagrams are an imperfect representation of a shared understanding between stakeholders”. Imperfect yes, but good enough. And in fact, for different stakeholders, different diagrams or more accurately different abstractions of the software architecture must be used for reasoning based on this common understanding.

Let’s back up a bit and discuss about how I believe most software architectures are defined and used in practice at different companies*. The software architect has a vision of how the application should be, it presents it to management, they don’t understand much but they agree as long as it will be realized in their preferred timeframe and then the architecture is presented to the development team. Software is developed aiming to realize this architecture. A year later the codebase looks nothing like the architecture, the architect probably already left and the architecture found its best use in the least sexy slide of the marketing team for the project. Sounds familiar?

It does not have to be like that. With some discipline, good communication and to be honest a bit more time up-front, software architecture can be really something that matters. And in the long run be both what will make a software application a success and a force for economy of resources when maintaining the application.

So how to go about defining the software architecture? And who should be involved? My concern is how the architecture will be represented and how it will be communicated to different groups. And it is not only the resulted architecture that matters, but the process of generating the software architecture. Dwight D. Eisenhower said “plans are useless but planning is indispensable”. In software, architecture is certainly not useless but its process is equally important, if not more. It brings together the assumptions, expectations and agreed trade-offs of all stakeholders in a software product from the business to the nitty-gritty code monkeys (or artists/scientists/Gods in our own perspective!).

The best approach in my opinion, is to produce different abstraction levels** of the architecture which will be mapped to the interests and technical depth of the involved stakeholders. This will serve the purpose of the architecture which is to give a common understanding between the stakeholders, about which they can reason.
I will attempt to show the value of the architecture (and the process of its definition) by providing a few examples. Let’s consider different scenarios where a good software architecture description can be proved golden.

A new developer joins the dev team:
Lots of legacy code, many decisions and trade-offs were made (shortcuts were taken) while developing as it always happens. The developers that are currently present may never touched parts of the codebase. How are we going to help the new dev get on board? How long will it take to become productive? With a good description of the architecture, it is (relatively) easy. Few UML sequence diagrams for the main control flows of the application, a picture with the layers of the application and mapping of the “diagram shapes” to the part of the code (e.g., packages) will help with understanding how the application works, where to search in the codebase and even what scenarios to run for a given issue. Of course it is extremely important to make sure that the code is sticking to the architecture or that the architecture is evolved during development.

Communicating with non-tech stakeholders:
How to discuss the development decisions with not so technical people? How to decide on the trade-offs? Mr. Bob Martin says that the architecture of an application should “scream what the application does”. And I see the merit in it. The decisions that shaped the architecture show what is important for the application. For example an application having a glitch when putting things on the “bag” of an e-commerce shop might be an acceptable choice, but having a glitch while helping a space vehicle to land, not so much. Use cases, pictures, UML diagrams, metaphors are invaluable tools during the architecture discussions and decisions - for me they are as a unit the architecture, not only some diagrams! These decisions must be agreed and communicated to the developers.

Selecting tools and frameworks:
This is a tricky one. Mr. Martin advocates that we should separate the architecture from the technologies and tools. It has to do with the reversibility, which is desired of course, since requirements seem to change, assumptions could be proved to be wrong and decisions sometimes are not that great. Selecting tools and frameworks often makes things less reversible or costly to reverse which in turn may increase the complexity of the system. So when Mr. Martin says "the purpose of a good architecture is to delay decisions, because then you can make decisions with more information" is pretty good advice. However, technologies to a certain extent shape the architecture. For example the different nature of NoSQL databases compared to relational, have effect in the architecture of the application. Isn't the selection of the database model closely related to the nature of the application? And is it not this choice affecting the architecture? And how these decisions will be made? During the crucial process of defining the architecture. So delay the selections of tools, sure, but the selection is very much part of the architecture. Even for the business the selection of technologies plays a big role. Try convincing a car or plane manufacturer to use things other than Excel sheets to hold their data and you will understand what I mean!

Here is another definition for software architecture: Mr. Fowler stated that “Architecture is about the important stuff. Whatever that is.” As I understand it, in its essence is a statement about communication, the important stuff need to be communicated between involved parties. From business and sales all the way to devs and ops, architecture in different abstraction levels, shapes, and forms gets people to discuss, decide and implement what is expected by all stakeholders. It is figuring out what are the important stuff, communicating the important stuff and building while having in mind the important stuff. And when it is done like this, the architecture really matters.

* Based on what I see and read in different blogs, books and portals
** Defining a software architecture on different abstraction levels is a concept proposed by few people and one of them (most recent to my memory) is Mr. Simon Brown. I rather enjoyed one of his presentations I viewed in youtube Software Architecture vs. Code in GOTO conference.

Wednesday, January 20, 2016

What makes teams great?

Great teams beat great individuals (almost) every time. Most of us have been members of a team at some point or another. The lucky of us who  happened to be members of great teams (or at least felt that way) probably achieved our goals, grew our skills and enjoyed every minute of it. I have been member of teams from early on and still find great pleasure in working within teams. It started with football at my young age and continues in my professional life as a software engineer. Many times I contemplated on what makes a great team and I think that both in football and in software development, the traits of great teams are essentially the same - or can be abstracted to seem like that. In this post I provide my take in what makes great teams.

It all starts with skills. Good teams are made of people that are very skilled in their domain. They constantly work to develop their skills even further and interact with teammates in a manner that improves each other’s skills (i.e., knowledge exchange, motivation, mentoring, etc.). Teams must have big goals and like it or not, certain level of skills are required to reach such goals.

Next, and closely related to the first trait, is the variety of skills. Different members should be experts in different skills so that teammates complement each other’s skills and achieve mutual growth. A software project for example, involves many aspects, such as the user experience, the architecture, performance & security, front-end and back-end development and the clear business value it brings. It is not common for single individuals to be highly skilled in all aspects. But put together people with variety of exceptional skills and with the right process and attitude you will eventually have a team of people who are jack of all trades and master of many. Moreover, discussions between people that approach a given issue from a different point of view, usually brings great results.

Another important trait of good teams is the respect of teammates for each other’s skills. In my opinion, most people involved in software engineering have quite an ego problem. It makes some sense, since designs, solutions and trade-off decisions are not always binary - right or wrong way to do it. People feel very emotional about the things they “give birth to” and are quick to jump and dismiss the opinion of others if they do not respect their skills and knowledge. Many times I heard sentences from fellow geeks such as “he doesn’t know how to test my application right” or “he is not able to write a code of line, he can’t talk to me about architecture”. These things I believe would be avoided and the discussions would be much more constructive if there is mutual respect on the skills of teammates.

The three traits mentioned above, I believe are enough to make a good and efficient team. But what separates good teams from great teams? In great teams, teammates like each other!
It is very important dynamic and changes a great deal of things. I will list the three most important effects it has in the team:

  1. It greatly enhances communication, because every comment or discussion is perceived with good intentions behind it
  2. It creates a fun environment to work in and I believe this does wonders on the team productivity
  3. There is not a “not my f@cking job” mentality and teammates are truly willing to help each other

Hopefully most of us are working within great teams! What are the traits you believe make a great team?