So what should an “agile” software architect be doing?

“As architects, you have the opportunity to create spaces that inspire, uplift, and bring people together.”

“An agile architect in his natural habitat dancing in a field of complexity…”

I recently wrote a blog on whether software architects matter. The blog was written quickly and without much consideration, which sparked discussions among my professional network, particularly among architects. Many of these discussions focused on the role of an “agile” software architect. My suggestion that most design decisions be made by the team appeared to be the trigger point for these discussions. In light of this, I have compiled a list of things that I believe “agile” software architects should be doing:

Be part of the development team – You are there to inform, motivate, and influence the team without expending social capital by forcing your decisions. Being removed from the actual development effort and simply flinging architectural documents (that probably don’t reflect actual system code) at developers is not good enough anymore.

Adapt to the team’s way of working – Not the other way around. In order to build high-performance teams, you need to create space for autonomy, mastery, and purpose. The autonomy boundary can be constrained, but each team’s sweet spot in terms of their way of working will differ slightly. Standardizing your approach will simply lack the flexibility and variability that modern teams need and require.

Your job is to accelerate the project, not to slow it down – Your goal is to keep the project moving forward and avoid slowing it down. Be flexible and willing to change priorities, discard unnecessary requirements, and experiment with new ideas. Above all, keep the flow of value creation going. Don’t get stuck trying to understand or gain consensus on every detail. Instead, defer decision-making as long as possible and focus on the high-risk areas that could derail your design. This will help you avoid becoming a bottleneck in the development process

Your job is primarily about communication; do it often and early – Keep the lines of communication open and start early. It can be difficult to achieve a shared understanding among all project stakeholders, but transparency and simplicity can help. Avoid complicated diagrams and strive to provide context and understanding. Repeat key points until a common understanding is reached and people start taking initiative. Then, simply curate and ensure accuracy without stifling people’s attempts to contextualize the information.

Focus on the essence of the problem, the simpler the better – Stop creating artefacts, documents, and stuff that nobody can contextualize. Even if you have to explain things over and over again, this will refine the concept in your head and provide extra insights. Look at initiatives like C4 diagrams to get your drawings more in line with the actual thing being built.

Test your architecture – Prototypes and POCs are single-handedly the best way to validate parts of your architecture. But in too many organizations, this is seen as a waste of time and money. Change the way you fund projects and cater for this activity. While you are at it, always add slack for testing the non-functionals of your architecture (scalability, performance, and robustness).

Question standard practices and seek out new ideas – Don’t be afraid to challenge the status quo and seek out new ideas and approaches. The world of software development is constantly evolving, and it is important for architects to stay current and adapt to new methodologies and technologies. This will help you to stay relevant and effective in your role.

In conclusion, the role of the agile architect is to be an active and influential member of the development team, adapt to the team’s way of working, accelerate the project, communicate effectively, focus on the essence of the problem, test the architecture, and seek out new ideas. By following these principles, you can help your team to build better software and achieve greater success.

Advertisement

Do software architects matter?

“In order to be effective, the role of the software architect should be closely tied to the act of coding.”

One of the most problematic versions of this role is when someone without a technical background starts making pronouncements about architecture and is labelled as an architect…

The role of the software architect in software development is an important one, but it is often misunderstood and can be problematic if not approached correctly. The term “software architect” often conjures up images of a senior engineer who has mastered their craft and no longer needs to engage in the mundane task of coding. They sit in their ivory tower, making grand pronouncements about how software should be built and then bemoaning the inability of others to execute their vision.

However, this approach is misguided and can lead to a number of problems. For one, it creates a disconnect between the design and the implementation, which can result in unrealistic expectations and poor decision-making. Additionally, it can foster a lack of ownership and responsibility among the development team, leading to subpar results.

In order to be effective, the role of the software architect should be closely tied to the act of coding. This means that there should be no distinction between architecture and coding – it should be a shared concern of the autonomous team building a system collaboratively. This approach allows for a more well-rounded understanding of the design, as well as fostering a sense of ownership and responsibility among the entire team.

