Random Acts of Architecture

Tales of an architect trying to bring order to the chaos that is modern information technology.

Monthly Archives: May 2018

Toppling alpha developers

Building blocks

Many people are attracted to software development because they love technology and development. Viewing it more as a hobby they are paid to undertake, they gladly spend time outside work solving that nagging problem, mucking around with the newest framework, contributing to open source software or exploring opinions on Twitter.

There is a subset of software developers that takes this to extremes. It is possible for someone that does not “eat and breathe” code to still take pride in their work, to still be a craftsperson or to want to learn more and improve. However, alpha developers make software development part of their identity and their desire for respect drives them to competitiveness.

From a hiring organization’s perspective, these alpha software developers are wonderful. Their pride dictates they produce high-quality work, often at the expense of their personal time. Training costs are minimal because they already know or quickly assimilate new tools, frameworks or techniques. Their competitiveness can force everyone to produce and learn more. They are happy to leave business decisions to others and focus solely on the technical. While these all have downsides, successful companies have learned to temper them.

However, alpha software developers create barriers. Alpha developers’ pride compels them to take technical leadership roles and demand others live up to their standards. Their knowledge of new tools and techniques and almost overriding urge to try them out can shut out discussions of other solutions. For those less enamoured with software development, alpha developers can be intimidating.

When asked to train others, alpha developers feel that owning one’s technical development and career path is a rite of passage. It is not that they look down on people who know less, more that alpha developers made the effort to train themselves so why should others be given special treatment?

Meanwhile, alpha developers feel their performance is judged on their own output and helping others interferes with that. Indeed, alpha developers will work around other developers if they feel they have to “save the project” by rewriting others’ code or taking on others’ work out of impatience.

This problem is exacerbated when alpha developers move into leadership positions. When hiring new developers, they perceive alpha developers as superior and hire them over others. When evaluating others, they reward alpha qualities.

Focusing on alpha software developers creates a monoculture, focused inward on technical prowess and knowledge. Decisions need broad, representative viewpoints. While few companies will have ample members of the target audience on staff, few companies’ target audiences are solely alpha software developers.

This relegates non-alpha developers to permanent “junior” roles. This blocks their career progression even though they may be well suited to roles that software development feeds into like business analysis, user experience, consulting, quality assurance, IT administration or solution architecture.

This also risks the competitiveness between alpha developers boiling over to conflict or burnout. Like a sports teams, having too many ego-driven superstars creates problems. Teams work best with people in a variety of roles and software development is a team sport.

Solving a problem like this, particularly something a deeply ingrained in software development culture, is not simple.

The first reaction is to move away from using lines of code or other similarly easily measured metrics as the primary determinants of productivity to ones that indicate the success of the project. This encourages a team-centric view of productivity, not individual-centric.

However, the problem is deeper than that. Like using the term “craftsperson” instead of “craftsman” at the start of this post, we need specific language to drive specific thinking. It is hard to conceive of ways to drive value without terms to describe them.

For example, a “developer experience” engineer could focus on improving the efficiency of existing developers and hastening the onboarding of new developers. While documentation is part of this role, its focus is more on fixing inconsistent APIs, gathering useful diagnostics, ensuring error messages are complete and descriptive, replacing or fixing buggy libraries and improving internal tool reliability.

This role focuses on the productivity of other developers and understanding how they work instead of raw lines of code. This person should not get too involved in the internals of the software. Otherwise, he or she may start to overlook or forgive bad practices.

Another potential role is a “business process integration” engineer. Working on a lower level than a user experience engineer, they look at product customization, integrations and automation/orchestration opportunities. For internal systems, this could be about integrating the system into a Business Process Management (BPM) or workflow solution. For external systems, this is similar to a customer-facing solution architect but works with the code directly to help users customize or leverage the product.

This role requires an understanding of the broader business context, how software is used by the organization and what the organization views as important. It is a good conduit into business analysis or enterprise architecture.

This all boils down to a search for value. While focusing on software is what others would expect software developers to do, focusing it to the exclusion of some of the software development community is a poor strategy. We need to change how we view and measure our software developers and change who we see as aspirational.

Image from https://commons.wikimedia.org/wiki/File:Autism.jpg. Used under creative commons license.

Requirements and leadership, not design, are the keys to architecture

Listen Understand Act

Many IT engineers aspire to be architects. They want to dictate the course of their products or services, leading their fellow engineers. To do so, they focus on designing the best and largest systems, learning all about design patterns, notations and understanding technology from top-to-bottom.

However, if such a thing can be said to exist, even the best design is wasted if it does not solve the right problem. Architects should start here, instead.

Depending on the organization, requirements are often supplied by product management, business analysts or management. During requirements analysis, architect validation identifies ambiguities, omissions, estimated time and resource costs and likely tradeoffs. The resulting requirements and priorities may differ substantially from the original as trade-offs and discoveries are made.

Requirements often present the business understanding of what technology should do, not the most impactful or beneficial things technology can do. Architects are in the best place bridge the gap, driving technology from the bottom-up instead of the top-down.

Business-supplied requirements often lack quality attributes or non-functional requirements like availability, performance and security. These are either assumed or difficult for non-technical people to articulate and architects are the best equipped to specify these.

Architects need to listen more than they talk, learning as much as they can about the business context of their work and its business value. Drilling into requirements is a good start, helping to understand requirements’ context, assumptions and priorities. There is no point where an architect understands everything, only a process to continually learn.

While it is tempting for a newly appointed architect to focus on their pet technical problems, ensuring they have a good pipeline of requirements helps architects to align their efforts to solve others’ problems, not just the ones they perceive. They also need to ensure the business outcomes are met, not just the technical enhancemnts.

Looking at it another way, a design is not just a model (approximation) of the implementation. A design is the requirements for the implementation. Like requirements gathering, design is iterative and may change through the review or implementation process. Like requirements gathering, design is a trade-off. Like requirements gathering, it is an abstraction, leaving some details to implementers. If an architect cannot understand or provide good requirements, their designs are going to be misunderstood, at best, or ignored, at worst.

Moreover, architects are leaders. Not leaders in the management sense but leaders by collaboration, communication and example.

While the technical leadership of architects is well understood, good architects move out of their comfortable technical conversations and into the less comfortable business conversations. As mentioned above, some requirements sit between the technical and business and stakeholders need assurance the system will meet their needs. No design pattern or notation will achieve this.

Architects should focus on outcomes and end-to-end systems, not the minutiae of their designs, particularly in agile environments where just-in-time design occurs or where component responsibility is delegated to teams. Trusting implementors by giving them clear interfaces, scope and direction is the best way to foster their trust in architects.

Architects must own their communication. The responsibility for implementors and stakeholders understanding the design and vision rests with the architects. A design or vision that is not communicated is not understood and an architect producing designs no one understands has zero business value.

An architect must also facilitate communication between teams, particularly when design changes ripple through other teams’ work.

Architects must be accountable for systems they architect. They need to listen to implementors to understand their challenges and how to mitigate them in current or future designs. They need to accept criticism from stakeholders when requirements are not met. They also need to be applauded when their projects or systems succeed.

While designs are the architect’s deliverables in many projects, an architect’s success is driven by their ability to ensure they are solving the right problems and assure people of that direction. Good architects look down toward the technical detail and ensure it is correct. Great architects also look up and around to understand how they can best provide value to the business, sometimes better than the business can.

Image from https://www.flickr.com/photos/highersights/6231641551. Used under creative commons license.

%d bloggers like this: