Author: Ben Linders

DevOps streamlines software development with automation and collaboration between development and IT teams for efficient delivery. According to Nedko Hristov, testers’ curiosity, adaptability, and willingness to learn make them suited for DevOps. Failures can be approached with a constructive mindset; they provide growth opportunities, leading to improved skills and practices.

Nedko Hristov shared his experiences with DevOps as a quality assurance engineer at QA Challenge Accepted.

DevOps by definition is streamlining software development by automating and integrating tasks between development and IT operations teams, Hristov said. It fosters communication, collaboration, and shared responsibility for faster, more efficient software delivery and integration.

Hristov mentioned that DevOps is not typically an entry-level role. It requires a strong foundation in software development practices, including how software is designed, built, and tested. Fortunately, software quality engineers or software testers often possess this foundational knowledge, as he explained:

We understand the software development lifecycle and many of us have expertise in automation. This background allows us to quickly grasp the core concepts of DevOps.

While software testers may not have deep expertise in every technology used in a DevOps environment, they are familiar with the most common ones, Hristov said. They understand coding principles, deployment processes, and system architectures at a high level. He mentioned that this broad understanding is incredibly valuable for applying DevOps.

Software testers are often inherently curious, Hristov said. They are driven to learn and expand their knowledge base:

When I first became interested in DevOps, I proactively sought out developers to understand the intricacies of their work. I asked questions about system behavior, troubleshooting techniques, and the underlying causes of failures.

Software testers can leverage their existing skills, their inherent curiosity, and a proactive approach to learning to successfully transition into and thrive in DevOps roles, as Hristov explained.

One of the most crucial skills I’ve gained is adaptability. In the ever-evolving tech landscape, we constantly encounter new technologies. This involves identifying key concepts, finding practical examples, and focusing on acquiring the knowledge necessary for the task at hand.

A strong foundation in core technologies is essential, Hristov mentioned. This doesn’t necessitate deep expertise in every domain, but rather a solid understanding of fundamental principles, he added.

Failures provide invaluable opportunities for growth and deeper understanding, Hristov said. While it’s true that failures are not desirable, it’s crucial to approach them with a constructive mindset:

I consistently emphasize to those I mentor that failure is not inherently negative. Our professional development is fundamentally based on experience, and failures are among the most effective teachers.

Failures are essential stepping stones towards enhanced comprehension and improved working practices, Hristov said. They are not inherently good or bad, but rather mandatory components of growth, he concluded.

InfoQ interviewed Nedko Hristov about what he learned from applying DevOps as a software tester.

InfoQ: What skills did you develop and how did you develop them?

Nedko Hristov: My skill development is driven by a combination of adaptability, focused learning, effective communication, practical application, and knowledge sharing.

I’ve honed my communication skills, particularly the ability to ask effective questions. This is often overlooked, but crucial for knowledge acquisition.

When approaching a new technology I usually ask myself a ton of questions:

• What is the core purpose of this technology?
• What problem does it solve?
• How does it work, what are the underlying mechanisms and architecture?
• How can I integrate it into my current projects, tooling, and workflows?
• Are there any best practices or recommended patterns for using it?
• What are the common challenges or pitfalls associated with this technology?
• How does this technology compare to its alternatives?

InfoQ: What’s your approach to failures?

Hristov: When encountering a failure, we should ask ourselves three key questions:

• What happened – Objectively analyze the events leading to the failure
• Why it happened – Identify the root cause and contributing factors
• What is my takeaway – Determine the lessons learned and how to apply them in the future

The key is to extract valuable takeaways from each failure, ensuring that we approach similar situations with greater knowledge and preparedness in the future.

InfoQ: What have you learned, what would you do differently if you had to start all over again?

Hristov: I was fortunate to begin my DevOps journey under the guidance of a strong leader who provided me with a solid foundation. However, if I were to start over, I would focus on avoiding the pursuit of perfection. In the tech world, there will always be a more optimized solution or a 500ms faster request. Instead of chasing perfection, I would prioritize understanding the core business needs and identifying the critical pain points to address.

Early in my career, I often fell into the trap of trying to make everything perfect from the beginning. This is almost impossible and can lead to unnecessary delays and frustration. It’s more effective to iterate and improve incrementally, focusing on delivering value quickly and refining solutions over time.

Security can be at odds with a fast and efficient development process. At QCon San Francisco Dorota Parad presented how to create a foundation for security without negatively impacting engineering productivity.

Traditionally, security is all about defense, Parad said. We focus on stopping the attackers, so we put obstacles in place to stop them. These very same obstacles often get in the way of our own employees as much, if not more, as the malicious actors, she mentioned.

Considering software development, engineers have the power to bring our whole system down, so it’s not much of a mental jump to treat them as a source of security risk, Parad argued. But it’s the same engineers who make the system run and release the features that keep our business going:

Putting too many obstacles in their way means slowing down our value delivery, which in the long run costs the business more than a security incident would.

Parad mentioned that there is the tension between security and productivity, which traditionally gets resolved by an unsatisfying mixture of security theater and lax security posture, all dressed up as “compliance”. In that situation, no one wins except the attackers, she added.

Parad presented a framework she created, called BLISS, which helps implement security without negatively impacting engineering productivity. BLISS stands for bulkheads, levels, impact, simplicity, and pit of success:

• Bulkheads let you limit the blast radius of security incidents through separation and isolation.
• Instead of applying a single, strict strategy to everything, have different levels of protection proportionate to the level of risk.
• Focus on minimizing the impact of the incidents instead of just limiting the probability.
• Keep your processes and tools simple to make them easier to secure.
• Create a pit of success, where it’s so easy to do the right thing that it happens by default.

This way, you can make your security strategy almost invisible to the engineers while embedding it deep into the culture at the same time, Parad said.

Focusing on minimizing the impact of breaches can be more effective than trying to prevent the breach in the first place, Parad said. What security teams often overlook is that modern software development already includes a lot of ways that make a successful attack less likely compared to the early days of the internet. CI/CD pipelines, ephemeral test environments with automated tests, code reviews, serverless infrastructure are just some of the examples, she explained:

I’m not saying we should completely ignore prevention, things aren’t so black and white. From what I see in the industry though, security teams often overindex on measures intended to prevent breaches, and that’s ineffective.

None of these offer full protection, but when we consider them all together, they create a baseline that’s good enough, Parad said. At that point, trying to reduce the likelihood of a breach tends to bring diminishing returns, so it makes sense to look at the impact side of things.

Assume every part of your system is going to get compromised at some point; it’s not a matter of if, but when, Parad said. She suggested thinking about what you do so that an event doesn’t turn into a total catastrophe.

InfoQ interviewed Dorota Parad about improving security and productivity.

InfoQ: What can be done to improve both engineer productivity and security?

Dorota Parad: An example is logging in with Single Sign On (SSO) instead of having to use multiple usernames and passwords. Not only is that easier for the user – no need to remember or type in that annoying password every time, it’s also more secure.

Any time you make a part of your development process simpler or more robust is going to be a productivity win; we all understand that intuitively. What’s less obvious is that those same optimizations tend to improve security as well. If it’s automated, it’s fewer places for a malicious actor to use social engineering to get access. Fewer steps in a process mean fewer attack vectors. Removing tools from our tool chain means fewer things to break and fewer vulnerabilities to patch.

InfoQ: You highlighted the importance of “bulkheads” to limit the blast radius of incidents—what are some practical ways teams can achieve this?

Parad: It’s all about the separation: separate git repositories with separate access controls, separate deployments, cloud accounts, databases, and so on. I always say security starts with the architecture and how well you can achieve that separation is going to be constrained by your architecture choices.

If you have a monolith where everything has to be deployed all together into a single cloud account, you’re going to be pretty limited on where you can place your bulkheads. But even then, having a separate instance for each customer will offer some way to limit the blast radius in the event that one instance gets compromised.

Ideally, we want a modular architecture with different parts of the system deployed and operated independently. That way, if one part becomes compromised, it doesn’t automatically mean the whole system is.

Software architects and system architects will not be replaced anytime soon by generative artificial intelligence (AI) or large language models (LLMs), Avraham Poupko said. They will be replaced by software architects who know how to leverage generative AI and LLMs, and just as importantly, know how NOT to use generative AI.

Avraham Poupko gave a talk about how he uses artificial intelligence in his daily work as an architect at OOP conference.

The word LLM means Large Language Model. Poupko argued that the question of how humans and machines differ is a fundamental question, and understanding it is critical to the understanding of LLMs.

Humans do not really have a language model, they have a world model, Poupko said. Humans have an understanding of the world that consists of an understanding of how the objects in the world behave, and how they interact with each other. That world model is the result of many experiences and interactions, Poupko explained:

When we use spoken and written language to communicate about the world, that is only one representation of the world model and a very limited representation at that.

LLMs on the other hand only have a word or language model, Poupko mentioned. The LLMs only know how words relate to each other. While that model often does give an astonishing illusion of understanding and comprehension, it is not real understanding. It is just a sequence of words, he said.

While it is true that a great deal of world knowledge can be captured in texts and in words, other parts of our world knowledge and world understanding are based on experience and cannot be properly captured in words, Poupko said. This is particularly true with situations that are highly contextual and where the person present is aware of the context, but where not all the context is verbal, he added.

Architects and large language models can work together to create better software architecture, Poupko said, which is somewhat similar to how humans and books can work together:

Humans will use books to learn and understand. A human will decide if the case at hand is similar to the case outlined in the book, and if so will apply the knowledge learned from the book in a context-appropriate way.