Of course, it’s helpful to be able to articulate architecture and the impacts of technical decisions in a way that non-technical people can understand. But this is a skill that every technologist should strive to perfect, not just those who carry the title of “architect.” Clear communication is essential for ensuring that all stakeholders have a shared understanding of the design and its implications.

One of the most problematic versions of this role is when someone without a technical background starts making pronouncements about architecture and is labelled as an architect. They are likely to be completely unaware of the subtleties of technology frameworks and the practicalities of building coherent software systems. This can lead to unrealistic expectations and poor decision-making. Yet, these individuals are common in corporate environments.

So, what is architecture, if anything at all? Martin Fowler’s view is that if there is such a thing as architecture, it is about creating a shared understanding within your team and investigating and answering the things in your project that will be hard to change in the future. The rest can be left to your capable and trusted development team. By focusing on collaboration and clear communication, the role of the software architect can be valuable in ensuring the success of a software project, provided is rooted in authentic knowledge.

The Silent Devastation Caused by “Ideas People”

“Generating ideas is not a special talent reserved for a select few people who have been blessed with some kind of mystical ability to predict the future.”

Behold the unicorn ideas person. Full of ideas and low on execution.

In the software industry, you often come across individuals who are referred to as “ideas people.” These are people who are always talking about the big ideas they are “working” on. They might even insinuate how groundbreaking their idea is and how it’s going to change the world. These individuals often have a seemingly endless supply of ideas and can quickly switch between them, talking about each one with equal enthusiasm. If someone else in the industry has had success with an idea that resembles one of theirs, they may lament the fact that they didn’t pursue it and blame external circumstances for their failure. They may hold onto these ideas for years, waiting for the perfect moment to put them into action.

The worst part is that their passion for their ideas is often mistaken for genuine vision. Some people may be fooled into thinking that these individuals are true visionaries, and they may even receive funding from investors who are taken in by their rhetoric. When these ideas fail (which is most of the time), the ideas people typically blame external factors for the failure. They may say that the market wasn’t ready for their product or that the investor funds ran out just before they were about to make a breakthrough. If they are not technically inclined, they may blame the developers for being too slow, too expensive, or too inexperienced. It’s rare for them to take responsibility for the failure of their ideas or to admit that their ideas were flawed. To do so would damage their egos, which are often the only things they hold dear.

In reality, there is nothing more useless in this world than an “ideas person.” Not only is it frustrating to deal with their egos and their misplaced protection of their ideas, but anyone can come up with ideas. Generating ideas is not a special talent reserved for a select few people who have been blessed with some kind of mystical ability to predict the future. In fact, if you look closely at the ideas that ideas people come up with, you will realize that they are often nothing more than imitations of innovation, with concepts copied from the successes of others.

True visionaries are not just dreamers, they are also doers. Dreaming is an important part of being a visionary, but you also need to be able to follow through and make things happen. Ideas without execution are meaningless and a waste of everyone’s time. Execution is king.

The devastation caused by ideas people is particularly pronounced in the corporate world, where these individuals can operate with minimal risk to their livelihoods or reputations. If their half-baked ideas fail in a corporate environment, it’s virtually impossible to determine the cause of the failure because there are so many factors that could have contributed to it. As a result, ideas people can often escape blame for the failure of their ideas.

In contrast, the startup world does a better job of separating the doers from the ideas people. In startups, execution is everything. There is no room for ideas without action. If you can’t build something that is useful to humanity and that people want to use, you’re done. It’s a brutal environment that rewards true visionaries who can execute their ideas and destroys those who are just in it for the sound of their own voices.

The difficult part is that you want to encourage innovation and experimentation in corporate environments to help the company evolve and grow. However, the people who are typically tasked with coming up with these strategies and product ideas are often not well-suited to executing them.

Project Delays: Why Corporate Companies Struggle with Accurate Estimation

“‘The creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” – Bollinger, T

At the heart of this problem lies the phenomenon of discovered complexity.

Accurate estimation is one of the biggest challenges in software development. It’s a problem that has plagued the industry since its inception, and it’s one that elicits strong opinions from everyone involved in a project.

