The Crossroads of Testing and Architecture: An Interview with Neil Ford

What does a QA architect position mean? And what does the completely incomprehensible position of meme wrangler mean? From when should testers be connected when working on architecture? How to change processes in the organization so that people at a meeting with the first complexity do not return to the old?

Neil Ford presents three options on his website: ThoughtWorker (an employee of ThoughtWorks, which many people know because of Martin Fowler), Software Architect and Meme Wrangler. Soon, at our Heisenbug conference, he will talk about creating “evolutionary architectures,” which can be changed with changing external circumstances. In the meantime, Michael xomyakus Druzhinin(a member of the Heisenbug program committee) asked Neil: both how his presentation intersects with testing, and much more.

- Can you start by telling about yourself and your career?

- Of course. I have been at ThoughtWorks for almost 14 years. Prior to that, he was CTO at a small consultancy and training firm of about 25 people, and there he began to try his hand at technologies like Java. The first three books I wrote before I joined ThoughtWorks. The very first one was about Delphi, at that time quite popular in Russia and in Europe.

When I was CTO, I got tired of being an alpha geek. When you know more than the people around you do not really develop. I began to speak at a variety of conferences, and I really enjoyed being among the other speakers because they were very smart and interested people. And I began to unconsciously look for a company in which really smart and interested people would mainly work. And literally stumbled over ThoughtWorks, like many, on Martin Fowler's website. On things like CruiseControl and the NUnit testing library, I noticed that they make a huge contribution to open source and do a lot of very interesting things. And so I inadvertently began the interview process with ThoughtWorks, at the end of which I received a job offer. This was a good step for me, because they are very smart and very enthusiastic developers.

I could be an independent consultant, but in this role I do not like two things. First, you must do all the business yourself: billing, chasing people for money, regulating cash flows and all that. I am capable of doing this, but it does not interest me. My passion is software and development.

And the second: if you are an independent consultant, then you rarely manage to work in collaboration with someone, as a team. You are almost always on your own, and I really like team development. I even wrote several books together with other authors, including my latest book, Evolutionary Architecture. It seems to me that when working together, the result is greater than the sum of the individual components. When you collaborate in creative work, whether it be a writing project or a program, you can get more points of view and a more general idea, therefore the result will be better.

So in April it will be already 14 years since I was at ThoughtWorks. I know this so well, because one of the interesting advantages of working at ThoughtWorks is that if you have been with the company for 10 years, you get a 12-week paid vacation time when you can do whatever you want. And after that, every 5 years you get a 6-week paid creative leave, so I have a year left until the first 6-week. I really liked the 12-week one and am looking forward to the next one. So you always remember what a decade you have been here: they are measured out with such pleasant holidays.

- This is a very tangible length of vacation, cool.

“I was hired by ThoughtWorks as an architect and played that role for a while until I got to the director level.” Most of my work now relates to the field of software architecture, I spent a lot of time at the intersection of architecture and engineering practices (for example, continuous delivery) - I suspect that here my interests intersect with those of the Heisenbug audience.

In particular, what I talked about a lot lately is the topic of my latest book, the construction of evolutionary architecture. If you can prevent bugs, then the people who are testing the application will be easier. Evolutionary architecture includes security techniques for critical architectural features — such as deployability, testability, scalability, performance, and so on.

“What does Meme Wrangler mean?”

- According to the rules of ThoughtWorks, you can choose any job title, except for a few reserved ones like "CEO". If you come up with an interesting position for yourself, then please. And when the set of business cards ends, you can come up with a new one.

My first job was an application architect. This position reflected the essence of the work, but very often in large companies it implies that you no longer bring much benefit, that you spend more time drawing pictures than creating anything.

And one of the advantages of custom development is that you can get acquainted with a large number of different projects. Software architects, I think, are “pattern matchers” by nature: we try to apply patterns to everything we see, even to things from the real world. So, if you are an architect in custom development, you have to see a lot of different projects, you see repeating patterns in them, you see which of them work. And I realized that, in fact, my work is a bit of collecting interesting ideas from the software ecosystem. From here came the Meme Wrangler.

Meme is a term coined by writer Richard Dawkins; it is a widespread unit for designating ideas. Everyone knows memes from the Internet - this is some witty thing that catches and spreads like a virus. And the word “wrangle” has two useful meanings, the first is to act as a judge in a dispute, and the second is to drive into a herd. And I chose the position of Meme Wrangler, because it more accurately reflects what I am doing now. Moreover, now that I am releasing another book, I am writing on Twitter that I "lasso another meme" and put it in this book.

- Can you explain what a software architect should do, what do you do as a software architect?

“Of course I can try, but no one really succeeds in giving this a definition.” Martin Fowler - a man who knows how to give a very cool determination of everything in the field of programming - publicly declined to define the term "software architect" in his text "Who needs an architect?" .

But if you look at the role of a software architect, one of the things is that they are responsible for everything that is then difficult to change. This is all related to the structure of your software system: what fundamental patterns will you use, which language or which frameworks. Because all these decisions have far-reaching consequences.

One of the things that architects really really care about is what we call “architectural parameters,” which is also called “non-functional requirements,” but we don't like this name. These are things such as performance, scalability, elasticity, deployability - all this is the responsibility of the architect. An architect can create a structure that will take into account the requirements for the program itself, and all these architectural parameters that must be provided in it.

Suppose you are an architect and you need to create a software system structure for registering students at a university. Suppose we have a thousand students and 10 courses for which they must enroll. And now, based on our knowledge of how universities are organized, what do you think will happen: students will be distributed evenly throughout the semester so that we get the same number of students in each course, or they will all last until the last hour, and then rush to record all at once?

And this is elasticity, this is an architectural parameter that you must ensure when you create such a system. Most likely, this is not indicated anywhere, but you know it, simply based on the subject area. This is what makes the architecture of software systems so complex: you need to understand the subject area, as well as the technical capabilities and limitations of your company. You can be limited, for example, by the fact that this relational database is already selected for the standard of our company, and we need to make the productivity increase. How can we achieve these results?

This is the work of the software architect - to cope with all these important decisions related to the fact that it has very long-term consequences and it is very difficult to change it later. Many elements of the structure, such as the user interface, are pretty easy to develop, because you just change one layer of the application. And architecture is more about how all these layers are juxtaposed, and it's usually much harder to change.

They say that microservices are now quite popular, and such an architecture was created specifically with the expectation of constant changes. So to make major changes to the microservice structure is much easier, but they were created from the very beginning. And this is a very interesting topic for research - how to design an architecture that is easy to change, because for the industry this is exactly what has been the most difficult for a very long time.

- On the issue of architecture and posts: I see “QA Architect” on business cards and LinkedIn more and more.

- This is one of the problems of the term “architect”: each company has to invent its own names for this. I met both “QA architects” and “data architects”, “system architects”, “solution architects”, “technical architects” - I met architects of all possible stripes. And this is a problem, because no one can give a clear definition, and give what you want.

What “architect QA” can mean for a particular company, I don’t even know for sure. Does such a person develop a QA structure? As for me, this is closer to the function of an architect as a technical expert, because often an architect is also a technical project manager. But the architect also deals with presentation and documentation. So, if I am an architect and I had a brilliant idea for a new architecture, but I can’t make a presentation and convince people with money that we should do it, then we will not have a chance to realize my cool idea. This means communication skills.

These skills apply to QA, and whoever does this can also be called an “architect.” You see, this is such a vague post. Many organizations simply come to the point of calling the senior engineer an architect, because it sounds cool and they cannot figure out what else to call it. Like, you know, senior-senior-senior developer - okay, architect. And I met companies where there is one type of architects, and I met companies where there are dozens of varieties of architects. In fact, these are fictitious posts. My “meme wrangler” is better in this sense because it is obviously made up.

- Let's talk in the direction of your speech at Heisenbug. You will speak at a testing conference - what about the quality of software for you?

- I personally consider the quality of the architectural components of the system. I know that the QA world sees software more as a black box, that is, it looks from the user's perspective whether there are errors and failures, whether it functions correctly. Of course, I'm also interested in this, but I'm more concerned about the root causes of errors: why is the application unreliable, why does it crash periodically? Here I have to be the last line of defense, figuring out why this is happening. And there are things like performance and responsiveness. There is a lot of talk about them in the UI world now, they have clear indicators: if your mobile site loads visible content for longer than 3 seconds, users will leave and go somewhere else.

Great attention is paid to web performance: what is the time before loading the first visible content, what is the total page loading time. And all these are quality parameters, which are certainly visible from the point of view of an outside observer, and I am the one who should figure out how we will build a system in which such indicators are achieved. And this can lead to changes in the frontend regarding which web technologies will be used, but it can also lead to changes in the backend. Perhaps, to transmit information not in real time, but in a packet, and in the middle make a caching mechanism? For me, quality looks like this: determine what the requirements are, and then come up with a technical implementation that will embody them.

- Can you give the most interesting case study from practice related to quality?

- It's hard to say, all projects are different, so the best is always the last one I worked on!

Well, somehow I worked on a system where the requirements partially resembled Lotus Notes. Remember such an ancient program? She was a terrible program, but she did one thing very, very good. This program synchronized very well: you could download your mail and notes, then catch a taxi, go somewhere, answer all letters at that time, and the next time you connect to the network, everything will automatically unload, synchronize and work magically way.

And we had a client with a sales system who wanted the same working principle. Because the salespeople are always on the move, and it was necessary that they could place orders without an Internet connection, and then everything would synchronize and become as it should.

And we realized how difficult this is, because of a bunch of borderline cases and scenarios that need to be provided. First, we developed a system that worked without any internet connection at all, then we started synchronization. And there was a bunch of headaches - for example, the performance of an application online compared to offline, a noticeable delay appeared when connecting, because synchronization was taking place at that time. So, in this case, QA was a big splinter for us, because they found borderline cases that destroyed the whole system.

And from the outside, this seems like a simple task. Applications like Dropbox and Google Drive solved this problem so that it became invisible. And it seems easy. But when we tried to solve it, it turned out that there were a million borderline cases. So without a reliable QA, it’s hard to find all of them, each of which must be returned to align with the application structure in order to ensure that the overall structure still works.

Actually, while we were developing this system, making fundamental changes to the structure, we realized that borderline cases would be frequent and unacceptable. And this is a great illustration of how important it is to have a very well-established feedback loop between architecture design and parts like QA. Too many companies put off this at the very last moment, but if you do so, in the end many things will be done wrong, and you will have to go back and spend a lot of time to redo it. If you establish close contact between the development of architecture and testing, you can find these borderline cases and change the structure much faster. Fortunately, we were extremely flexible in this project - since it was a ThoughtWorks project, we had a very fast cycle. And we had a very strong team of testers.

- Many people in testing ask how they can affect the architecture. For them, architecture is something in an ivory tower. What can be done with this?

- It seems to me that it would be useful for testers to come to the architects and explain to them that they are doing their job poorly, and it is better for testers to know how to perform it. People love it when they are told this! Actually, no, they don’t like it, nothing good will come of it.

I have a favorite mantra for such cases: "it is better to show than to discuss." You need to show how different your world is from their world. If you are a testing engineer, you need to bring a user case that will clearly demonstrate the design flaw. If you show this scenario to an architect, then this is not just a complaint about something, but a concrete demonstration: “Now, your project will not work in such a scenario, so it needs to be changed.” If they do not agree to this, then this means that they simply lost touch with reality. And architects must be sensitive to things that happen in the real world.

There is a great little, as I call it, poetryfrom former Secretary of Defense Donald Rumsfeld, which refers to the “famous known” and “unknown unknowns”. So, in every software project there are “unknown unknowns”, so the development of any architecture should be iterative. Because it doesn’t matter how much you think over, things that you could not foresee in any way will simply appear suddenly while you are trying to build this structure.