That is exactly what we do with an LLM, Poupko stated. We give it a prompt or series of prompts and receive a response. The response is usually neither correct nor incorrect, rather the response is either useful or not useful (as the famous George Box quote goes “All models are wrong. Some are useful”), he mentioned. When we say useful, we mean useful to humans. It is the human that gets to decide if indeed the model is useful and in what context, and then decides to apply it, he mentioned.

Poupko mentioned that that AI is most useful in tasks that involve written language. A case where he often uses LLMs is when there is a need to read a requirements document and discover ambiguities, i.e. those cases where a single requirement can mean multiple things.

In the talk, he gave an example where an online system had the requirement:

The system should be able to handle a large number of users.

When asked to detect ambiguities, the LLM he was working with, detected two ambiguities:

1. The term “a large number of users” is not useful as it is not specific enough. How many users is a “large number”? 100? 1,000,000?
2. The term “a large number of users” can either mean a database that supports a large number of users that are registered to the system, or it can mean a large number of concurrent users. It might of course mean both.

Next Poupko used the LLM to explore what information was needed in order to resolve these ambiguities.

AI does not do design work for me, Poupko said. The system knowledge, the domain knowledge, and the organizational knowledge needed to do effective architecture are such that AI can’t replace me, he concluded.

Data contracts define the interface between data providers and consumers, specifying things like data models, quality guarantees, and ownership. According to Jochen Christ, they are essential for distributed data ownership in data mesh, ensuring data is discoverable, interoperable, and governed. Data contracts improve communication between teams and enhance the reliability and quality of data products.

Jochen Christ spoke about data contracts at OOP conference.

Data contracts are what APIs are for software systems, Christ said. They are an interface specification between a data provider and their data consumers. Data contracts specify the provided data model with the syntax, format, and semantics, but also contain data quality guarantees, service-level objectives, and terms and conditions for using the data, Christ mentioned. They also define the owner of the provided data product that is responsible if there are any questions or issues, he added.

Data mesh is an important driver for data contracts, as data mesh introduces distributed ownership of data products, Christ said. Before that, we usually had just one central team that was responsible for all data and BI activities, with no need to specify interfaces with other teams.

With a data mesh, we have multiple teams that exchange their data products over a shared infrastructure. This shift requires clear, standardized interfaces between teams to ensure data is discoverable, interoperable, and governed effectively, Christ explained:

Data contracts provide a way to formalize these interfaces, enabling teams to independently develop, maintain, and consume data products while adhering to platform-wide standards.

Christ mentioned that the main challenge teams face when exchanging data sets is to understand domain semantics. He gave some examples:

If there is a field called “order_timestamp”, is it the timestamp when the customer clicked on “buy now”, is it the payment succeeded event, or is it the order confirmation email?

Another example is enumerations, such as a “status” field, which highly depends on the implemented business process and exception-handling routines.

Data contracts are written in YAML, so they are machine-readable, Christ said. Tools like Data Contract CLI can extract syntax, format, and quality checks from the data contract, connect to the data product, and test that the data product complies with the data contract specification. When these checks are included in a CI/CD deployment pipeline or data pipeline, data engineers can ensure that their data products are valid, Christ mentioned.

Data users can rely on data contracts when consuming data from other teams, especially when data contracts are automatically tested and enforced, Christ said. This is a significant improvement compared to earlier practices, where data engineers had to manually trace the entire lineage of a field using lineage attributes to determine whether it was appropriate and trustworthy for their use case, he explained:

By formalizing and automating these guarantees, data contracts make data consumption more efficient and reliable.

Data providers benefit by gaining visibility into which consumers are accessing their data. Permissions can be automated accordingly, and when changes need to be implemented in a data product, a new version of the data contract can be introduced and communicated with the consumers, Christ said.

With data contracts, we have very high-quality metadata, Christ said. This metadata can be further leveraged to optimize governance processes or build an enterprise data marketplace, enabling better discoverability, transparency, and automated access management across the organization to make data available for more teams.

Data contracts are transforming the way data teams collaborate, Christ explained:

For example, we can use data contracts as a tool for requirements engineering. A data consumer team can propose a draft data contract specifying the information they need for a particular use case. This draft serves as a basis for discussions with the data providers about whether the information is available in the required semantics or what alternatives might be feasible.

Christ called this contract-first development. In this way, data contracts foster better communication between teams, he concluded.

InfoQ interviewed Jochen Christ about data contracts.

InfoQ: How do data contracts look?

Jochen Christ: Data contracts are usually expressed as YAML documents, similar to OpenAPI specifications.

dataContractSpecification: 1.1.0
info:
 title: Orders Latest
 owner: Checkout Team
terms:
 usage: Data can be used for AI use cases.