Every company has its own collection of horror stories about projects that have slipped catastrophically or seem to perpetually overrun their budgets and timelines. These delays can result in lost jobs, damaged careers, and, most importantly, destroyed relationships.

For some companies, this is such a common occurrence that the destruction caused by poor estimation has become the norm rather than the exception. In these environments, the trust between business and technology may be so eroded that any attempt at coming up with reasonable project estimates is regularly abandoned.

Instead, these companies are bombarded with unrealistic business demands that are labelled as “critical deliverables,” even though they are based on no quantifiable reality of effort. These “immovable” business targets are often arbitrarily tied to people’s KPIs, even before the feasibility of the work is explored. The recipients of these KPIs are typically people with no experience in software estimation and no understanding of the differences between an estimate, a target, and a goal.

At the heart of this problem lies the phenomenon of “discovered complexity.” For some reason, people view software development as a mechanical task similar to an assembly line in a factory. However, as research has shown (even mathematically), “the creation of genuinely new software has far more in common with developing a new theory of physics than it does with producing cars or watches on an assembly line.” In other words, software development is a creative process that requires a lot of thinking about unknown problems that constantly arise. These “accidentally discovered” problems can lead to more subtle and indirect problems that also need to be solved. This is called “accidentally discovered complexity.”

In simpler terms, at any given point in time, you don’t know what you don’t know yet, and there’s no way to predict how long it will take to figure it out when you do discover it. In this world, how can you accurately estimate how long something will take? At best, you can make a reasonable guess based on the information you have at that moment. But even this is problematic because the information you have about the problem domain changes and develops as the project progresses.

Given this, it seems virtually impossible to accurately estimate these creative tasks. Therefore, it’s essential to follow an iterative development methodology that includes a constant feedback loop for estimates. If you’re not continually re-estimating how long a piece of work will take based on all the new information you learn, you’re putting your project, and more importantly, your organizational goals and commitments, at risk. Do that often enough, and you’ll see the consequences unfold.

The learned helplessness of corporate companies

“In a nutshell, the experiment involved exposing dogs to controlled electric shocks in a confined space.”

It is really hard not to become despondent in bureaucratic organizations

One of the most common and destructive phenomena in bureaucratic organizations is the concept of learned helplessness. This term was first coined by Martin Seligman and his colleagues in their research on classical conditioning in the 1960s. In a nutshell, the experiment involved exposing dogs to controlled electric shocks in a confined space. The negative conditioning of the shocks eventually led the dogs to avoid seeking potential escape, even when the chamber was altered and an obvious exit was presented. This phenomenon is known as learned helplessness, and it can have devastating effects on individuals and organizations.

In many corporate environments, the negative effects of learned helplessness can be seen all too clearly. There are often too many people working in heavily regulated industries, using outdated and ineffective methods, and organized into hierarchical teams that stifle creativity and innovation. In such environments, even small attempts to deviate from the norm can be met with resistance and obstacles from self-proclaimed guardians of the status quo. The go-to argument in these cases is often governance and regulation, which are used as excuses for inaction and a lack of accountability for real change.

This self-imposed learned helplessness is often passed on from one team to another, and from one culture to another, until the majority of the organization becomes trapped in a cycle of feeling powerless and unable to break free from the safety of their constant suffering. It is no wonder that many individuals in these environments lose hope and become despondent.

One of the biggest dangers of learned helplessness is the way it can be exploited by those who seek to gain political advantage. These individuals often exaggerate the implications of self-imposed governance policies, creating artificial urgency and forcing people to work beyond their limits for the benefit of a few. In the process, employee well-being is frequently sacrificed, and any hope of creating a psychologically safe and caring environment is destroyed.

In conclusion, all leaders face constraints, and it is not always possible to challenge them. However, true leaders are able to differentiate between the constraints that must be accepted and those that can be challenged. They also show their employees that it is okay to go against the grain and that they will be supported in doing so. By encouraging creativity and innovation, and by fostering a culture of accountability and empowerment, leaders can help their employees break free from the cycle of learned helplessness and create a more positive and productive environment.