Suppose you started developing a new system five years ago, and then Docker suddenly appeared two years later. There was no chance that you could predict that something like this would appear. But you need to review your structure as soon as this happens, because now some things can become much easier and some of your problems can be solved.

Therefore, you need to constantly review your entire world. And to think that you are locked in an ivory tower and you can throw projects through the hole in the floor that will not change over the years, and people will simply implement them - it's just naive, this is a misunderstanding of the fundamental principles of software development.

Based on your experience, how would you say the pace of change in software development is slowing down or accelerating?

- Speeding up.

- Of course! And even the pace of acceleration is also accelerating! So any company, any organization that does NOT seek to establish a feedback loop with a design makes a big mistake. Because part of this vital feedback loop should be testing (QA). This is the last frontier of defense, which allows you to just do what you stated what your system will do.

We put together all the things that our system should do, and QA must evaluate whether it really does everything promised. And if not, then testing, demonstrating this, allows you to do two important things. Firstly, it helps to get better architecture feedback. Secondly, it allows you to more accurately determine your goals.

One of the things that I am absolutely confident in architecture is that architectural parameters must have an accurate, objective definition. Because if I have an accurate objective definition of performance or elasticity, then it will be easier for the guys from QA to say whether you have everything right or not. There is either there or not. If you have an objective result for these indicators, this clarifies the relationship between the two parts of your organization and allows you to create a better feedback loop.

- When you develop architecture, at what stages of the project do you attract testers?

- From the very beginning. When we start a project, we usually have architects, developers, business analysts, and QA engineers, and if there is someone who is involved in data engineering, data architecture, or data science, they are also present. Because it’s stupid to make such an architecture that it will be difficult to test.

Their feedback is needed from the very early stages. Because always, again and again in a variety of projects, it happens. First, the architect comes up with some kind of structure and says: "We will do like this." And then someone from the data or testing world says: “You know, if you do this, then it will be very difficult for us to work with this, but if you do this, it will be easier for us, and the task will not be very complicated for you either.” And it is very important to collect these ideas in the early stages, because it is possible to make such a structure that greatly simplifies the life of testers and everyone else, not just testers. You don’t want to drive your data architects crazy.

There is one phrase we often use in ThoughtWorks, “pave cobblestone paths” for people. We do this when we build our infrastructure, things like deployment pipeline. We do not want developers to have difficulty using these tools, we are trying to pave a cobblestone path so that they have as little interference as possible in doing what we consider necessary. And we also believe that you need to have a reliable QA, so that they need to take part in the development of architecture from the very beginning, so that we can see that there will be no difficulties for them in further work with this structure, because why should they create superfluous difficulties, if we can easily immediately make the structure different to reduce most of these difficulties. And noise reduction is such a way to speed up the feedback loop,

- Sounds familiar. And what do you think about the fact that from clear roles “business analyst”, “QA” and so on move to some kind of generalized form?

- This is completely normal. At ThoughtWorks, employees have levels and roles, and people can change roles if they want. A common situation is when a developer becomes a tester on one project, then again becomes a developer on another. Because some people just wonder how others live, they want to try something that they have not tried. We try to automate the testing process as much as possible, and to do this we need to develop a little. And if a strong developer appears in the testing team, this helps them automate more.

- And when they do not even share the roles of QA and developers?

- No, roles are needed, roles must be. Letting developers do the testing is like giving prisoners the keys to their own cameras. They will definitely follow the path of least resistance and will miss absolutely all borderline cases, these will be solid blind spots.

A really good tester should be able to break anything; it's not a developer. Of course, it happens that a person can act in both roles, but these are two completely different ways of thinking. And it’s absolutely impossible to let someone test what this person himself wrote. Because incorrect assumptions are built into the structure of his code, and if this person makes the same incorrect assumptions during testing, then he will miss a lot of things. Therefore, even if you are doing a project without the formal role of a tester in it, at least make the code of one developer test another developer. Because otherwise everything will end with very stupid bugs that no one thought to check.

But I am completely normal in having flexible roles within the project. All this is done so that the team is as small as possible - this is the wisdom that came to us from 1975, which is only now beginning to become aware.

- 1975?

- Fred Brooks wrote in Mythical Man-Month that attracting new people to a lagging software development project slows him down even more. He was the first of those who decided to analyze the dependence of the productivity of the development team and its size. He was the first (although he never called it) who came up with the idea of ​​a “two pizza team”. Although his role distribution was a little different, his results were very accurate. The more communication you need to maintain, the more difficult it is to do it, especially when the work is on something as complicated as the software. So many companies make more flexible roles, which reflects their desire to maintain the small number of teams. But this does not mean that roles do not need to be done at all and there is no benefit from them.

This is how many teams decide they want agile, because they want to avoid what they find boring - like documenting important decisions, QA, and the like. But if you do this, you get only agile disaster. All these things still need to be done, you just need to find a way so that all this is with the least difficulty. But, I believe that this is still critical for software development projects.

- Very interesting.

- By the way, I believe that Apple should hire a corrector to read stupid texts on their dialog boxes. Because on their Wi-Fi dialogs there are two so terrible passive voice examples that I immediately boil every time I see them. Because I am a writer and I hate bad texts. Do not let developers write texts for the UI, let the developers write code. And it’s worth hiring a proofreader in the QA team to fix them and less annoy users.

- Okay, back to the topic of small teams. You probably have a lot of experience at ThoughtWorks - how do I get started with these?

“Well, as I said before,“ it’s better to show than to discuss. ” To show your organization that they should strive to form small teams, it’s enough to track the number of messages that are sent between departments to solve simple issues.

Suppose I need to change the unload from the directory in my application. How many tickets should I create? One for the UI layer, one for developers, one for the database administrator, one for the operations department - and it’s immediately clear that this is just noise and interference. If you have one team, and you are all together, then you need zero messages, because you are all sitting together and you just have to say: “Hey! Let's change the process of unloading from the catalog! ”And you have one standalone team and you need only one message that the unloading from the catalog will be changed, and not 50 tickets in Jira that hang out throughout the company.

This is one clear indicator. And this is exactly what Fred’s book leads to: the damage caused by large divided teams, mainly consists in the fact that most of the time is spent trying to figure out the flow of information: tickets, requests, or anything else that happens between these teams. Just putting them together makes it much easier to work.

We started doing this by chance. We started to organize teams around this idea, and it worked perfectly. We noticed that the work went faster, and this inspired us to spread it as much as possible.

I believe that the only way to implement this approach in a company is to “show better than discuss”. If you are trying to bring this approach to your company, choose a simple, non-vital project and try. Remove the partitions, create a common workspace, put a small cross-functional team there. And it is extremely important, as I have already said, measure. Measure their speed, how often they release releases, how many bugs they have - any metrics that can be collected by this command. And your company will be convinced that indicators will really improve.

And we do the separation of employees by their functions in work. Separation of employees by their functions at work is very convenient for the HR department, but terrible for software development. Team separation is much better. It's crazy to have a whole department of testers, separate from what they need to test. How should you dive into the subject area if you are far from business analysts and developers? Testers need in-depth knowledge in the subject area, how it all works, and if they have very limited access to business analysts, because they are in another part of the company, then how can I get all the knowledge in the subject area that the tester needs for effective work? But if you are sitting in the same room, it will be much easier for a tester to lean over to a business analyst and say:
- Hey! And if you change this value to something, then there should be a credit default swap? Is this the way it should be?
- Yes.
- Good.

This 15-second conversation allowed us to avoid the full cycle of movement of Jira tickets, emails, fuss and all that only causes interference in the work. So to have a team that is in the same room, that is, when there is an opportunity to talk without leaving the room, this is really extremely important. And it is much better to be in the same room than to use something like Slack, because if you are in the same room, you can see if this person is busy, and not throw him with distracting messages through Slack.

There is an analogy that I give, explaining the convenience of being in the same room. Suppose we are back in time 30 years ago and you need to find out the weather in Chicago. How do you do this? You can turn on the weather forecast channel on TV and hope that it comes to Chicago. Or maybe go to the library and see if there are any Chicago newspapers there. Or call someone. And when so many difficulties arise, you no longer want to know this weather. And now it can be recognized instantly, just open the application on your smartphone.

There are the same significant things in software projects: if it’s hard to do, then you just won’t do it, and if it’s a trifle, you’ll do it simply because there are no obstacles. And also with the interaction between business analysis and QA: if it is very easy to establish this contact, it will happen, but if you need to create an email or open Slack, see if this person is available, enter a message. This creates enough interference to not do it at all, although if it were easy, it would be of great benefit.

- It’s logical. However, we are moving towards a world with a large number of distributed teams. So you have offices in London, New York, I don’t know Chicago or there in Singapore. That is, you still have to rely on communication tools.

- Yes, I have to. But the thing is to strengthen communication ties that are torn apart by distance. We have almost all the teams distributed, so we installed video cameras so that team members can see each other all the time: see the face, gestures.

I hate Slack so much! Slack is the latest version of where productivity comes to die. Some teams manage to use it well, but most people use it terribly, turning it into a dump. Each project needs a “default” location to dump everything in a row, and that was Slack. Some are trying to use it to maintain communication "in the same room." And you can use it that way, you just need to be very disciplined, because with the mechanism that constantly distracts you, it is simply impossible to engage in development. I refuse to ever use Slack because it simply destroys my productivity, constantly taking me away from work, because everyone needs something all the time.

This is a convenient format if you are working on a project as a team and you need to quickly get information, but this does not replace communication with each other in the same room.

Communication can be enhanced through the widespread use of webcams. Alistair Cockburn conducted many interesting studies of what he himself called the temperature of communication channels. And the text is a very cold channel of communication, so cold that we had to invent emojis so that people would not get annoyed. Because the text is very easy to read and emojis are needed to add context. How often do you use emojis when talking to someone in person?

- Never.

- Never! Because you can just look at the person you are talking to and see what he’s talking about. This is one of those communication channels that Alistair Cockburn is talking about. If you replace personal communication with Slack, then you will lose all the levels of communication that are in personal communication. Therefore, cameras are much more profitable than Slack, although it may seem that the amount of information transmitted is the same, but there is a huge layer of non-verbal information that is transmitted between people when they talk, and reducing the number of these channels, we make this communication channel much less valuable .

- Yes Yes. At some point, I noticed that I began to put a smiley at the end of each sentence, so as not to sound so damn cold.

Now I’ll ask about something else. Suppose we want to improve the company's IT infrastructure, services, make it faster, better, stronger. And some hire an outside architect for this. In your opinion, is this achievable, or does someone inside the company still need this?

- Here absolutely definitely need the participation of people from the company. And that's why. Someone from the outside can come and show people how to do these transformations, get people to work in a new way, and so on. But as soon as some unplanned crisis occurs, they will all return to their bad habits.

In large organizations, it is almost impossible to radically change the approach of employees to work: as soon as something unsettles them, they immediately return to their old habits. Because "obviously, this new approach did not work and we just go back to the old one." It's very hard. It is easy to inform people about new approaches to work and it is very difficult to make these approaches take root for a long time.

Therefore, you need to have connections within the organization. We have found the best way, and this is the only way we use. Take a small group of ThoughtWorks employees who will work with the team within the organization, and a new approach, like a virus, will spread throughout the organization. Because we are actively working on a project using our engineering techniques in tandem with them. Once the project is completed, ThoughtWorks employees begin to work in tandem with another team, and that first team begins to work in tandem with the third team and begins to distribute these new techniques.

And to disseminate not as if it is a dogma, but as something with which they already have experience, and they know what it is. Again, "better to show than to discuss." Working with a real project and seeing what happens when something breaks, how to recover from it is fundamentally important because it makes such knowledge long-term. We need to give people confidence that if something breaks, you can fix it with this new system and not return to old habits and old methods. You can create “ambassadors”: take small groups, train them, show them how everything works. They become ambassadors and they already go to work in pairs with other teams and so an avalanche spread new principles for organization. That is, first it’s better to start with a small group of volunteers from the organization, and then make it all spread,

This is all based on objective results, and this ultimately convinces the company. If you just talk about all the benefits of these crazy hippy ajails, you will never convince anyone of anything. But if you back it up with numbers: “Look, our new team that uses this new agile approach can add features 1.3 times faster than the team with the“ waterfall ”, and we have 30% less code defects ". If you give specific figures, no one can argue with such objective results. It will be very difficult for them to say: “Oh no, I can’t work in this organization when you have accurate numbers that show that one side benefits the other.”

- And how do you determine what to measure?

- Your company should determine this: what is important to you in software? More important to you is stability or speed of release of new features? You need to determine this on behalf of the company, and that will be the driving force. Okay, stability is really important to us - we are starting to measure stability. How many failures do we have in production over a given time period? If a really important criterion is new features, then we will measure the frequency of new features for this software product.

This should be determined by the company, and this brings us back to what I said before. Objective definitions are needed, because if these are vague, meaningless things, then no one understands what we are striving for as an organization. And if they are fixed in iron, then someone, whether it’s a QA or an architect, or a data architect, knows exactly where to aim when creating and setting up this program. And you will save yourself from the senseless clutter in the company, if you can clearly consolidate these goals. So it depends on you, how you determine what it will be, and you can get together and think about what we value as a company, what indicators will be useful to monitor in order to understand that this experiment is paying off.

- In fact, you say that the goals of the company will affect the quality parameters for a particular system and we will achieve some compromise on the basis of the organization, not even a specific project in it?

- That's right. This is one of the things that I often say lately: there are all trade-offs in software development, and if it seems to you that you have found something that is not a compromise, it means that you have not yet understood that it is a compromise.

There are no binary contrasts in software development - everything is located on the spectrum, closer to one or the other side, it is important to determine exactly where. This is one of the reasons why architects are always so annoying: in our world there is no binary “yes or no”, there are only compromises, there is nothing better, there is only the least bad.

- I have stickers with the phrase “architecture is abstract until operationalized” that you use, and I really like it. Maybe you could tell us in more detail what this means to you?

- Of course. This is one of the memes I collected, a good example for meme wrangler.

I realized that this is actually a reflection of the DevOps revolution. For a long time, architects believed that their job was to draw beautiful pictures of architecture and all. But continuous delivery to DevOps showed us that this is only an abstraction, and the next step is to make this architecture really work in a real control center with real software, with real version numbers.

It is an idea that architecture is always an abstraction until “the tires feel the road” and it will not be realized. But you can't just go straight to implementation. And the developed architecture cannot simply be left behind, because everything in the world is constantly moving and changing. Here is a thought experiment that I sometimes do: take a computer, put an operating system on it, install several programs, and then disconnect it from the network and put it in the cabinet for a year. After a year, get out your computer, connect it to the network and the Internet, and what will it do first?

- Updated.
- Yes, it will update everything that is possible! You did not change a single byte on this computer, but the whole world changed, so you have to update the software. Architecture is a living organism, it is not enough to build it, you need to make it work, and you also need to allow it to be updated and developed, which is exactly the idea of ​​evolutionary architecture. It is alive, and even if you do not change it, the whole world in which it is located will change: a new version of Docker or something else will be released, something can break or change from this. And you know about the possible risks if you do not start updating your systems, they will become obsolete and further it will be even more difficult to update them.

Actually, I mean that software systems are living organisms, and you need to work first, and then support their whole life.

- Thanks for answers. See you in Petersburg!

Neil will perform at the Heisenbug , which will be held in St. Petersburg on May 17-18 , with a report "Building evolutionary architectures: Fitness functions". Besides him, many other reports are already known: you can see their descriptions on the site , purchase tickets in the same place.