models:
 orders:
   type: table
   description: All webshop orders since 2020
   fields:
     order_id:
       type: text
       format: uuid
     order_total:
       description: Total amount in cents.
       type: long
       required: true
       examples:
         - 9999

InfoQ: How do data contracts support exchanging data sets between teams?

Christ: With data contracts, we have a technology-neutral way to express the semantics, and we can define data quality checks in the contract to test these guarantees and expectations.

Here is a quick example:

order_total:
 description: |
   Total amount in the smallest monetary unit (e.g., cents).
   The amount includes all discounts and shipping costs.
   The amount can be zero, but never negative.
 type: long
 required: true
 minimum: 0
 examples:
   - 9999
 classification: restricted
 quality:
   - type: sql
     description: 95% of all values are expected to be between 10 and 499 EUR.
     query: |
       SELECT quantile_cont(order_total, 0.95) AS percentile_95
       FROM orders
     mustBeBetween: [1000, 49900]

This is the metadata specification of a field “order_total” which not only defines the technical type (long), but also the business semantics that help to understand the values, e.g., it is important to understand that the amount is not in EUR, but in cents. There is a security classification defined (“restricted”), and the quality attribute defines business expectations that we can use to validate whether a dataset is valid or probably corrupt.

InfoQ: How can we use data contracts to generate code and automated tests?

Christ: In the previous “order_total” example, the data quality SQL query can be used by data quality tools (such as the Data Contract CLI) to execute data quality checks in deployment pipelines.

In the same way, the CLI can generate code, such as SQL DDL statements, language-specific data models, or HTML exports from the data model in the data contract.

Web accessibility is about making web content available to users with disabilities. Development teams can use the success criteria of the Web Content Accessibility Guidelines to improve accessibility and create an inclusive website.

Joanna Falkowska gave a talk about creating accessible websites at DEV: Challenge Accepted.

There are different kinds of disabilities, Falkowska said. Think of users with sensory limitations (e.g. visual, hearing), physical ones (e.g. missing limbs), neurological diseases (e.g. Parkinson’s disease), or cognitive disability (e.g. Down syndrome).

The WHO estimates that about 16% of the world’s population is affected by significant disability:

If we add all of the mild ones, as well as groups that usually do not consider themselves disabled but might be facing similar problems, such as the elderly, the number becomes even higher.

Falkowska mentioned that development teams who do not know where to start their accessibility journey may feel overwhelmed by the number of disabilities they should take into consideration. They may have no idea about the limitations different users with disabilities face when opening their web app:

What they need is a benchmark that gives them clear criteria as to what makes an app accessible.

The Web Content Accessibility Guidelines (WCAG) is a document that serves people who create web apps. It has been drafted to make the web accessible and it gets updated every now and then to keep up with the development of the technology people use, Falkowska said. Just as the offline world can be more or less friendly for people with disabilities, the same way the websites that we browse can be more or less accessible, she added.

The WCAG gives you a set of success criteria that have assigned conformance levels, as Falkowska explained:

The lowest and the most basic one is A. The Web Accessibility Initiative (WAI), who is responsible for drafting and updating WCAG, states that any website we browse should address at least this level of conformance.

AA is a bit more complex, but at the same time it is the level that the authors (and many legal acts) recommend to follow, Falkowska said. The third and generally the most difficult to achieve is AAA. Usually the entities that address triple A will either be governmental/federal offices or companies/associations that serve specific groups of people with disabilities, Falkowska mentioned.

The levels are a bit like the wooden nesting doll “matryoshka”, Falkowska said; if you want to address AAA with your website, you also need to cover AA as well as A’s success criteria.

Falkowska mentioned that one of the most commonly missing success criteria tells you to add alternative text to any content that makes sense only if you can perceive it with your eyes. For example, if your website contains an image, a person who cannot see and uses a screen reader will only hear the name of the file, which may just be a meaningless string of numbers and characters. In order to make sure they can perceive this content in a meaningful way, developers add an “alt” attribute in html, Falkowska said. The content of this attribute will not be visible on the website, but the screen reader will read it to a person using assistive technology.

InfoQ interviewed Joanna Falkowska about the success criteria for an accessible website.

InfoQ: Can you give some examples of success criteria?

Joanna Falkowska: An example would be keyboard focus. It should be possible for the user to navigate all of the interactive elements with a keyboard, which is achieved with the “tabindex” attribute in html. It is beneficial not only for users with visual disabilities, but also to those who cannot use a mouse due to hand tremors, e.g. because of Parkinson’s disease. It is also a very good example of how a success criterion may support users without disability. I cannot count the number of situations when my mouse was discharged and I needed to navigate the web with a keyboard only while waiting for the mouse battery to fill up…

Another example is that of screen orientation (which is mainly important for tablets and smartphones). It should not be limited to landscape or portrait-only mode. Some users may use a mobile device in one orientation only. Think of the users with quadriplegia who have their phone attached to a special handle or a tripod. They cannot move their phone around. We should not lock their display to one specific orientation with the CSS rotate and/or transform property.

One of the newest success criteria discusses authentication issues the users may have. Authentication should not strain short-term memory with puzzles, so we need to make sure that our login feature allows for copy-paste and/or the use of a password manager. Make sure your input fields provide proper “label”, “type” and “autocomplete” html attributes. Apart from that, we should no longer require the users to solve the CAPTCHa in which the content needs to be deciphered and then typed into an input field. Object recognition is still allowed at AA level, but if you wish to succeed with AAA, even this type of CAPTCHa should be removed.

Growing your personal brand can improve your credibility, give you greater impact, and lead to better opportunities, Pablo Fredrikson said at QCon San Francisco. As a staff plus engineer, helping others solve problems creates value for the company. His advice is to find out what you are passionate about, learn more about it, get better at it, and share it, to build your personal brand over time.

A personal brand is the impression or perception of an individual, as Fredrikson explained:

Your personal brand is a culmination of the experiences, skills, and values that differentiate you.

Whether you like it or not, you already have a personal brand, even if you try not to, Fredrikson mentioned.

Software developers should care about their personal brand because it is part of “selling” themselves to peers and superiors, Fredrikson said. It can be a way to get access to better projects, a promotion, or even a career change, he added.

By improving your personal brand, you’ll also improve your credibility. With that influence, you can inspire others and add significant value to the company, Fredrikson mentioned. For principal engineers, this impact extends far beyond their immediate team, as Fredrikson explained:

A strong personal brand enables you to shape decisions and strategies at the organizational level, driving company-wide improvements, and fostering a culture of excellence.

As IT professionals, we’re constantly learning as part of our job, Fredrikson said. It’s an incredible advantage—we’re paid to grow our skills and knowledge, he added. If we take full advantage of this, we can not only elevate our careers but also inspire and help others along the way, he explained:

In order to build my brand I needed to be better at my job, so I learned a lot of new technologies and techniques that I needed to expose my knowledge.

To improve your brand, Fredrikson suggested finding what you are passionate about. Keep talking about it, get better at it, and share it, he advised:

Maybe it’s dinosaurs, maybe it’s clean code or maybe it is leading productive teams. There is something you can’t shut up about, so don’t!

Fredrikson mentioned that at the end of the day, you just need to become a better person. Customers don’t care if you use X or Y technology, they just want to use your software, he said. So if you care about them, and you build a good team, you’ll make a good product and your customers will be happy, he concluded.

InfoQ interviewed Pablo Fredrikson about building his personal brand.

InfoQ: What benefits did you get from building your brand?

Pablo Fredrikson: Let me give an example. During a project about cutting down costs in our infrastructure, I learned about Karpenter, an open source tool that automatically selects the best machines for your Kubernetes cluster. The tool helped us to save money and also I made a video about it on my YouTube channel.

Once I got that, I was able to get exposure and that definitely helped me to get more interviews and opportunities. I was also able to give this talk at Qcon because of my brand!

InfoQ: What worked and what didn’t work in elevating your brand?

Fredrikson: You definitely need to be open to pivoting. At first, I started creating more “vloggy” videos, like recording an adventure of going to get ice cream—things like that. It didn’t work at all. I didn’t have an audience, and no one cared about my personal stories.

So, I pivoted. I realized I was already learning and growing every day through my work, and the roles I aspired to required teaching and sharing experiences. I decided to align my content with that goal. I faked it until I made it—I learned, helped people at my job, and then used that knowledge to help others outside of it. In essence, I got paid to learn, and I turned that into an opportunity to grow my brand.

As customers take on a more active role in national language adaptation, the process should be simple, using tools they are familiar with, Daniela Engert stated in her talk at NDC TechTown. They decided to use GetText in C++ where they provide tools and procedures for their customers to provide translations.

Engert mentioned that they want their customers to be a bigger part of the whole development process. With the opportunity of their – at least optional – ultimate decision about the “language” (national or regional language, jargon, terms, script) the application communicates with them, they are increasingly less passive consumers:

We need to be aware of the needs of our customers to take part in this process, and learn to abandon some control over what we thought to be our private playground, bound only by our company culture and upbringing in our wider environment.

If we expect customers to work with us on a product that satisfies their needs and meets their expectations, we should make the whole process as simple as possible to people outside of our inner circle, Engert said. What we may perceive as “simple” and “easy” might just reflect a very particular world view, she explained:

For example, we might see an XML file with all the necessary information for the language translation process as “perfect”, albeit wordy. But customers and all the people involved at their site like end users, professional translators, or the like, will most likely perceive this as gobbledygook with arcane and obscure rules, possibly outright frightening.

