In the last couple weeks, I had the chance to talk with lot of people and teams from different companies. And some common themes appeared, like motivation issues, code quality, odd architecture choices and slow delivery cycles.

I reflected about these issues and a common element seemed obvious between them: the lack of design, or better, bad design. To discuss what is good or bad design, a definition is welcomed:

Good design is design that is informed by specific information, what kind of climate do you have, what kind of building code do you have, what kind of social behavior do you have and which you would like to promote. So that everything you do is actually done for a specific purpose. Because I think good design is careful, bad design is careless (Ingels, 2015)

As you noticed, Bjarke Ingels does not work with software: he talks about the climate, burocracy and social behavior. Ingles is an architect, but he has a good point: good design is informed and careful.

A partial transformation

In my Domain-Driven Design introduction talk, I start discussing how design was put aside even with the Agile transformation that happened in the last 16 years. Sandro Mancuso discuss in his The Software Crafsman book about how this transformation was partial:

The Agile transformations focused mainly on process; empowering people; reducing bureaucracy and waste; prioritization; visibility of work in progress; and improving the information flow. These were real and important problems that needed to be solved (…). However, the principles behind Agile (Manifesto) were forgotten. Process became more important than technical excellence. Technical excellence, which is assumed to be in place by every process-related Agile methodology, is normally ignored by managers and ill-prepared Agile coaches. (Mancuso, 2014)

This partial transformation unfold in the problems I introduced above and in the proverbial “we tried, but it did not worked” and “this won’t work here”. There is no way for methodologies or processes that depends on feedback cycles succeed without technical excellence and without improving the skills from the team’s professionals. Then we come to the following (sad) fact:

Many Agile projects are now, steadily and iteratively, producing crap code. (Mancuso, 2014)

Design is everywhere

The design that manifests in code is the result of the intersection between the organization’s design and the team’s design. The design question is by no way an issue of a single team member.

It is worth noting that most of the time, when I talk about software development, I’m talking about a human-technological endeavor that is done by a team. The majority of softwares are developed by teams.

Behind the Agile methodologies, behind the Lean/Kanban and behind the DevOps, we always find principles or objectives for the creation of highly functional teams. From the Agile Manifesto (Beck et al, 2001), we have the principles 8 and 11, for example:

  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
  • The best architectures, requirements, and designs emerge from self-organizing teams

From Lean (Liker, 2003), we have the principles 9 and 10:

  • Grow leaders who thoroughly understand the work, live the philosophy, and teach it to others
  • Develop exceptional people and teams who follow your company’s philosophy

And from DevOps (Debois et al, 2016), from The Principles of Continual Learning and Experimentation, we have:

  • Enabling organizational learning and a safety culture
  • Institutionalize the improvement of daily work
  • Leaders reinforce a learning culture

So, the professional software development activity happens in teams, in an organization. And the design of the organization and of the team influences in the code design. Dr. Melvin Conway has some words about this phenomenon, that became so famous that were promoted to what is known today as Conway’s law.

Conway’s law

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure. (Conway, 1968)

Conway’s law is a sociological observation that can be observed in different kinds of team’s organization. The famous Amazon’s two pizza team (2PT)1, for example, limits the teams’ size to a maximum of 5-10 people. This constraint has important effects (Debois et al, 2016):

  1. The team has a clear understanding of the system they are working on
  2. It limits the growth rate of the product or service being worked on
  3. It decentralizes power and enables autonomy
  4. Promotes a safety culture, the smaller work scope limits the failures’ consequences

In the same way, it seems that the Spotify’s Squads (Kniberg, 2012) contributes to achieve the same effects.

The difference is that Amazon is a market-oriented organization, optimized to respond quickly to the clients needs and formed by multidisciplinary teams in a flat hierarchy. Spotify is a matrix-oriented organization, which combines elements from functional-oriented organizations (optimized for expertise, labor division and cost reduction) and from market-oriented organizations.

The important thing in these differences is the fact they disclose a concious organization design. If good design is informed, adopting a team organization like Amazon’s 2PT or Spotify’s Squads requires understanding not only the teams’ structure as well as their interdependencies and the impacts of these new dynamics in the organization.

This design, made in a careful way, dictates how the work is performed and the achieved outcomes (Debois et al, 2016).

Teams, individuals and code

The teams’ design is a direct outcome of the organization’s design. Market-oriented teams are, in an extreme, totally responsible not only in software development, but also for testing, securing, deploying and supporting their service in production. They’re DevOps teams (Debois et al, 2016).

The classic Scrum team is also cross-functional, formed by a Product Owner, by the Scrum Master and by the Development Team. However, the goal for this team is to deliver a potentially releasable product increment (Schwaber, 2013). This team’s responsibility is limited to the software development.

The teams’ structure will define their interactions and potential conflicts. Usually the developers defines how they’ll work. However, they seem to not realize their influence in the organization and for the whole society: the world depends more and more on software.

Developers are, generally, highly motivated and curious individuals. But this same curiosity seems to result in an extremelly technology-oriented mindset. It is not uncommon to see teams trying to solve problems with technology instead of doing a careful design. Then, the software model turns into a Big Ball of Mud (Foote; Yoder, 1999), with almost no business’ knowledge coded in an expressive way.

