Random Acts of Architecture

Wisdom for the IT professional, focusing on chaos that is IT systems and architecture.

Tag Archives: Innovation

Adapting Software: A Case for Generalists

Leave a comment Posted by on September 26, 2022
Colourized Photo of Charles Darwin

Developing and improving software or IT services is challenging. With change the only constant and competition fierce, organizations often live and die by their ability to adapt.

Unfortunately, most organizations are not structured to adapt quickly. Many fool themselves with superficial agile practices without building any real understanding. Some hire external consultants whose benefit ends with their consulting engagement. Others undergo discrete transformations, unaware that adaptation is continuous.

I find it helpful to think of software or IT services requiring three primary foci.

The first is automation. Usually fulfilled by software developers, this is what most people think of with software or IT services.

The second is knowing the customer. For example, an IT service targeting health may need to understand how doctors or clinicians work. A network management service requires understanding routers, networking and network security.

Multi-sided markets may require understanding multiple customer types. Uber, for example, requires understanding both passengers and drivers.

The third is providing the service. This focus includes onboarding/offboarding, billing, service desk/support, security and scalability/performance. Multiple roles within an organization often handle these.

The challenge with most organizations, and a significant reason they have difficulty adapting, is they hire specialists for each focus. Software developers, for example, are usually hired solely for their ability to write software.

Unfortunately, understanding one focus can only take you so far. For example, if you only understand the customer, you risk creating an uneconomical or impractical service. If you only understand automation, you risk automating things of little value. If you do not understand delivering a service, you will struggle to provide one efficiently and economically.

There are exceptions. Product Management is often familiar with the customer (second focus) and providing a service (third). They understand the economics and finances. However, they often distance themselves from automation to prevent a bias toward what their existing services can easily provide.

Management also absorbs a little of all three foci. However, their understanding is often shallow. Their attention is usually broader than just product improvement.

The solution is to identify and then incentivize specific staff to generalize across all three foci. They need to learn enough of each to (1) understand the impacts of a decision or change in one focus on the other foci and (2) identify when opportunities in one can provide a nett benefit.

By comparison, separate individuals struggle with this, even those who communicate well. We often think we know more about others’ roles and needs than we actually do. There is a “critical mass” of understanding that these generalists need to achieve.

The concept of hiring generalists or “T-shaped” skills is not new. However, this usually applies within one of the foci. For example, software developer generalists are often “full stack” developers, not ones familiar with non-technical areas.

Finding generalists is difficult. Each business is different and has different needs. While many universities offer combined IT and business degrees, they usually produce IT management candidates. While some universities provide mixed degrees, they often neglect the third focus on effective service delivery.

Similarly, many want to specialize and master their chosen craft. It is a better understood and measured career trajectory.

Importantly, these generalists do not replace specialists. Organizations need sufficient specialists to deliver each focus.

However, the best generalist candidates demonstrate interest or passion across all three areas. Submerge them in each focus, challenge them to translate the challenges and benefits of each and then task them with identifying bottlenecks and potential improvements.

One of the first hurdles they usually encounter is management structures. Organizations are usually built around similar skills, not business output. Organizations usually incentivize teams or departments around cost minimization and throughput, not customer value.

However, with executive support, creating and supporting these generalists will break down barriers and help the organization adapt quickly. Without doing so, organizations will stagnate, often too siloed or distracted by short-term problems.

Charles Darwin was right. Natural selection applies to organizations, too. Those that cannot adapt will be replaced by those that can.

Architecture, Op-Ed , , ,

What makes a “good” software developer?

6 Comments Posted by on June 7, 2013

Good Software DeveloperSpend any with software developers and the question of whether a software developer is “good” has invariably arisen. Want to hire a new software developer? Want to promote someone to a lead developer position? Need someone to refactor or redevelop a piece of code? Need someone to work with a different team? You always want a “good” software developer. The challenge is “good” has many different meanings and few can be more specific. What does “good software developer” actually mean?

The first skill of a “good” software developer is delivery: writing code quickly with as few bugs as possible. Some software developers are faster than others, some create slightly more bugs than others but the balance should be there.

The second skill is product knowledge: knowing where to fix or improve something, the rationale for the current design and impacts of any change – often the hardest parts of software development. This includes the technical ecosystem (what products it integrates or interacts with and how).

This list excludes skills like communication and building a network of contacts. They are important but are not software development specific.

This list also excludes business knowledge because most software developer “business knowledge” is just product knowledge. Software developers with business knowledge exist and some product owners lack the business knowledge they should have. However, few software developers can step into a non-technical role and perform as well or better than someone hired specifically for the role.

Both delivery and product knowledge provide strong business value. However, does that mean the best software developers are those that have worked on the product the longest? Is “good” synonymous with “experience”?

Similarly, with little design up front, regular pivots, increased visibility and pressure to deliver, Agile practices tend to encourage finding the minimal effort to solve a given problem. The constant focus on delivery may dissuade developers from stepping out of their immediate task and learning how to improve themselves, their process and their team.