There is no “blessed way” of doing it, there are rightfully no related functions in the C++ standard library, and there is no “standard” library that fulfills the needs. Instead, we have the choice of multiple libraries from both C++ and C, Engert said, so we then need to figure out which one suits us best.

There are solutions available that come with a rich enough ecosystem of tools and information sources that can guide us. Some of them are pretty specific to a subset of programming languages or communities. These are great because their gravitational pull helps defend their selection, Engert said.

Some tools are more geared to a wider audience, Engert mentioned. This is part of the landscape where you might find a solution that fits possibly all applications (and their dependencies) that you might intend to adapt to more languages than just one:

Such solutions tend to be more open to inputs from communities outside the programmers’ guild. They often have a richer tooling ecosystem and more sources for information at different levels of understanding the problems. That’s good for our customers, too.

They chose to use the GetText tools in their company, Engert said, to develop a feature in e.g. C++ with little to no translation in mind, in a language they preferred. Tools that come with GetText then extract all those strings that require translation and put them into a container text file with all the already existing translations.

Engert mentioned that they let their customers come up with translations of their own taste, using their preferred procedures and tools. Or they do it themselves if the customer chooses so. Tools build the artifacts that they incorporate into the application and deploy to the machines at the customer site (they are a company that builds machines). People can then select one more UI language when working with the machine, Engert said.

The GetText facilities became standardised this year, after a decades-long history and widespread use in the industry, Engert mentioned. They take advantage of other standards like Unicode and the information available there about how to handle languages and their peculiarities like language forms dependent on quantities, she concluded.

InfoQ interviewed Daniela Engert about doing natural language adaptation.

InfoQ: How can we involve customers in national language adaptation?

Daniela Engert: Timely involvement and short development cycles are more likely with the least possible entry barriers for people that are much less affine to the world of IT than we implicitly are. Rather choose something as simple as a text file with the least possible amount of rules to follow.

Ideally, a customer can modify such a file with any text editor at hand, with a small chance of introducing errors. And if they do, like using e.g. MS Word as their preferred tool, we can quickly undo it without loss of information. Ideally, we can give them tools that feel like all the other tools they are already familiar with.

InfoQ: What will the future bring when it comes to national language adaptation in C++?

Engert: I can see no appetite in the committee to incorporate something like that into the C++ standard library. Besides alluding to language translation in some proposals, I am not aware of any substantial efforts or even proposals to widen the target area of C++.

Many of the committee members – like myself – are volunteers with little to no support from their employers. Our resources and our energy are limited. That’s the reality of most ISO languages with no company backing. C++ was always meant to be a tool for implementing libraries, tailored to certain applications and particular needs. Let’s keep it this way. The language itself is expressive enough, powerful enough, and dynamic enough to fulfill current and future requirements.

DORA can help to drive sustainable change, depending on how it is used by teams and the way it is supported in a company. According to Carlo Beschi, getting good data for the DORA keys can be challenging. Teams can use DORA reports for continuous improvement by analysing the data and taking actions.

Carlo Beschi spoke about using DORA for sustainable improvement at Agile Cambridge.

Doing DORA surveys in your company can help you reflect on how you are doing software delivery and operation as Beschi explained in Experiences from Doing DORA Surveys Internally in Software Companies. The way you design and run the surveys, and how you analyze the results, largely impact the benefits that you can get out of them.

Treatwell’s first DORA implementation in 2020 focused on getting DORA metrics from the tools. They set up a team that sits between their Platform Engineering team and their “delivery teams” (aka product teams, aka stream aligned teams), called CDA – Continuous Delivery Acceleration team. Half of their time is invested in making other developers and teams life better, and the other half is about getting DORA metrics from the tools:

We get halfway there, as we manage to get deployment frequency and lead time for changes for almost all of our services running in production, and when the team starts to dig into “change failure rate”, Covid kicks in and the company is sold.

DORA can help to drive sustainable change, but it depends on the people who lead and contribute to it, and how they approach it, as Beschi learned. DORA is just a tool, a framework, that you can use to:

• Lightweight assess your teams and organisation
• Play back the results, inspire reflection and action
• Check again a few months / one year later, maybe with the same assessment, to see if / how much “the needle has moved”

Beschi mentioned that teams use the DORA reports as part of their continuous improvement. The debrief about the report is not too different from a team retrospective, one that brings in this perspective and information, and from which the team defines a set of actions, that are then listed, prioritised, and executed.

He has seen benefits from using DORA in terms of aligning people on “this is what building and running good software nowadays looks like”, and “this is the way the best in the industry work, and a standard we aim for”. Beschi suggested focusing the conversation on the capabilities, much more than on the DORA measures:

I’ve had some good conversations, in small groups and teams, starting from the DORA definition of a capability. The sense of “industry standard” helped move away from “I think this” and “you think that”.