That’s where us, as individuals, have the duty to act as professionals. Being professional requires discipline. The organizations still don’t understand us. Uncle Bob (Martin, 2016) has some good words about how to be a professional:

In particular, the business does not understand our disciplines (…), business doesn’t understand Pair Programming, doesn’t understand Test-Driven Development, doesn’t understand Refactoring, doesn’t understand Simple Design. These technical disciplines are not within the expertise of business.

And they shouldn’t be. They belong to us, its part of our tech expertise. So business can not approve or endorse them. You can’t go to the business and say “Is it ok if we write tests?”. (…) Because when you do that, what you are trying to do is to shed the risk, you are not willing to take the risk, you put it on the business, and the business can not evaluate that and take the risk. (…)

And the risk, frankly, is ours to take. We own that risk. That’s us. We are the ones who know the things that need to be tested, we are the ones who know the things that need to be refactored, we are the ones who know how to get software done and so we have to take the risk as part of our normal professional operation. As professionals. And that’s what professionals does: a professional take the risk on what they know what must be done.

Another professional responsibility we have is to understand the business domain in which we work:

(…) if programmers are not interested in the domain, they learn only what the application should do, not the principles behind it. Useful software can be built that way, but the project will never arrive at a point where powerful new features unfold as corollaries to older features. (Evans, 2003)

Uncle Bob and Eric Evans exposes deep economical implications. Our professionalism can be the difference between the business realizing the return on investment made in software development or having a software that’s just cost.

We can’t run away from our responsibilities: we have the duty, as professionals, as individuals, to never stop learning and to improve in our craft.

Informed and careful design

A software development approach that supports informed and careful design is Domain-Driven Design (DDD). DDD helps to implement the best software design from models that explicitly reflects the organization’s competencies. DDD helps to develop software that gives competitive advantage to the business because it forces the organization to understand where it must excel (Vernon, 2016).

DDD has strategic and tactical design tools to support the design activities in the organization/team intersection. The strategic design is about dividing the work that must be done and about finding what is strategically important to the business. In short, DDD is primarily about modeling a Ubiquitous Language in a Bounded Context (Vernon, 2016).

These tools are DDD’s cornerstones. Teams that adopts DDD speaks in a Ubiquitous Language that is spoken both by developers and by domain experts. This language is implemented the software model (that’s why it’s ubiquitous). The Contexts are used to constrain and clarify the vocabulary of this Language. They’re semantic boundaries. Inside a Context, each term has a specific meaning, which is understood by the team members.

The Contexts are the acknowledgement that the business’ domain is not only big and complex, but best managed by dividing it. The recommendation to assign a Context to a team, with a separate source code repository and database (Vernon, 2016) aligns perfectly with product’s teams organization. It is also a natural way to implement a Microservices architecture (Newman, 2014).

The resulting model from the strategic design is informed: the team acquired the needed information from the business to divide it in sub-domains, finding their Contexts and modelling the Ubiquitous Language.

The tactical design is a pattern catalog that helps to implement the model in code, with the goal to make the software an explicit reflection of the model. If my code is an explicit representation of the model that was created by the collective effort from the developers and domain experts, this code documents and centralizes the business’ knowledge. It’s careful design.

Continuous improvement as a design practice

Organizations and teams inter-relations are complex systems. Software development is a hard activity. Given these challenges, we create strategies to execute tjese design activities (organizational, team and code) to transform the organization.

However, a organizational transformation depends on people. They learn and change the organization (Soares, 2017). In software organizations, it is pretty common see people burned out with too much transformational activities, with multiple process being adopted in parallel.

This not only raise the risk of failure in the adoption and understading of the processes, this overburden causes morale issues in the team. With each new failure, the team desmotivates. Even with its best intentions and efforts, the new process failed. A thick fog of indifference and ressentiment appears.

Aiming to have fully DevOps teams is a nice starting point. DevOps, as a set of practices, has flow visualization amongst its principles. The Lean mindset and the Kanban Method are integrated into DevOps (Debois et al, 2016) and as mentioned previously, the creation of a continuous improvement culture.

The Kanban Method is designed to minimize the initial impact of changes and reduce resistance to adopting change. Adopting Kanban should change the culture of your organization and help it mature. If the adoption is done correcly, the organization will morpth into one that adopts change readily and becomes good at implementing changes and process improvements. (Anderson, 2010)

The strategy doesn’t matter, it is primordial to minimize the initial impact and resistance to changes to adopt a continuous improvement culture.

Design is innevitable

Questions about whether design is necessary or affordable are quite beside the point: design is inevitable. The alternative to good design is bad design, not no design at all. (Vernon, 2016)

Design being inevitable, we have the duty to design the organization, the teams and the code. There is no alternative, we need to do design. Better if informed and careful. What are we waiting to start?

References

  1. The idea is that the team can be fed with two pizzas. I believe, for now, that this is not an Amazon’s plan to raise the demand for pizzas by increasing the appetite of unsuspecting readers. ↩