Random Acts of Architecture

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

Monthly Archives: October 2012

A Clash of Development Cultures

Software developers often consider themselves perfectly rational. After all, their jobs consist of programming deterministic, rational machines (computers). However, anyone who has worked with developers realises this is completely untrue. In particular, leaders that direct or influence different groups of developers need to understand what motivates them, especially the more vocal and influential developers and technical leads.

There are two types of influential developers. The first are the “craftsmen” (or the gender non-specific “craftspeople”). Craftsmen are motivated by the respect of their peers and want to be known as “good” developers. Craftsmen tend to:

  • Want to work with cutting edge tools, such as the latest version of an IDE or library, and techniques, such as agile development methodologies.
  • Think “good” code not only satisfies the requirements but is clear, maintainable and is an example to others. They are more likely to refactor code, follow (or create) coding  style guidelines and create automated tests, particularly when they have advance warning their code is going to be reviewed.
  • Thoroughly research and experiment with different ways of solving a problem. They are often critical of designs or direction from others, particularly those removed form the code.
  • Prefer a more egalitarian, flatter management and team structure. They are happy to work in a group of peers, each with their own area of responsibility.
  • Code in their spare time, discuss technical issues over lunch and read or write technical blogs. They hold examples of collaboration, such as open source software, in high regard. They tend to look past certifications and degrees to focus on what was studied or produced.
  • Hold technical opinions strongly. They may argue weakly because they feel their points are “obvious”.
  • Be more common in western cultures like in the US, UK and Australia.

The second are “success-oriented“. They see software development as a relatively well paid and respected stepping stone, usually to management.  They tend to:

  • Prefer familiar tools and techniques, so long as they are well compensated and have promotion opportunities.
  • Think “good” code meets requirements. Other facts are less important.
  • Seek help for problems when there is no immediate, obvious solution.
  • Look to seniority or management for guidance and direction. Indeed, if they are in a senior position, they will often demand the right to design or give direction.
  • Respect and seek “authoritative” measures of achievement such as degrees, certifications and training. The goal is usually to decrease the time to the next promotion, enter the industry at a higher position or be paid more.
  • Hold technical opinions weakly. They may argue strongly because it their training and education emphasized it.
  • Be more common in eastern cultures like in India and China.

Clearly, these groups are not well-defined or mutually exclusive and are generalizations. Craftsmen still want promotions and pay rises. Success-oriented developers may still be interested in technology. They key difference is that the software written by craftsmen is part of their identity so they work to make it as good as they can. They grok languages rather than just learn them.

Craftsmen are not better developers than success-oriented developers and vice versa. For example, craftsman may get distracted by perfectionism or experiments but may drive the organization to newer and (hopefully) better processes. On the other hand, success-oriented developers often use well-understood paths to complete tasks sooner and are happy to maintain older software using older tools.

Success-oriented developers are not more likely to provide business value than craftsmen. Although success-oriented developers are less dismissive of non-technical users and focus more on pleasing management, they commonly implement the requirements verbatim without additional understanding.

Although team composition and work assignment are often the domain of team leaders and management, it benefits everyone in the team to understand others’ motivations. For example, pointing out a better solution to success-oriented developers may frustrate them since their solution is no longer “successful” and requires additional work. Point out the simplicity, time-saving aspects of the new solution or how marketable the new skills required are to motivate or influence success-oriented developers. By comparison, pointing out a better solution to craftsmen may embarrass or make them feel threatened. Point to relevant code, articles or recommendations of industry thought leaders to motivate or influence craftsmen.

Also be aware the type of developer when soliciting feedback. Craftsmen generally give better feedback. Many success-oriented developers are happy to be directed by those more senior or want to direct those they perceive as junior. That said, craftsmen are likely to push newer designs and techniques while success-oriented developers look at things in the context of existing practises.

Moreover, having both developer types working together without self-awareness can create friction, such as when a success-oriented senior developer or manager asserts authority over a craftsman developer pushing what he or she considers a better solution, perhaps backed up by blogs or articles. Outsourcing or mergers/acquisitions often cause or exacerbate this.

The challenge is that developers have weak soft skills and many consider meetings and discussions unproductive time. They rarely focus on interacting with each other, sometimes oblivious to the problems it creates. Unfortunately, developers are not perfectly rational but understanding their motivations can solve common problems or avoid them completely.

(Thanks to Bryan O’Donovan for the helpful review and comments.)

Developer to Architect: A Matter of Perspective

When interviewed for a promotion some time ago, the interviewer told me two developers are arguing over whether to use programming language A or B for a project and asked me which I would recommend.

There are different ways to answer the question. The first is technical, comparing the language minutiae, libraries, IDEs and tool support. It argues the merits of the vendors, communities behind the languages and often has a bias toward favourite languages or tools.

Team leaders and managers approach the problem differently. They look at the existing skills of the team. They look at support structures (such as contracts and consultants), the longer term viability of languages and their organization’s investments in each. They consider the risks and benefits.

I gave both these answers. While correct, these answers miss a critical viewpoint: customer benefit. For example, the product may have to integrate with existing applications using mechanisms only supported by or heavily geared toward certain languages, like COM with C++, Visual Basic or C#. The target device or operating system may support one primary language, such as iOS and Objective-C. Languages may have runtimes that require additional configuration and patching, such as Java or Flash, and the customer lacks the infrastructure and expertise.

Customer benefit is an assumption so implicit in the question that people consider it assumed or ignore it. However, this assumption is what makes the question a great (trick) question, particularly for a software architect that needs to interpret, challenge and identify requirements.

“We do not see things as they are. We see them as we are.” Talmud

Moving from a developer to an architect involves a change in perspective. Developers leap to details with the “how”, arguing libraries or techniques. Managers identify resource requirements and risk. Architects step back and ask “Is this even the right question?”

“Nothing is more dangerous than an idea if it’s the only one you have.” Emil-Auguste Chartier

Thinking inside the box is easy. Thinking outside the box is hard. Finding the box is harder still. Architects may specialize but are expected to delve into enough detail to validate a proposed solution without risking leaping to conclusions or becoming too attached to a solution. Developers focus on the best and fastest way to solve a given problem.

“The limits of my language is the limit of my world” Ludwig Wittgenstein.

Design patterns are useful for conceptualizing and communicating designs. Understanding the business problem and customer viewpoint is critical to identifying the best solutions. Architects straddle both the developer and customer worlds and so must learn the terminology of both and translate concepts between them.

“It takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!” Lewis Carroll

It is an understatement to say technology changes rapidly. Whereas developers must keep up with their chosen tools and languages in detail, architects evaluate and adapt to a wider set of technologies but less deeply than a developer, particularly those architects responsible for a technical strategy or vision.

“It is a painful thing to look at your own trouble and know that you yourself and no one else has made it.” Sophocles

Architects are responsible for the product without being the ones implementing it, including design delegated to others and trade-offs  made to handle  technical or business constraints, and their role is as much communication and evangelism as high level design. Managers have long been accustomed to this level of responsibility and facilitation but it may be new to a developer.

Of course, this is not to say a developer cannot think like an architect or manager (or other permutations) or that these are immutable, defined roles. Like Edward de Bono’s Six Hats, recognizing that there are different viewpoints and switching between them is key. It is also challenging, particularly when under the pressures of commercial software development. Or an interview.

%d bloggers like this: