Mark Richards – Will there be software jobs when you graduate?

Codecamp România organized last week in Iași an interesting talk together with the local university. They have invited Mark Richards to talk about “Will There Be Software Jobs When You Graduate? AI, Hiring Trends, and the Future of Software Careers”. The original talk was supposed to be held by James Coplien but his flight was canceled so Mark stepped in to help. 

Mark Richards is an important worldwide software architect who published important books on software architecture: ‘Fundamentals of Software Architecture: A Modern Engineering Approach’, ‘Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures’, ‘Head First Software Architecture’, ‘Architecture as Code: Specifying Architecture for Humans and Agents’, ‘Software Architecture Patterns, Antipatterns, and Pitfalls: Understanding Trade-Offs‘(just released). Please see https://developertoarchitect.com/books.html for all the books he has written.

He has been in this industry since 1983. And he is still coding almost every day.

I made a post on LinkedIn that evening about the talk and I felt the need to extend a little bit more because it was an interesting presentation: https://lnkd.in/p/dF6FcAvB 

Seeing such an important person from IT going to the heart of Romanian education, a Romanian school, touched in me a sensible cord. And I told this to Mark. 

So, here are the main ideas that I recall from his talk which I think are very important:

Time

He said that he had a lot of time to prepare for his career, a lot of time. He started as a programmer and gradually over 12 years he got his first job as a software architect.

Then he said to the students that maybe they will not have those 12 years, but perhaps 2 or 3 years at most, in order to get a comparable experience because things are so accelerated now. 

Karma

He quoted an idea from Venkat Subramaniam. The fact that programmers write bad code. He also admitted to writing bad code. Well … we all wrote bad code. But, AI is trained on code written by programmers. Then programmers complain that AI writes bad code. “Guess what? This is karma”.

Dreyfus Model for Knowledge Acquisition

Dreyfus Model for Knowledge Acquisition in the context of AI and IT

The Dreyfus model is being used to describe stages of knowledge acquisition. And he centered the discussion around this.  

He said that a novice applies recipes and follows step-by-step instructions.

The next level in the Dreyfus model is the advanced beginner. In this stage an advanced beginner is applying more complex recipes, but they are still recipes.

The next level is competent. The competent are still following recipes and still doing analytical thinking but they begin to be more creative with their thought process. If something is not ok they can apply other techniques to fix that particular problem. 

He then went to describe the proficient and expert stages. He mentioned that the experts create the recipes.

In the context of AI this Dreyfus model is important because it helps to show where, most probably, AI agents are now: at the border between advanced beginner and competent. These agents are recipe followers with no creative thought. 

But Mark also spoke about RSI (Recursive Self Improvement). It is about agents recursively starting to improve themselves. He thinks that, because of RSI, AI might get to the competent level. But he also expressed his skepticism when he invited us to think about all the problems that can pop up while AI will do its learning via the RSI. 

Picasso Quote

Picasso Quote

Mark liked this quote because it shows the importance of good new questions, ideas.

Computers are deterministic, and that LLMs have non-deterministic responses.

Then he mentioned the fact that computers are deterministic, and that LLMs have non-deterministic responses. And that LLMs can help with good questions. 

He mentioned that AI is and should be seen as a tool. Is a tool that accelerates code generation and that also gives great questions and great ideas. 

Behaviour and Capabilities 

Behaviors and Capabilities in Software Architecture

For Mark, behaviour is about design. In the image it can be seen that usually when trying to design for the behaviour, programmers start from something simple and then gradually arrive at the desired thing. In the image it can be seen that the truck is the goal. 

He said that the AI can write code regarding the behaviours, and he also says that it is bad code. And even if it is bad code, it will still work.

But there is another important detail, which is about the capabilities that architecture must provide. In the example from the image it can be deduced that the capabilities needed for a truck will for sure not map at all to the ones needed for roller skates.

Here are some examples of capabilities provided via some questions by Mark: Do we need to scale to 100,000 users?  Do we have to have response times in our systems of under 200 milliseconds? Does our system have to be highly maintainable? 

Then, on the next slide he provided a long list of all the capabilities that can be considered for a system:

List of all the capabilities the architecture must provide

And it is in these capabilities, Mark says, where the opportunity for programmers lies. Because the AI is not good at these, even though the AI is good at producing code.

You can emerge design, but you cannot emerge architecture.

Gall’s Law

Gall's Law

Gall’s law can be applied to software architecture and is a very needed skill to have as a programmer. We need to start with a simple system, but we have to plan. Because it is not that we can just simply add an architecture. He gave the example of building a very simple system that will scale to 100,000 users and that we will continuously verify it. Now that there is a simple system that works, the emergence of the design starts.