Consequently, there are other skills to consider. For example, optimizers examine a process or product, identify its deficiencies and make concrete improvements. Epitomized by Sam Saffron’s recent post, these developers excel at improving nonfunctional aspects (e.g. performance, scalability, security, usability) or automation (e.g. build process). These are the developers constantly pushing for new tools and libraries because they are better, not just because they are shiny and new.

Software developers may also focus on good design. For new products or features, designers focus on how the software works as much as what it does and usually head for the whiteboard first and not an IDE. For established products, designers seek technical debt, fix it and move to the next problem.

Software developers may also be quality-focused. Quality-focused developers consider code incomplete until it is both testable and has automated tests. They often espouse the benefits of Test Driven Development (TDD) and code coverage (an imperfect but useful metric) not necessarily for themselves but as easy ways to encourage (or require) others to focus on quality.

This list is also hardly conclusive. Some software developers may focus on security, others on user interface design and so on.

Optimizers, designers and quality-focused software developers are disruptive and may detract from delivery by focusing too much on improvement. For example, they may spend too much time and effort on switching tools, redesign and over testing. The disruption may extend outside the development team, too. For example, new processes may impact other areas of the business and purchasing new tools may put pressure on budgets.

However, these disruptive developers can drive positive change and be a source of innovation. Without them, software developers would still be writing code in assembler using waterfall processes on computers that filled buildings.

The first consideration is focusing disruptive software developers on important problems, often difficult for managers not used to software developers driving initiatives from the ground up. Changes must be driven to completion and implementation and not just the initial research and proof of concept. Managers also need to make sure all team members can follow and benefit from the improvements, not just team members driving changes.

The second consideration is managing expectations. A disruptive developer brought into the team may expect or be expected to drive change. Setting boundaries and goals beforehand can avoid problems before they occur.

However, having the skills mentioned above is not necessarily the best answer to “What makes a good software developer?”. Yes, “good” software developers deliver and amass product knowledge. Some software developers are disruptive and those that drive improvements while delivering may be “great” software developers. However, these are goals. How does a software developer become “good” or “great”?

Great software developers strive for continual improvement. If a software developer truly wants to improve, reads widely, experiments and keeps what works then even a “poor” software developer will become “good” or “great” eventually.

Continual improvement is often mentioned when discussing Agile development processes but it also applies down to the individual level, such as scripts, key bindings, macros or IDE add-ins. It also applies to the organization level, although this is harder for individual software developers to influence.

To look at it another way, great software developers focus on goals and motivations , not just rituals. A good developer may follow Test Driven Development or the SOLID principles but a great developer will know the benefits they bring and when to bend the rules. This is also why great developers learn new languages quickly and apply concepts from one in others.

That said, choosing a great developer is not always the best choice for every role or task. Great developers expect more from an organization. This is not just a higher salary and benefits. They expect to make more of an impact but not every organization can provide or allow that.

The key is to match the software developer to the task, not just find a “good” or even “great” software developer. This requires understanding what the team needs and how developers improve or lose their edge over time, which requires “good” management. However, that is a whole other blog post.

Software Development , , , , , , , , , ,

The Other Side of Software Architect Innovation

2 Comments Posted by on January 14, 2012
As stated previously in this blog, software architects must be innovators. They are responsible for creating a technical vision to apply new technologies to further the customers’ goals and/or reduce development costs and for high level designs. Many books, lectures, blogs and so on describe the process of innovation and are not repeated here but, when confronted with a problem, most developers and architects either work out their own solution or lazily Google something similar. However, software developers and architects, in particular, need not “reinvent the wheel”.
 
Ignoring structured learning, such as degrees and certificates, there are two ways architects can learn ways others do things. The first is to proactively listen for new information.Most software architects will already read favourite blogs or web sites, follow twitter luminaries, subscribe to magazines, read textbooks, attend conventions and so on. However, the key with information sources is efficiency – five sources providing predominantly relevant information is better than one hundred poor sources.
 
Aim for a mix of information sources, including some technical, some design, some industry commentary and some aggregators (those that provide interesting links to other sources that may only occasionally have relevant information). Review sources over time because the architect’s requirements, knowledge and expectations will change over time. Experiment with new things and plan to either remove “old favorites” or check them less often when they are no longer being consistently useful.
 
The second is to research topics when the need arises. Competitor’s products are good places to start but, unless this is a major feature, information is often sparse. Internet searches or dedicated development sites are useful but iterating synonyms is time-consuming.
 
Software architects often neglect academic texts or papers, which are particularly useful if the group is using more complex algorithms. Use Google Scholar or consider joining ACM or IEEE to access their academic paper repositories. Such papers may be dry or assume too much knowledge initially but persisting may reveal better approaches, establish common terminology and point out less explored areas suitable for potential patents or the architect’s own academic papers if he or she is so inclined.
 