Beschi mentioned the advice and recommendations from the DORA community on “let the teams decide, let the teams pick, let the teams define their own ambition and pace, in terms of improvement”. This helps in keeping the change sustainable, he stated.

When it comes to meeting the expectations of senior stakeholders, when your CTO is the sponsor of a DORA initiative then there might be “pushback” on teams making decisions, and expectations regarding their “return of investment” on doing the survey, aiming to have more things change, quicker, Beschi added.

A proper implementation of DORA is far from trivial, Beschi argued. The most effective ones rely on a combination of data gathered automatically from your system alongside qualitative data gathered by surveying (in a scientific way) your developers. Getting good data quickly from the systems is easier said than done.

When it comes to getting data from your systems for the four DORA keys, while there has been some good progress in the tooling available (both open and commercial) it still requires effort to integrate any of them in your own ecosystem. The quality of your data is critical.

Start ups and scale ups are not necessarily very disciplined when it comes to consistent usage of their incident management processes – and this impacts a lot the accuracy of your “failure change rate” and “response time” measures, Beschi mentioned.

Beschi mentioned several resources for companies that are interested in using DORA:

• The DORA website, where you can self-serve all DORA key assets and find the State of DevOps reports
• The DORA community has a mailing list and bi-weekly vídeo calls
• The Accelerate book

In the community you will find a group of passionate and experienced practitioners, very open, sharing their stories “from the trenches” and very willing to onboard others, Beschi concluded.

As ClearBank grew, it faced the challenge of maintaining its innovative culture while integrating more structured processes to manage its expanding operations and ensure regulatory compliance. Within boundaries of accountability and responsibility, teams were given space to evolve their own areas, innovate a little, experiment, and continuously improve, to remain innovative.

Michael Gray spoke about the journey of Clearbank from start-up to scale-up at QCon London.

ClearBank’s been on the classic journey of handoffs in the software delivery process, where they had a separate QA function, security, and operations, Gray said. With QA as an example, software would get handed over for quality assurance, before then being passed back with a list of found defects, after which the defects were fixed, then handed back to QA to test again. All of these hand-offs were waste in the system and a barrier to sustainable flow, he mentioned.

Gray explained that everyone is now a QA, as well as an engineer; the team that develops the software is also accountable for the quality of it. They maintain a QA function, however, their role is to continually coach and upskill the software delivery teams, maintain platform QA capabilities, and advise software delivery teams on specific questions:

We’ve found a significant increase in both quality and sustainable speed of software working this way. This also keeps the team’s feedback loops short and often, allowing them to make adjustments more quickly.

End-to-end ownership leads to direct and faster feedback loops, Gray said. A team seeing and feeling the consequences of poor quality sooner takes more pride in making sure software is up to a higher standard; a team feeling the pain of slow releases is more likely to do something to fix the slow release, he explained:

This is only true if we ensure there’s space for them to continuously improve, if not this end-to-end ownership becomes a fast way to burn folks out.

Gray mentioned that they are constantly trying to find the balance between autonomy and processes, and prefer processes that provide enabling constraints as opposed to governing. This allows people to make their own decisions within their processes that help them, as opposed to getting in their way and negatively impacting the teams.

As organisations grow, there is the natural tendency to add more and more processes, controls and overheads, but rarely do they review if the current processes are working, and remove processes and controls that are no longer necessary, Gray said. We try our best to be rigorous at reviewing our processes and controls, to make sure they are still effective, and having positive outcomes for the bank as opposed to getting in the way or creating wasteful overhead, he stated.

Gray explained that they communicate their strategy at three key levels to enable localised decisions:

1. The business strategy
2. The product strategy that supports that
3. The technology strategy that supports both the business and product

Ensuring that strategies are clearly understood throughout the organisation helps people make much more informed decisions, he said.

Gray mentioned two aspects that enable maintaining an innovative culture while scaling up:

• Clear communication of the vision and mission, and a supporting strategy to ensure there’s alignment and a direction
• Ensure you create space in the system for people to experiment, so long as it is aligned with that strategy.

A mistake a lot of organisations make is trying to turn an organisation into a machine with very strict deliverables/accountabilities that take up 100% of teams’ time with absolute predictability of delivery, Gray said. While we should all have a good understanding of our boundaries and what we are responsible/accountable for, building and delivering software is not manufacturing the same thing over and over again and neither is evolving a complex system, it is a lot more subtle than that:

When we try to turn them into “well-oiled machines”, it is not long before inertia sets in and we continue doing the same thing, no longer improving or innovating.

InfoQ interviewed Michael Gray about staying innovative while scaling up.

InfoQ: You mentioned that processes are reviewed and are being changed or removed if they are not effective anymore. Can you give some examples?

Michael Gray: One example is our continuously evolving development and release processes. This is a process that is very much in control of technology, where we are continuously reviewing toil, asking questions such as, “Is this step of the process still needed and adding value?”

Another example of this is how we review software for security. Previously we needed a member of the team to be a “security reviewer” which meant they would need to review every software release with a security lens. We automated this with tooling, and if software meets a minimum security standard, this can be automatically approved by our automation. All engineers now must have a minimum level of security training to be able to review software. This removed bottlenecks from teams for releasing software, improved the minimum security awareness of all our engineers, and removed friction from the process with automation, further improving our DORA metrics.

InfoQ: How do you support localised decisions at Clearbank?

Gray: We introduced the concept of decision scopes. We have enterprise, domain, and team. The question folks need to ask is who does this decision impact? If it’s just the team, make the decision, write an ADR (Architecture Decision Record) and carry on. If it impacts other teams in your domain, have a conversation, reach an agreement, or don’t- either way write the result down in an ADR. For enterprise decisions that are wide impacting we have our Architecture Advisory Forum.

High-performing teams expect their leader to enable them to make things better, Gillard-Moss said at QCon London. Independence in software teams can enable decision-making for faster delivery. Teams need empathy, understanding, and guidance from their managers.

Something most driven and motivated engineers have in common is that they will have a longer list of all the things they want to improve than the things they believe are going well. Gillard-Moss mentioned that for some managers this is intimidating and makes them believe the team is being negative, when in reality this is a good thing. They are motivated to get these things solved. In return, they need you to create the opportunity to solve things.

If the team feels that you are not enabling them to solve things fast enough, then sentiment turns negative, Gillard-Moss argued. This is because they’ve stopped believing in you as someone who can help. So rather than bringing you problems to solve and wanting your help, they become complaints, burdens, and excuses:

If you have a team that is unable to make things better, and is stuck complaining that things aren’t getting better, then you do not have a high-performing team.

We should strive for independence in teams for faster and better decision-making, which leads to faster delivery and faster impact, Gillard-Moss said. Waiting for decisions is the single biggest productivity killer, and making decisions on poor information is the most effective way to waste money, he explained:

In technology, we need to make thousands of decisions a day. It’s unrealistic for someone far from the information to make high-quality decisions without blocking teams. And it doesn’t scale.

With low-performing teams, Gillard-Moss suggested analysing their cycle time. The vast majority of it is waiting for someone to provide information or make a decision, he mentioned. And then, when they do, the team struggles to implement or pursue a suboptimal solution because the decision maker had an overly naive view of what needed to be done.

What teams need from managers is empathy, understanding, and guidance. Empathy comes from being able to think like an engineer, Gillard-Moss said, and understanding because you’ve been there and done that yourself. Guidance comes from a deep instinct for the universal fundamentals of engineering and how to apply them to get better results, he added, the evergreen wisdom and principles.

Gillard-Moss stated that a good engineering leader builds teams that can maximise impact by applying their expertise:

My experience as an engineer tells me that integrating early and often results in less delivery risk, and when to tell that’s not happening. It also tells me that’s sometimes easier said than done and the team might need help working through it. This gives me the patience and empathy to guide a team through the trade-offs in these difficult situations.

InfoQ interviewed Peter Gillard-Moss about managing high-performing teams.

InfoQ: How can managers help teams improve their cycle time?

Peter Gillard-Moss: There are so many factors that influence cycle time, from architecture to organisation design to culture to processes. The best thing any manager can do is observe the system and continuously ask, “Why did this take as long as it did? With hindsight how could we have improved the quality of this decision?” And then experiment with small changes. Little nudges. This is, after all, why we have retrospectives.

One example was a team who felt like they worked on a lot but nothing came out the other end. When we analysed the cards, we saw that they would keep moving back up the wall from Dev Complete back into Dev, or more cards would be created and the original card would be placed in Blocked or Ready to Deploy for weeks on end. What was happening was the stakeholder would specify the exact solution, literally down to fields in the database in the original card. The team would build it and then the QA would find edge cases. The edge cases would go back to the stakeholder who would then decide on the next steps, either adding new criteria to the original card or creating new ones.

Most of this was over email (because the stakeholder was too busy) and it was often missing context both ways. When you gathered the history and context around the cards, it looked absurd as weeks would go by for simple stories which have long email chains connected to them. Despite the obvious inefficiencies, this is a pattern I’ve seen in many teams.

InfoQ: How can engineering leaders keep their engineering expertise up-to-date?

Gillard-Moss: You can’t. I’m really sorry but you can’t. It’s impossible. Once you realise this, it will liberate you and you will become a better leader.

Plus it’s not what teams need from you. The engineering expertise needs to be in the team with the people doing the work. Knowledge and expertise is a group asset, not an individual asset.

How do you think a team would perform if all the knowledge and expertise was only in their manager’s head? Every time a team gets stuck having to go to their manager to get the answer. How slow is that? How expensive is that? And the manager will burn out and complain that they don’t have time to focus on the important things.