So, AI is currently lacking architecture. And it will be onto us to teach the agents architecture, and for doing this we need to know architecture.

He has also shown some examples of Architecture Definition Language (ADL).  The ADL’s are a new way to describe architecture through a pseudo-code language.(1) He is using ADL and the generated code after it, with AI, in order to validate architectures. There are great advantages in using this language in connection with LLMs.

I recall that he used an example from his class regarding a ticketing system and how he used ADL’s to describe its architecture and how actual code can be automatically generated with Claude.

So, ADL can be used to describe the architecture, but also to validate it with code via agents. And programmers can play a very important role here.

He mentioned that the traditional role of a programmer is moving from writing source code toward architecture and design. 

Increase your technical breadth of knowledge

Increase your technical breadth of knowledge

At a certain moment he explained a hypothetical scenario where a programmer said that is an expert in micro-services but is struggling to find work. And is asking Mark why it is hard to find a job. And Mark’s answer was: The problem is you are an expert in microservices. And the same for a lot of other people that are competing with each other for 3 or 4 open positions. It is about how a programmer will differentiate herself/himself in the industry, and architecture is a differentiator and can help.

Communication and collaboration skills also matter a lot. His book ‘Fundamentals of Software Architecture: A Modern Engineering Approach’ addresses all of the people skills needed for a programmer.

In the previous image Mark is showing a triangle. He is using it as an analogy that represents all the knowledge in the world. On top are the things we know and we are experts in. In the middle of the triangle is about the things we know we do not know. At the bottom of the triangle is about the stuff we do not know that we do not know. It is about the things we never heard of. 

He insists on increasing the breadth of our technological knowledge. He advises to place our focus in the middle of the triangle. And that we can do this by investigating various resources like infoq.com or https://www.thoughtworks.com/radar. He advises to spend at least 20 minutes per day in the morning, but before opening email and MS Teams or the social media, and after the ‘blessed’ coffee or tea. 

Increasing our technical breadth is a differentiator in this new state of the industry.

Advice

Do not take as face value all the code that is being generated. Trust, but verify. The code might work, but once modified the behavior might change and it will no longer work.

As developers we will need to deeply verify the code that we did not write.

Ethics 

No one talks about it. Who is teaching our agents about ethics?

After his talk, I made the following question and comment on which he agreed:

– Isn’t, in a way, that this AI triggered us to return to the essentials, for what it meant for us to be programmers? Because it was never about just knowing C++ or Angular  syntax, tips and tricks. It was about solving some problems. So, it seems to me that the good thing about AI is that it triggered this aspect.

When answering my question he said so nicely that it’s not about the syntax of the languages. It never has been. It’s about how to program, how to think about algorithms, and how to solve a particular problem. That it really is getting us back to some of the essentials. Rather than focusing on all the languages and the problems of code syntax, we are solving problems.

Then he did an interesting thing. He said that initially he programmed in assembly language, then C and C++ , then Java, and then he had to handle the cloud. And suddenly he made me think about the leaky abstractions and how important it is to be careful at them. Because we have abstractions over abstractions, for example cloud environments abstract us from the infrastructure. We have no idea where the code is running.

– It seems to me that AI has raised the bar. It doesn’t mean we shouldn’t know things. It’s related to the time it took you to become an architect, 12 years. It raises the bar and it also pushes and hurries us to learn things faster. It doesn’t make us abdicate on knowing those things.

And he exclaimed: Bingo! And then asked how many bits in a byte? How many bytes in a word? Like an invitation to realize that we need to know our craft as computer scientists.

We are living interesting and challenging times. And Mark’s talk is helping, I believe, us navigate uncertainty whether we are students, juniors or experts.

Important note: The images were used with permission of Mark Richards. 


(1) Lesson 210 – Architecture Definition Language – (August 4, 2025) – https://developertoarchitect.com/lessons/lesson210.html 

About microservices and software architecture

This topic of microservices continues to pop-up in my professional activity. 

I remember that some time ago, I heard James Coplien say in a video something like “Microservices…don’t let me start with this”. I wanted to decipher this. Because of that, I re-read his wonderful software architecture book(1) and all of his OOP materials (2).

Small note: I tried to find again the initial video and no luck. Still the words remained in my head. After James reply I realized that I was not off track with my memory.

I have to say from the beginning that this trend regarding microservices is becoming rather dangerous (maybe because of wrong focus or  because of misunderstanding of what software architecture really is or because it is not known what OOP actually is or …). I usually say to my friends, colleagues the nightmare we will have in 10 years or so when we will have to maintain the so-called microservices approaches.

What James Coplien said in that video and how he said it hunted me. Then, suddenly, I have found a way to decipher/decompress what he said when I read the paper “The DCI Paradigm: Taking Object Orientation Into the Architecture World”(3). Below are fragments from the article which triggered my thoughts/perceptions/insights:

● “…The authors have been working on a paradigm called DCI(Data, Context and Interaction) that places the human experiences of design and use of programs equally at centre stage…” ➜ Is hard to do that with microservices, they are not about humans at all. The way the subject of microservices is put on the scene is not about human experience at all.

● “…Architecture is the form of any system created through conscious design, and it thus has strong human elements both in its process and its product.The term form implies a deep mental model of the essence of some Structure…” ➜ With microservices it is hard for me to see the holistic form of the system, that’s why I can’t see microservices as architecture. For me is about some low level technical details and about deployments. 

●“…Form is the deep essence of what is common between these systems, just as Victorian architecture is the essence of common elements across innumerable houses…” ➜ Here is mentioned the Victorian style, but I thought of the Romanian style named Brâncovenesc(4). James and Trygve are right. When I look at the houses, churches I can say that it is about the Brancovenesc style and I can see that it is different from Victorian style. So, when I look at an HR application or Planning events application I should see that form which speaks about that kind of application. And the fact of what iron or cement was used is another story. I think with microservices it is hard to see the forest from the trees.

●“…Why do we do architecture?It might be useful to revisit some of the key goals of architecture. As mentioned above, Vitruvius reduces the purpose of architecture to utilitas(commodity or utility), firmitas (firmness) and venustas (delight). These goals echo strongly in software, which has adopted them with its own emphases. More broadly, architecture is, and always has been about form. Except among specialists, the English word form is often confounded with structure, and software folks in particular often incorrectly infer that a system’s architecture is the structure of its artefact. The proper architectural usage of the term form has historically been more precise. It’s important to differentiate form from structure: Form is the essence of structure. We can talk in detail about the form of gothic cathedrals even without having a gothic cathedral at hand. Form is the conceptualization of structure in terms of the relationship between parts, and between the parts and their environment. Many given structures can implement a given form, just as there are many (different) gothic cathedrals, all of which implement the forms of gothic cathedrals…” ➜ So, maybe, microservices came with a “structural” flavor and also a simple mechanism of sending/receiving data.

●“…SOA defined services, but at a level that was usually far removed from the code; it is probably a better metaphor for urban planning than for the architecture of a house…” ➜ Yes indeed, this SOA stuff was at the far extremity of the code, just a simple entry point in the system, but nothing else. I was amazed to see whole books regarding how to explain these endpoints and how the entire code structure has been influenced and is not ok. 

● “…This may well be because great architectural talent arises from domain knowledge, and it’s difficult to treat architecture as a generic discipline within the (generic) discipline of programming. In the end, architecture has arisen as a generic discipline of tools rather than the result of a quest for beauty and utility…” ➜ The knowing of the domain and its importance is diminished because all the discussions focus on the hammer, scaffold,..

I asked James Coplien to help me out. I really needed his help. He was very kind to review and give me feedback about my insights:<< “Yes” to all of your insights. The main one that bothers me is the lack of a coherent system overview. All understanding is local and the system behavior is taken to be emergent. That doesn’t work except at incredibly large levels of scale and scope.>>(5)

After his feedback I had the pleasure and honor to meet him in person, in Athens. I had participated in 3 of his wonderful trainings about Scrum – a blog post will soon come about this. I hope that soon I will also participate at his DCI training. I am waiting for this DCI training for a very very long time – sometimes I feel this is an impossible dream. Actually, one important reason I decided to have the Scrum trainings with him was the hope to have some minutes with him to discuss about architecture and OOP and it worth it.


(1) James O. Coplien, Gertrud Bjørnvig, “Lean Architecture: for Agile Software Development, https://www.amazon.com/Lean-Architecture-Agile-Software-Development/dp/0470684208/ 

(2) James O. Coplien, “Publications”, https://sites.google.com/a/gertrudandcope.com/info/Publications

(3) James O. Coplien, Trygve Reenskaug, “The DCI Paradigm: Taking Object Orientation into the Architecture World”, https://doi.org/10.1016/B978-0-12-407772-0.00002-2

(4) “Brâncovenesc style”, https://en.wikipedia.org/wiki/Br%C3%A2ncovenesc_style 

(5) Text used with permission (March, October 2019)