Some would recommend looking at open source software. Assuming the product is chosen with care, open source software or other people’s code in general is a great source of information from obscure language features to new algorithms. However, the software architect must not copy any code verbatim or infringe patents or licenses.
 
If the problem is not solved or not solved sufficiently by prior art and the organization has a process in place, software architects should create and file patents. Arguments over whether software patents encourage or discourage innovation are irrelevant. As they say, “You cannot win the game from the sideline”. The IT industry is pursuing patents aggressively and companies that do not, such as Google with Android, now face legal challenges and hurdles. For the software architects, patents are one of the few peer-reviewed, universally available measures of creativity available. Many organizations also offer financial incentives for them, too.
 
Beyond the software architect’s products and patents, avenues for innovation include open source software, apps in app stores, writing a technical blog, conferences or academic papers. Approval may be required from the organization and social networking activity will need to comply with the organization’s policy but this can help the software architect’s personal brand and help find or precipitate conversations with like-minded individuals.
 
The single most important thing about innovation is to start. A software architect must be a technical leader but cannot lead without producing and cannot produce without starting. The first attempts may be unremarkable or unsuccessful but persistence will bear fruit.
Software Architecture , , , ,

Creating an Innovative Environment

1 Comment Posted by on January 9, 2012
“Innovation” appears to have joined words like “synergy” in the buzzword nomenclature but is central to a software architect’s role, whether it be creating and driving either customer impacting or cost saving innovations. Unfortunately, many software architects and developers get frustrated when new ideas, features and improvements continuously are ignored, pushed to a nebulous future release or get anemic implementations. Innovation needs an environment and culture that allows it to succeed.
 
Many organizations feel that the greatest barrier to innovation is time. After all, many software development organizations are known for time specifically devoted to innovation. Google, for example, has “Google Time” where all employees spend a day a week working on their own projects. Atlassian, an oft quoted example, has “FedEx” days  where all the development staff spend 24 hours on their own projects and present them to the group afterwards. In both cases, this is where many new products or product features originate.
 
Unfortunately, organizations focusing solely on the time allocate it, expect developers to produce wonderful, insightful and customer worthy new products and features then scrap the exercise after initial disappointments or during the next crunch time. These organizations miss three important points.
 
First, these organizations put ideas created by developers (not just product management and support issues) into their product. This means that developers need the communication and exposure to customers or be customers themselves. Atlassian writes software for developers and they use their own products (or “Eat their own dogfood” as many people say) as does Google but most organizations lack this luxury. Software architects and developers need to create communication channels where they can get this information time efficiently. For example, start with requiring developers to use the product for basic tasks when they first join the team then periodically do manual testing in realistic environments (in addition to that done by QA) and have regular lunches with support.
 
Ideally, have architects and senior developers talk with customers directly, such as attending a support call or a conference. Development teams often receive a skewed view of the product consisting of support incidents and requirements from a few important, vocal customers only. Developers and architects ask different questions than non-technical people and hear the same answers with different ears. Even simple act of architects and developers watching customers use the product can reveal incorrect UI assumptions.
 
Build opt-in telemetry into the product, too. Two of the biggest issues with successful innovation are the self-supporting bias, where people over-estimate their own contributions to successes and under-estimate their part in failures, and the confirmation bias, where people interpret facts to support their own existing conclusions. Telemetry does not replace product management’s vision or support’s intuition but effective telemetry provides the most accurate information about what features are used, how often by when and by whom, particularly during A/B testing.
 
Second, innovative organizations have easily extensible or modifiable products, usually by people outside the development team responsible for that feature. No commercial software is ever perfect but the biggest hurdle to innovation execution is getting product quality to a manageable level and stopping endless “fire fighting”. This is particularly difficult on products with a small, maintenance staff or those with overly ambitious deadlines and usually requires extensive automated unit testing, refactoring, documentation and possibly new tools.
 
The team must also have room in the backlog (scheduled modifications or enhancements, some beyond the current release, for those unfamiliar with the agile term). Even brilliant ideas will have difficulty competing if the team has years of work outstanding or over-committed to customers. The team needs to focus, create a more effective and transparent prioritization mechanism and reign in the sales organization.
 
Third, innovation, when it occurs, must also be communicated and shared. If only the immediate manager knows about it, much of its value is lost. Similarly, innovation must be expected and rewarded with goals set, tracked and judged like other performance goals.
 
Software architects and development are not the only source of innovation, either. The best customer impacting innovations come from those that understand both the customer and the technology or product. Software architects are in a prime position to drive product and technology information to others that may innovate such as technical product management, professional services, support leads, architects from other products.
 
Software architects and developers must take responsibility to drive change throughout their organization. Organizations’ inertia often makes this a challenge but innovation does not spontaneously occur in a vacuum. As usual, start small, advertise successes and persist.
Software Architecture , , , , , , , ,

%d bloggers like this: