Felienne Hermans' keynote<\/h2>\n
The closing keynote on Wednesday was held by Felienne Hermans<\/a> and titled 'AI made me doubt\neverything about programming'. She talked about how tech has never been neutral, how in tech solutions that are hard are\nwrongly seen as more prestigious than things that solve actual problems, how tech needs to revolve more around people\nand that we do not need to use tools just because we can. She criticized the tech industry and called for more feminism\nand less AI. The topic was very relevant to me and I could relate to her experience. But even people who didn't agree\nwith\nher were praising the talk for how it was delivered. Felienne even received a standing ovation.<\/p>\n It is not usual that the use of AI is criticized at conferences, especially in keynotes. I also appreciated that there\nwere a lot of talks that did not revolve around AI. It was still a topic, of course. Even among those who are still\nexcited, everyone seemed to agree that there is a major economic AI bubble.<\/p>\n Felienne also talked about knitting (and mentioned my talk!) as an example of something complicated that does without\nalways keeping up the impression of being something really hard. Maybe because it is mostly done by women.<\/p>\n On the second day I mostly attended workshops. I learned about the Liberating Structures concept and applied it to DDD,\nfacilitated by Xin Yao and Martin G\u00fcnther<\/a>. That was fun and a little\nuncomfortable (in a good way!). I had great discussion and really enjoyed the company of the people I work-shopped with.<\/p>\n The second workshop I attended that day was held\nby Krisztina Hirth<\/a>, Kenny (Baas) Schwegler<\/a>, Henning Schwentner<\/a>\nand Maxime Sanglan-Charlier<\/a>. We explored different collaborative modeling\ntechniques. I joined the svent-storming group, facilitated by Krisztina. Of course, my group came up with objectively\nthe best\nsolution. Not that it was a competition :D.<\/p>\n The closing 'keynote' this day was an on-stage-conversation between Martin Fowler<\/a>\nand Eric Evans<\/a>, moderated\nby Gien Verschatse<\/a>. It drifted toward agentic coding pretty quickly and didn\u2019t reveal\nmuch that would be new to someone who reads Martin Fowler\u2019s blog regularly.<\/p>\n Michael Feathers<\/a> opened the conference on the last day. He talked about how we\ngain skills and how those skills fade when we don't use them. He said that you cannot verify something without\nunderstanding it first. Michael gave some examples of how to use AI to verify and deepen your understanding.<\/p>\n Next on the main stage was Susanne Kaiser<\/a>. She reminded us that we still need to focus on\nbuilding the foundations for continuous change. She talked about architecture for flow and the guardrails for continuous\nchange, none of which is new (her words, but also mine).<\/p>\n William Bartlett<\/a> gave advice and insight for when the ubiquitous language isn't\nEnglish. The talk was helpful and inviting. I attended because this question has been coming up for me repeatedly. Fun\nfact from my experience: 'get' in Swedish means 'goat' in English. So writing getNamn() can be read goatName().<\/p>\n Frances Sun talked about how unintuitive UI is often the result of unclear processes and fuzzy domains. And just making\nthe UI prettier does not address the real problems.<\/p>\n Diana Montalion<\/a> gave the closing keynote. She talked about knowledge flow, about how\nwe are transitioning toward building knowledge systems, and about why we should value knowledge and learning more\nhighly.<\/p>\n I met lots of interesting and kind people. As with most conferences, I had FOMO all the time because I was missing out\non great talks and workshops while I was listening to other talks and workshops. So if a talk is not on this list, it\nsimply means I didn\u2019t attend it because I chose to listen to something else.<\/p>\n I cannot think of a single thing that went wrong during the conference. I don't think I saw anyone who was stressed\nout (apart from the speakers!). The whole conference just worked. The communication with the team was excellent.\nEven when my flight was canceled, Anneke and Ilse set out to help immediately with the hotel booking. Pulling this\nconference off must have been an immense amount of work, and they made it look like it was nothing! Thank you!<\/p>\n Both food and drinks were great, I think it was a great choice that everything was vegetarian and the drinks served\nduring the social events were alcohol-free.<\/p>\n The venue was very carefully selected as well. It was right next to the train station and the hotel. The size was ideal\nand the rooms beautiful and well-prepared.<\/p>\n Next year the conference will take place in Amsterdam again. I hope to see you there!<\/p>\n"},{"title":"Isn\u2019t an e-shop enough?","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/isn-t-an-e-shop-enough\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/fT3ZU6JreB-1024.jpeg"}}],"updated":"2026-06-11T00:00:00Z","id":"https:\/\/factor10.com\/news\/isn-t-an-e-shop-enough\/","content":" For a start, both an e-shop and a solution configurator are very much about self-service, no difference there. It\u2019s simply reasonable and expected for most customers to be able to do as much as they want on their own, and that definitely goes for designing and ordering their solutions. If they can\u2019t, they might go somewhere else.<\/p>\n Both can be strategic initiatives, but one is more about hygiene and one is more about differentiation. To explain the difference, we'll look at a typical journey for a product-oriented company through the lens of strategic direction \u2014 using the Value Disciplines triangle above.<\/p>\n This triangle illustrates a company\u2019s strategic direction at a given point in time.<\/p>\n The evolution of a product company over a few years might look like this.<\/p>\n Most companies start here, it\u2019s essentially the birth reason for the company. A really good product will sell itself to some degree, even if customers have to find it and figure out how to use and buy it. It doesn\u2019t scale well, but it\u2019s a start.<\/p>\n This phase is about Product Leadership.<\/p>\n A possible next step is to scale sales by letting customers order through a digital portal. In many industries this is a hygiene factor, something customers expect. And, when your customers know exactly what to get, an e-shop is very cost efficient for sales.<\/p>\n This phase is about Operational Excellence.<\/p>\n The next step might be to provide a self-service solution configurator, built around your specific product logic. That way, the customer, who knows most about the situation and problem, can to a large extent design the solution themselves. Of course, with as much guidance from a sales person as they want or need.<\/p>\n We think of this as an extension of the product itself, making it better and more relevant for the users. So in this phase the focus shifts back toward Product Leadership.<\/p>\n In this phase, customers can order genuinely customised products, not just a configured assembly of standard components. The possibility for customisation is mainly driven from the specific needs of your larger customers, one at a time.<\/p>\n The focus is still Product Leadership, but with a tilt toward Customer Centricity.<\/p>\n This is intentionally a simplified picture. There are numerous reasons your situation might look different.<\/p>\n For example, the order between phases may vary, or even overlap. For some companies neither will ever happen, for others all four will, but in a different sequence. It\u2019s common, for instance, to swap phases 2 and 3: building a solution configurator first (that can, of course, also be used to order) and adding an e-shop later to make ordering spare parts or restocking easier for customers.<\/p>\n Another factor that totally changes the picture is if your products are used in isolation rather than as part of a customer-specific system. In those cases, the solution configurator path probably isn\u2019t relevant at all.<\/p>\n So, to come back to the original question \u2013 isn\u2019t an e-shop enough? The answer depends on whether your current strategic direction involves looking for differentiation or not.<\/p>\n If you would like to explore what a Self-service Solution Configurator<\/a> could do for your business, we offer a three-hour workshop<\/a> to help you discover the potential value \u2013 either remote or in-person. Don't hesitate to get in touch!<\/p>\n"},{"title":"From military to civilian use","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/from-military-to-civilian-use\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/GhgaQCtrlX-1024.jpeg"}}],"updated":"2026-05-14T00:00:00Z","id":"https:\/\/factor10.com\/news\/from-military-to-civilian-use\/","content":" As a matter of fact, I think we are very much affected in the civilian world by military thinking, just look at the business language as an example. I\u2019m not saying that we are all using those phrases all the time, but they are common. I\u2019m thinking about phrases like \u201cland and expand\u201d, \u201con the frontline\u201d and \u201cdivide and conquer\u201d. But that wasn\u2019t too helpful, more like jargon.<\/p>\n Something truly useful in my opinion was when I first read the book \u201cThe art of action\u201d by Stephen Bungay and started applying some of its concepts. It\u2019s a very interesting and inspiring book overall, for example regarding leadership. When I first read it, Many of us were trying to make microservices work well in appropriate settings. The seminal paper Microservices by James Lewis and Martin Fowler was released 2014 and that was very helpful. Then I got an epiphany moment by Stephen\u2019s book, when I realised that an influential part of the military world had known how to organise for microservices (at least the coarse grained-\/bounded context-style) in...150 years! Totally mind blowing!<\/p>\n Let\u2019s have a quick look at three of the many important areas of the book.<\/p>\n Bungay identifies three gaps which are seen in every complex organisation:\nThe knowledge gap, that the top leaders don\u2019t know enough of the reality below them, at least not how it is right now<\/em> when things have changed. Or in a minute, or\u2026 Therefore they can\u2019t know what should be done.\nThe alignment gap, what is ordered is not what will be done.\nThe effect gap, what is done won\u2019t lead to the expected results.\nA solution to this is that responsibility needs to be decentralised in a good way to where the action is. Mission command can be the method.<\/p>\n For mission command to work, there must be alignment on the purpose and the goals. Only then can autonomy be used in a good way. The autonomy also requires strict borders with clear responsibility and constraints. Paradoxically, that creates freedom and an environment for effective action.<\/p>\n Finally, the book discusses a template for strategy briefing. Used well, it\u2019s brilliant in providing just the right information of a directive, without a single word too many. As we all (I at least) know, clarity doesn\u2019t necessarily increase with more words.<\/p>\n This article has also been published on LinkedIn. Join the discussion here<\/a>.<\/em><\/p>\n"},{"title":"Tips for developers on improving collaboration with domain experts","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/tips-for-developers-on-improving-collaboration-with-domain-experts\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/gC1QAcgOzA-1024.jpeg"}}],"updated":"2026-04-22T00:00:00Z","id":"https:\/\/factor10.com\/news\/tips-for-developers-on-improving-collaboration-with-domain-experts\/","content":" A domain expert isn\u2019t just anybody who can do the job you need to know more about. A domain expert has thought so much about it, has so much experience, and has developed an understanding at a meta level. A domain expert can even think about how a machine should work to do the job (as Dan Bergh Johnsson puts it).<\/p>\n So they are rare, and when we find one, our success depends on our collaboration.<\/p>\n Yet over the years, I've often heard developers say that they can't get any time or attention from their domain experts. When I hear that, I suspect two different reasons. It might be that the domain expert doesn\u2019t think the initiative you're working on is important. If that\u2019s the case, run away. There's little chance of success, and why would you or the company spend development effort on something that isn\u2019t important?<\/p>\n The more probable reason, though, is that you are... boring. I know, that was a very blunt, but I got your attention, didn\u2019t I? And I\u2019m looking at myself as much as anyone else. I\u2019ve done it, I\u2019ve been so boooring. Going into a domain expert's room and saying things like repository, higher-order function, and closure of operations\u2026 They tune out after the first word when we only speak geek. And that\u2019s just one of the errors we make.<\/p>\n Anyway, the moment we realise that a problem is our<\/em> fault is the moment we start solving it. As the saying goes, it\u2019s enormously easier to change yourself than to change someone else! I always feel happy when I realise it\u2019s my fault. Then I\u2019m in control and in charge. Things can start rolling!<\/p>\n So let\u2019s just assume it\u2019s your fault that the domain expert is a bit hesitant about collaborating. What can you do about it? Over a series of LinkedIn posts \u2013 and with a lot of great input from the community along the way \u2013 I collected 15 tips. (As a matter of fact, most of them are generic and can be used in everyday life, but I\u2019ve especially put them to use in software development situations.)<\/p>\n Here goes\u2026<\/p>\n If I had a Euro for every time I\u2019ve heard someone describe a problematic situation with \u201cwe don\u2019t speak the same language\u201d, I\u2019d be rich by now. :) It\u2019s annoyingly common and often true. If only there were a solution to this problem!<\/p>\n If you\u2019ve come across DDD, you\u2019re probably familiar with the concept of \u201cubiquitous language\u201d. Trying to apply it together with your domain expert is as obvious a tip as it is helpful. I wrote a bit about the power of sharing a language in an old post<\/a>. It\u2019s still a good reminder to myself that the power is almost scary, and should therefore only be used for good.<\/p>\n Understanding the domain expert is absolutely crucial since without first understanding, it won't be possible to collaboratively develop the new thinking that is needed. To understand, it\u2019s not enough to listen and capture; you need to really get why<\/em>. That said, there's a risk of overusing that word in conversations, and when that happens it can start to feel almost like an attack.<\/p>\n If you notice you\u2019re whys<\/em> aren\u2019t received well, try switching tactics. Instead of just asking why, try describing your current understanding, preferably using a concrete example. This often changes the dynamics in the room!<\/p>\n If you didn\u2019t understand because you were talking past each other, now there\u2019s something to gather around. Your description will almost certainly contain a few errors, but that\u2019s actually a good thing. It makes misunderstandings visible and helps the domain expert see exactly where clarification is needed and what to focus on next.<\/p>\n Let go of your pride and ask the questions you\u2019re afraid will sound really stupid. Showing that kind of vulnerability can be very effective for changing the atmosphere in tense situations. More often than not, it also helps someone else in the room get a new idea. And it might not be a stupid question at all, that\u2019s impossible to know beforehand.<\/p>\n What often stops us from using this tool is the fear of letting others see that we don\u2019t get it yet. But you should optimise for understanding, not for looking smart or seeming like you already know everything.<\/p>\n Goldratt says it well in The Choice<\/em>: \u201cWe need humble arrogance. Be humble to assume that one doesn't know. Be arrogant \u2013 have the confidence that one is capable of figuring it out.\u201d<\/p>\n Pippi Longstocking says something along the lines of \u201cI\u2019ve never tried that before, so I\u2019m probably very good at it\u201d, but that might be taking it a step too far.<\/p>\n You\u2019re trying to create a shared mental model together, and different ways of doing this will suit different domain experts more or less well. It\u2019s also highly contextual.<\/p>\n Sometimes it helps to sketch on a whiteboard. Sometimes it\u2019s enough to talk and really play with the words, evolving the ubiquitous language together. Sometimes writing text together works best, or sketching a user interface. And don\u2019t forget code, it can work like a charm too.<\/p>\n Another powerful shift is to move back and forth between looking at the big picture and diving into the details. It\u2019s also helpful to alternate between abstract models and concrete examples.<\/p>\n It\u2019s not just about finding the right tool for a specific domain expert. It\u2019s about viewing the concept you\u2019re working on from multiple angles. When you get stuck in one, switch to another.<\/p>\n The sub-domain you are working on together with the domain expert doesn\u2019t exist in isolation. Make sure you understand how it fits into the broader business strategy of the company, and how it connects to its core objectives. If you, for example, believe you\u2019re working in the core sub-domain when it\u2019s actually a generic one, misunderstandings are bound to happen.<\/p>\n Earlier, I recommended asking \u201cstupid\u201d questions \u2013 and I still stand by that. But be mindful not to exhaust domain experts with repeated questions about the basics. Doing some reading before and between conversations will definitely be helpful, and it\u2019s also a matter of respecting their time.<\/p>\n If the domain expert notices that you are making a real effort, they're more likely to meet you halfway.<\/p>\n A good starting point is to ask what book students would be given in an introductory course on the subject. Or maybe there are lectures, talks, or other resources that would suit your way of learning better?<\/p>\n It is worth remembering that in most cases you do not need to become<\/em> a domain expert \u2013 you just need to be able to understand one.<\/p>\n 4-6 are inspired by Tobias Fors, Nyari Samushonga, Patrik Fredriksson and Gregory Young.<\/p>\n<\/blockquote>\n Of course you say thank you when someone helps you. We all do. Still, it\u2019s worth being very explicit about.<\/p>\n Saying thanks is about respecting someone\u2019s time. It\u2019s about showing appreciation for their work, their expertise, and the insights they share. If a domain expert takes time out of what was supposed to be spent on something else to help you understand a tricky concept \u2013 and doesn\u2019t even get a thank you in return \u2013 that doesn\u2019t exactly set things up nicely for the next session (if there will even be one).<\/p>\n Also, be explicit internally in the organisation about who has helped you with what. That\u2019s not just nice, it helps others in the organisation understand who is worth turning to for help.<\/p>\n 7 is inspired by Katharina Damschen.<\/p>\n<\/blockquote>\n A simple communication technique that can be very powerful in certain situations is to act like a mirror. When a domain expert explains something important and complicated to you, try repeating it back to them in your own words, based on how you understood it.<\/p>\n First of all, it\u2019s a good way for you to deepen your understanding and gives you a chance to validate that you actually got it right. At the same time, the domain expert feels heard, which in itself has positive effects, both in the moment and over time.<\/p>\n Finally, for those of us who have that lovely, automatic impulse to jump straight to problem-solving, this tip will help you pause that default behaviour for a moment. Sometimes the most helpful thing you can do is to stay with them<\/em> for a bit longer, rather than rushing back to you<\/em> and your ideas!<\/p>\n I suspect this tip may be as challenging for some you as it\u2019s been for me. I still struggle with this, very often. But trust me, it can be extremely helpful!!!<\/p>\n 8 is inspired by Lotta Nilsson<\/p>\n<\/blockquote>\n Another communication technique I find very useful is to talk in four dimensions by explicitly describing:<\/p>\n This creates a much richer picture for the person listening, and is typically received quite well.<\/p>\n It\u2019s especially powerful in situations where simply describing what you observe tends to create friction, for example, when the receiver experiences it as an attack.<\/p>\n Even though I\u2019ve known about this approach for a long time, and used it with good effect on many occasions, it still doesn\u2019t come naturally to me. The good news is that if a conversation didn\u2019t go well the first time, you can usually go back and ask for a new try. You don\u2019t just get one chance; try again, but change something.<\/p>\n You can read more about this in the book Clear Leadership by Gervase Bushe.<\/p>\n It\u2019s good to act a bit like a crocodile: small mouth, big ears. But it\u2019s a misunderstanding to think that your job is simply to listen to the domain expert and capture everything they say.<\/p>\n A good conversation isn\u2019t just one-way. For it to be useful, it needs to be a dialogue. For example, your experiences from other domains and situations are often highly interesting to the domain expert (when shared at the right moment) and can help them rethink aspects of their own domain.<\/p>\n If you started out knowing exactly the same things as the domain expert, the collaboration would be pretty useless. Celebrate your differences and be generous about sharing them.<\/p>\n Also, listen to what is said between the lines. If the domain expert doesn\u2019t understand something when you try to explain it, that\u2019s a strong signal that you might have misunderstood. And that\u2019s actually a very good thing. Lack of understanding is an invitation to dig deeper \u2013 and might be the start of a real breakthrough!<\/p>\n Wanting to belong is a deeply human thing, and it applies to both you and the domain expert. So, it\u2019s worth considering how you can create that sense of belonging together.<\/p>\n Try not to see your conversations as transactions. Think of them as the start of a relationship instead. It might seem like you don\u2019t have much in common at first, but in my experience, it often turns into something surprisingly fun and meaningful over time!<\/p>\n This tip is actually quite simple: treat the domain expert like a human. Talk about other things now and then, share a bit about yourself, listen carefully even when it\u2019s not about the domain, grab lunch or have a coffee together. Nothing fancy, just normal, human stuff!<\/p>\n When you start working with someone new, take a moment early on to understand their goals and values. If you\u2019re aligned, there\u2019s usually a solid foundation for trust. If you're not, that's genuinely useful to know early.<\/p>\n The mistake I keep making is assuming everyone shares the same outlook as me and is naturally pulling in the same direction. But people come with different backgrounds, priorities and ideas of what \u201cbetter\u201d looks like.<\/p>\n A good starting point is to identify one shared outcome you can both agree on, something concrete and simple. Something you both find valuable, even if you don\u2019t share all the same values. Start the session with the mindset \u201cwe all want to make things better\u201d.<\/p>\n 11 and 12 are inspired by Suzi Edwards-Alexander.<\/p>\n<\/blockquote>\n Kenny Baas Schwegler wrote a post<\/a> about that the situation might not be optimal for a group to come up with the best ideas. Rank, experience, reputation, personality, etc lead to a dynamic that always favors the same few people. The best ideas might not even have been articulated...<\/p>\n This probably needs a book on its own, but I know that Cecilia Hilton would suggest the two first here:<\/p>\n Writing scenarios in the style of Behavior-Driven Development (BDD) (created by Daniel Terhorst-North) definitely have large value in itself as documentation and as automatic tests. But the biggest value as I see it is in the discussion between domain experts and developers.<\/p>\n It can be a powerful icebreaker. You write three words on the whiteboard, and then somebody says that \u201cwe actually don\u2019t call them customers, rather\u2026\u201d. The person asks for the pen and continues writing. The discussion is started and work of evolving the ubiquitous language is on.<\/p>\n Don\u2019t take my word for it, it must be experienced!<\/p>\n Your mindset should always be curiosity and a genuine desire to learn, not letting thoughts like \u201cthat seems stupid\u201d through. Goldratt gives clear advice on this in \u201cThe Choice\u201d: beware of derogatory thoughts. It\u2019s a trap, a really bad one! Your thinking will create<\/em> the situation you were thinking about. If you are aware that derogatory thoughts are a trap, it gets easier to recognise them and see them as what they are: just a stupid thought on my part.<\/p>\n Why it works to have a curious mindset, I think it\u2019s because when you continue investigating what seems stupid, you reach understanding and understanding is the cure! A lack of understanding, well then most things seems stupid.<\/p>\n Related to this, Suzi Edwards-Alexander mentioned \u201cfundamental attribution error\u201d. The solution is to focus on the behaviour, not the person. I guess this is useful for tips 13 as well.<\/p>\n Dan North mentioned the following great tips in the comments, when I shared these tips on LinkedIn:<\/p>\n For 14 \u2013 Language as an icebreaker, two concrete examples I've experienced:<\/p>\n When I posted these tips three at a time on LinkedIn, I got a lot of good book suggestions. Those are still on my TODO list, but I'm quite sure I'll have more tips to share further down the line. For now, 15 (or 17?) will have to do. Oh, and please don't hesitate to ping me with more ideas!<\/p>\n"},{"title":"Why is it so hard to optimise software delivery under stress?","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/why-is-it-so-hard-to-optimise-software-delivery-under-stress\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/yIhfHzC7cD-1024.jpeg"}}],"updated":"2026-04-07T00:00:00Z","id":"https:\/\/factor10.com\/news\/why-is-it-so-hard-to-optimise-software-delivery-under-stress\/","content":" When a software team is under sustained delivery pressure, the things that would actually improve performance get deprioritised in favour of the things that feel like progress: flaky builds get worked around rather than fixed, test suites get slower and developers start skipping them locally, architectural decisions get deferred, and the pipeline accrues small inefficiencies that nobody has the time to clean up. Each of these is a small daily tax on the efficiency of every developer.<\/p>\n Stress makes this worse. When cognitive load is high, people optimise for the short term. They find workarounds and learn to live with the pain. Over time, the friction becomes background noise, invisible precisely because it's always there. The team isn't slow because people aren't working hard enough, it\u2019s slow because the environment they are working in is generating drag, and nobody has the bandwidth to remove it.<\/p>\n The reflex response to a delivery shortfall is to hire. Brooks identified the flaw in this thinking 50 years ago in The Mythical Man-Month<\/a>: adding people to a late project actually delays it further. The onboarding cost, the communication overhead, the ramp-up time \u2013 all of it creates more drag before it creates any lift.<\/p>\n But there's a subtler version of the same mistake that doesn't get talked about as much. Even experienced new hires, who ramp up quickly and start shipping code, are forced to focus on the features. Instead of fixing the underlying friction, they inherit it: working around the same flaky builds, running the same slow test suite, and operating in the same suboptimal architectural context.<\/p>\n The alternative might seem counterintuitive, but the Theory of Constraints<\/a>, Lean manufacturing<\/a> and Team Topologies<\/a> all point to the same insight: in any system under pressure, the constraint is almost always flow, not raw capacity. Adding people doesn't fix a flow problem. Finding what's blocking flow and removing it does \u2013 and that's a different kind of work entirely.<\/p>\n Instead of asking "who do we hire?", a better question would be "what would we need to fix to make the people we have much more effective?" The answers tend to be specific and concrete: a flaky test suite that takes 20 minutes to run, a build pipeline that's become a queue, a deployment process full of undocumented manual steps, an architecture that makes every new feature disproportionately expensive.<\/p>\n None of these are critical issues on their own, but in combination, they have a severely negative effect on everything the team does.<\/p>\n Most teams know what needs doing, they just can't allocate the time to do it. When a team is under delivery pressure, improving the system competes directly with delivering features for time and attention. Feature delivery has visible stakeholders, clear deadlines, and immediate accountability. Friction removal has none of those things. It's important but never urgent, right up until the point where it becomes a crisis.<\/p>\n There's also a skill dimension. Finding and fixing systemic friction requires a specific kind of experience that most delivery teams don't have as a core competency, and under pressure they can't afford to develop it.<\/p>\n So the friction compounds, slowly at first, then faster. And as agentic coding becomes part of the workflow, the problem accelerates: AI-assisted development amplifies whatever environment it operates in, good or bad. That means a high-friction codebase doesn't get better when you add AI to it \u2013 it gets worse, faster.<\/p>\n There's a reason Forsgren, Humble and Kim used delivery performance as the central metric in Accelerate<\/a>. Their research showed that deployment frequency, lead time, change failure rate and time to restore predict the organisation\u2019s business performance and employee wellbeing.<\/p>\n Flow isn't just a productivity metric, it's a signal of whether developers are able to do good work in a sustainable way. Teams in high-friction environments don't just ship slower, they also burn out faster, make more mistakes and leave sooner. In this sense, reducing friction is just as important for talent retention, quality and morale as it is for efficiency.<\/p>\n Stress is precisely the condition that makes friction removal hardest to prioritise. When a deadline is looming, spending time on systemic improvement rather than features feels like taking your foot off the accelerator at the worst possible moment.<\/p>\n But one week spent halving a 20-minute test suite, for a team of 100 developers running it six times a day, recovers something like 40 hours of productive development time, every single day. It pays back the investment within the first week and keeps paying for months after, and that's just the quantitative part. The qualitative effect \u2013 on morale, retention, and the quality of thinking \u2013 is probably larger still.<\/p>\n So, how do you find the confidence to act on it when everything feels urgent? In our experience, it\u2019s much easier when you have people alongside you who have done this before, who can show the work and demonstrate the effect \u2013 and who aren't themselves experiencing the feature pressure that makes thinking clearly so hard.<\/p>\n At factor10, we call this kind of engagement an Anti-friction Team \u2013 a small, focused group of experienced hands-on software architects who work alongside your team to find and remove what's slowing you down. Not to learn your domain or add to your delivery capacity, but to make your existing capacity work the way it should.<\/p>\n Read about our Anti-friction Team offer<\/a><\/p>\n"},{"title":"Why is my software development team slow despite having more people?","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/why-is-my-software-development-team-slow-despite-having-more-people\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/rs3oGDQybt-1024.jpeg"}}],"updated":"2026-04-02T00:00:00Z","id":"https:\/\/factor10.com\/news\/why-is-my-software-development-team-slow-despite-having-more-people\/","content":" The software team says the workload is too high. So you add more people. That should help! But what happens instead is that features now take even more time to squeeze through the system and your people start blaming each other. What has happened?<\/p>\n You are far from the first person to live through this dilemma, and the good news is that there are ways to add more people to a project and actually go faster, but it requires some serious work. In 1975 Fred Brooks wrote about this conundrum in his book 'The Mythical Man Month'<\/a>, where he compares developing a software project with having a baby. You won't be able to get that baby in one month when you assign nine people to making it. He coined Brooks's Law<\/a> which says that "Adding manpower to a late software project makes it later." Several other people have made the same discovery since and came up with reasons and solutions (for the software problem, not the baby one).<\/p>\n Here is a list of some of the reasons:<\/p>\n For every person added to a team, the number of communication channels increases quadratically. If you had five people in the team, there were 4 + 3 + 2 + 1 = 10 communication channels. If you add a sixth person, there are now five more (5 + 4 + 3 + 2 + 1 = 15) communication channels. Each new person increases the number of channels by the number of persons already in the team.<\/p>\n Official communication becomes a lot harder, but the unofficial communication suffers too. Situations like overhearing your colleague talking about a problem that you know how to solve become more unlikely the more colleagues there are.<\/p>\n Communication through code suffers as well. With fewer people it is easier to decide on shared standards and to have discussions about the structure of the code. With a lot more people involved, it is harder to maintain conceptual integrity: the code won't look like it was written by one person and thus be harder to navigate, understand, change and maintain.<\/p>\n The authors of the book Team Topologies<\/a> argue that the size of a team is limited by Dunbar's number<\/a>, which is the maximum number of people with whom one can maintain stable social relationships.<\/p>\n If the team gets too big (more than nine members), the trust automatically decreases because of this human limitation. High trust is what allows teams to innovate and evolve. If it is lacking or reduced, the speed and quality of delivery will decrease.<\/p>\n It takes time to onboard new members, and it takes away time from those who are familiar with the system. This is why adding people to an already late project makes it later.<\/p>\n If you, however, add more people before everything is on fire or if you add the right and highly qualified people, Brooks's Law does not apply (according to Brooks). It also does not apply if you can perfectly partition the tasks, which Brooks argues is very rare.<\/p>\n The cognitive load remains the same even if you add more people, you cannot decrease it by sharing it (it is like 'fun' in that way, only much less fun). Complicated code, processes and tools will influence the speed of every team member, if there are more, that just means more people are trying to make sense of the same mess. Cognitive overload can also be rooted in teams being responsible for too many domains or an architecture that doesn't reflect the organizational structure.<\/p>\n There's another law called Conway's Law<\/a> that says that the architecture of your systems prevails the structure and communication paths within your organization. So adding more people to a big team will not only complicate the communication and trust but also the architecture. If you try to change the architecture without reorganizing, this will, according to Conway and Team Topologies, only lead to friction and cognitive overload, and in the end the organizational structure will prevail over the architecture again.<\/p>\n So what needs to be in place to be able to gain speed by adding people? According to Conway's Law, you should start with working on the organizational structure. Together with technical people who know the current architecture and its limitations, you can reorganize with the goal to improve the architecture (this is called an Inverse Conway Maneuver<\/a>). Taking trust and cognitive load into consideration, you should make sure that the teams stay small and can work independently of each other. Aim for one Bounded Context<\/a> per team. Now you can make sure that the architecture reflects the organizational changes. This is called a sociotechnical process because it requires both social and technological change.<\/p>\n The new organizational and architectural structure (which is modular now) makes it much easier to add more people and gain speed.<\/p>\n Once you have come so far, you might find that you no longer need to add more people to gain speed. But if you decide to do so, you are now able to add a whole new team that starts working on a new module without affecting other teams. Or you add multiple new people to a bunch of smaller teams. If each team has to onboard one new person, the negative consequences (trust, communication) are much less serious than onboarding a lot of new people into an already big team. You can also think about adding people with the purpose to remove obstacles for the team (a so-called enabling team according to Team Topologies) and thus speed up all other delivery teams.<\/p>\n At factor10, we call this kind of focused intervention an Anti-friction Team<\/a>: a small, experienced team that works alongside your delivery teams to identify and remove the bottlenecks that limit flow.<\/p>\n You still won't be able to make a baby in a month, but you might be able to make more babies in 9 months than you could imagine.<\/p>\n"},{"title":"What is flow for you?","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/what-is-flow-for-you\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/1A_CS-aG-g-1024.jpeg"}}],"updated":"2026-03-25T00:00:00Z","id":"https:\/\/factor10.com\/news\/what-is-flow-for-you\/","content":" And this is for sure a lovely state to be in. But it\u2019s pretty much a local optimum.<\/p>\n As I gathered more experience, I found myself more drawn to flow at the organisational level: value that is created and moves from start to finish. Starting from the customer\u2019s perspective, having no or few hand overs, doing the work to the very end so that it creates impact.<\/p>\n To me, that\u2019s a far more interesting form of flow. Even lovelier and more important since it\u2019s done though collaboration. Much more of a global optimum.<\/p>\n Tell me, what\u2019s your version of flow?<\/p>\n This text has also been published on LinkedIn. Join the discussion here<\/a>.<\/em><\/p>\n"},{"title":"Do we have the data needed for a self-service solution configurator?","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/do-we-have-the-data-needed-for-a-self-service-solution-configurator\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/OI7ZZCbeev-1024.jpeg"}}],"updated":"2026-03-11T00:00:00Z","id":"https:\/\/factor10.com\/news\/do-we-have-the-data-needed-for-a-self-service-solution-configurator\/","content":" In fact, even companies with a mature system map (ERP, CRM, PIM, PLM, CAD systems, etc) don't have everything they need. Here's why: the data required for a customer-facing configurator is different from the data you use internally. Much of it simply doesn't exist yet because no one has needed it before.<\/p>\n The data that does exist often has quality issues, since it's been designed for humans to interpret, not for systems to process automatically.<\/p>\n The missing data isn't just product specs \u2013 it's the configuration logic that guides customers to the right solution. This is business knowledge about how your products work together, what makes sense in different contexts, and how to solve specific customer problems.<\/p>\n Your existing systems store product information, but configurators need something different: the rules, constraints, and domain expertise that lives in your sales team\u2019s heads, not in any database where a configurator can access it.<\/p>\n But don\u2019t worry, together we can fill that gap.<\/p>\n We start a self-service solution configurator initiative from what your customers need, not from what data you have. This approach creates a precise specification of the required data as you build.<\/p>\n The configurator begins with manually maintained data. Once it's proven valuable with real customers, you backfill the data flows and integrations \u2013 as a separate initiative, on its own timeline.<\/p>\n This means you can move quickly. Build the configurator, test it with customers, prove the value. Then systematise the data sources.<\/p>\n We recommend building in small increments with customer feedback after each step. Start simple with the business logic, keeping integrations lightweight at first. Once you've validated that the configurator works for your customers, you invest in the more sophisticated technical infrastructure.<\/p>\n That said, it's good to understand your current system landscape, and we recommend creating a high-level map if you don't have one (we can help with that too). That map evolves as the project progresses and becomes valuable reference for future initiatives as well.<\/p>\n Organising your internal data involves multiple stakeholders across the organisation. Different departments own different pieces of the puzzle, and coordinating that work takes time and careful navigation.<\/p>\n The good news: our approach is designed for this. By letting requirements emerge from proven customer value rather than internal debates, you avoid getting stuck in opinion wars. The configurator will show what data is actually needed, creating a concrete specification that's hard to argue with.<\/p>\n External facilitation often helps here. Someone without organisational history can ask necessary questions without political baggage, especially with clear sponsorship of the initiative from top management.<\/p>\n Treating internal data work as its own workstream \u2013 separate from the customer-facing configurator \u2013 keeps momentum going. You're not waiting for full automation before launching. The configurator launches with curated data that you maintain manually at first. Then, as you prove value, you increase automation of data sourcing and maintenance.<\/p>\n And because the purpose is clear (better customer experience and increased revenue), it's easier to unite the organisation around the effort.<\/p>\n This work improves your entire data landscape, not just the configurator. You'll increase overall data quality, often redefining responsibilities for more effective operations. You're fixing problems at the source (incorrect data) rather than dealing with the consequences downstream (wrong orders, installation issues).<\/p>\n Your product catalogue becomes more complete and well-structured. Every essential detail \u2013 measurements, pricing, compatible combinations, production country, material specifications \u2013 must be accurate for the configurator to function. This creates a solid digital foundation that benefits the entire organisation.<\/p>\n The configurator initiative becomes a catalyst for broader operational improvements.<\/p>\n Your data is about to become more valuable than ever \u2013 because it will directly power your customer experience and sales process.<\/p>\n Yes, there's more to the data story. The data you do find is often duplicated across several systems with slight variations. Which version is authoritative? That becomes clear as you build. As your configurator matures, you'll also add preview and testing layers to ensure weak data quality and data changes don't unexpectedly affect customers. But these are topics for another time.<\/p>\n The key point: you don't need perfect data to start. You need a clear approach that builds the right data as you prove value with customers.<\/p>\n Ready to explore what a Self-service Solution Configurator<\/a> could do for your business? We offer a three-hour workshop<\/a> to help you discover the potential value \u2013 either remote or in-person. Get in touch!<\/p>\n"},{"title":"Is our organisation ready for AI?","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/is-our-organisation-ready-for-ai\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/PxwlMcm01V-1024.jpeg"}}],"updated":"2026-02-27T00:00:00Z","id":"https:\/\/factor10.com\/news\/is-our-organisation-ready-for-ai\/","content":" In his recent white paper \u201cAI-Ready Code: How Code Health Determines AI Performance\u201d, Adam Tornhill comes to the conclusion that GenAI is even more inclined to create errors due to bad code than human developers.<\/p>\n You can read the full paper here<\/a>.<\/p>\n In her article \u201cBuilding Foundations for Continuous (AI-accelerated) Change\u201d, Susanne Kaiser points out that team topology and architecture are crucial if you want to benefit from the faster pace of AI-generated code.<\/p>\n You can read the full article here<\/a>.<\/p>\n I find this is especially interesting in the light of this quote from the book \u201cAccelerate\u201d, by Kim, Humble and Forsgren, about what kind of architecture you need to enable high software delivery performance:<\/p>\n \u201cWe set out to discover the impact of architectural decisions and constraints on delivery performance, and what makes an effective architecture. We found that high performance is possible with all kinds of systems, provided that systems \u2013 and the teams that build and maintain them \u2013 are loosely coupled.\u201d<\/em><\/p>\n I would like to add 'high cohesion' (from a business perspective) to 'loosely coupled' as another important pairing principle.<\/p>\n This text has also been published on LinkedIn. Join the discussion here<\/a>.<\/em><\/p>\n"},{"title":"What will tomorrow look like?","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/what-will-tomorrow-look-like\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/0XrazuhghT-1024.jpeg"}}],"updated":"2026-02-20T00:00:00Z","id":"https:\/\/factor10.com\/news\/what-will-tomorrow-look-like\/","content":" A friend mentioned yesterday that many software organisations are stuck in a vacuum right now. GenAI is clearly affecting them, but they don\u2019t know how, and even less what to do about it.<\/p>\n At first, this surprised me. I definitely see how GenAI is affecting things daily, but mostly it\u2019s accelerating trends that were already in motion. Sure, it\u2019s a jump, a big one. But the direction isn\u2019t entirely new.<\/p>\n That said, I understand that it\u2019s complex to decide what to do. The information overload isn\u2019t helping, is it? And it also doesn\u2019t help to acknowledge that nobody actually knows what\u2019s coming (even though plenty of people sound like they do). In some places there's a pre-hysteria vibe...<\/p>\n But here\u2019s what scares me more than the uncertainty: doing nothing. That\u2019s probably the worst decision right now. In my opinion the best approach is the same as always: make the best decision you can with what you know today, execute and adapt!<\/p>\n To help you do that, here are three things that are still important and true:<\/p>\n Context is king. What you should do depends entirely on your situation, not what worked for someone else or what the hype cycle says.<\/p>\n Aim for global optima. Maybe coding speed was your bottleneck before (though I suspect not for most). Where will the bottleneck appear now? What unlocks the most value across your entire business?<\/p>\n Software architecture still matters, a lot. If your architecture tricks people into creating errors, it will trick GenAI. If it drains your teams\u2019 energy with unnecessary complexity, same goes for GenAI. If it blocks people, it will block AI agents too.<\/p>\n By the way, nobody ever knows what tomorrow looks like. Therefore, embracing change is always a good strategy.<\/p>\n This text has also been published on LinkedIn. Join the discussion here<\/a>.<\/em><\/p>\n"},{"title":"Raniz will be talking at Devoxx Greece in April","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/raniz-will-be-talking-at-devoxx-greece-in-april\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/IyGt2X50i1-1024.jpeg"}}],"updated":"2026-02-11T00:00:00Z","id":"https:\/\/factor10.com\/news\/raniz-will-be-talking-at-devoxx-greece-in-april\/","content":" Automated pipelines have become an integral part of our daily workflow. As the pipelines become increasingly important, the demands placed on them rise proportionally.<\/p>\n As with many things, a great pipeline operates seamlessly in the background, while a poorly designed one becomes a constant irritation. But what makes a pipeline great? In what order should you run your test suites? Should you have one pipeline or ten?<\/p>\n In this talk, Raniz answers these questions and more by bringing up a few antipatterns he has encountered during his work as a consultant, explaining why he considers them such and what you should do instead.<\/p>\n After listening to this talk, you will have a better understanding of what makes a pipeline great and concrete things you can do to improve it and shorten the feedback loop.<\/p>\n You can find the full schedule and ticket information on the Devoxx Greece website<\/a>. I was super young and hadn\u2019t expected that kind of questioning, but I replied something along\nthe lines of: I thought I could learn it fairly quickly, since I\u2019d worked a lot with\n\u201canother-development-tool-family-that-was-quite-similar\u201d. It turned out fine.<\/p>\n It only just occurred to me that this may have been a formative moment for me, and perhaps\none of the reasons why a tech-agnostic approach has made so much sense to me...?<\/p>\n Fast forward 33 years. If I were asked a similar question now, I think my answer would be\nthat I try my best to be what\u2019s described in the\ntext Expert Generalists<\/a> by Martin\nFowler, Unmesh Joshi and Gitanjali V. Thanks guys, I really like that text! It makes so much\nsense. It\u2019s also a very good description of the kind of people we would like to hire at factor10.\nI only wish I\u2019d had that text a long time ago, but better late than never.<\/p>\n When I read an early draft this autumn, I was genuinely moved, to the point of getting wet eyes.\nThat\u2019s not my usual reaction to a tech text. :) I\u2019m not sure why, but perhaps it felt like being\nunderstood and not being alone in an ambition I\u2019ve had for a long time. An ambition that\u2019s often\nbeen seen as a bit weird, or at least not mainstream.<\/p>\n I do have one issue with the text though, and that\u2019s the word \u201cexpert\u201d. Maybe it\u2019s a Swedish thing,\nbut the word has been so overused and abused that I almost automatically distrust it. I find it\u2019s\nmore often than not used for people who aren\u2019t very skilled and experienced at all. There are\nexceptions, of course, but it\u2019s still a troublesome word for me. But that\u2019s just a minor detail in\nan otherwise excellent piece.<\/p>\n This article has also been published on LinkedIn. Join the discussion here<\/a>.<\/em><\/p>\n"},{"title":"Need an outside perspective on your architecture?","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/need-an-outside-perspective-on-your-architecture\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/QU6ozWZbF6-1024.jpeg"}}],"updated":"2026-02-10T00:00:00Z","id":"https:\/\/factor10.com\/news\/need-an-outside-perspective-on-your-architecture\/","content":" Do you recognise any of these symptoms?<\/p>\n These symptoms are usually a sign that your system can no longer support the way the organisation needs to work. But before investing in large-scale changes, you need clarity on what\u2019s actually slowing you down \u2013 and what isn\u2019t. If you need a clear outside-in perspective on what\u2019s slowing down your software delivery, don\u2019t hesitate to get in touch!<\/p>\n"},{"title":"An example of architecture modernisation, 15 years later","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/an-example-of-architecture-modernisation-15-years-later\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/NUa8A5IB5O-1024.jpeg"}}],"updated":"2026-02-10T00:00:00Z","id":"https:\/\/factor10.com\/news\/an-example-of-architecture-modernisation-15-years-later\/","content":" That team was without a doubt one of the best I\u2019ve ever worked with, and I have very fond memories of the project. So, I decided to reach out to one of the people who was involved back then, Atle Haugan. To my great joy, he told me that the system was still alive and kicking, even blossoming!<\/p>\n They\u2019ve continued evolving the system ever since the renovation project, and that\u2019s the main reason it\u2019s in such good shape today and can support new opportunities. To me, the fact that they\u2019re still investing in its evolution is a strong signal that it\u2019s still a genuinely valuable system. Also that continuous adaptation is smooth for them.<\/p>\n Another team member from that time, Ellen Lippe, and I gave a presentation about the project at \u00d8redev 2011. Back then, most conference talks were about what could and should be done. Therefore it was especially fun to talk about what had actually been done \u2013 and what the outcome was. Unfortunately there were issues with the sound recording, so the video was never published.<\/p>\n I gave the same presentation again at NDC Oslo 2012, this time by myself since Ellen couldn\u2019t make it. The version we did together was definitely better, but this one<\/a> is still reasonably informative, I think.<\/p>\n Oh, and during this project was the first time I met G\u00f8ran Hansen and that was a blast. He joined the team after a while and I definitely learned a lot from him too!<\/p>\n Three years after the renovation project, I got the following comment from another team member, Kjell Einar Mikkelsen (translated to English by me): \u201cI look back on the time of that project as the most important in my career. An amazing learning experience.\u201d<\/em><\/p>\n It was definitely an amazing learning experience for me too! A big thanks for that, and for all the fond memories, to the great Sing team at Equinor!<\/p>\n Initiatives for architecture modernisations \/ renovations \/ remakes \/ transformations \/ adaptations can be incredibly valuable, that\u2019s what they all have in common. That said, every situation is different and context is king.<\/p>\n This text has also been published on LinkedIn. Join the discussion here<\/a>.<\/em><\/p>\n"},{"title":"Katharina will be talking at Scan Agile in March","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/katharina-will-be-talking-at-scan-agile-in-march\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/nR_ZjVrDA8-1024.jpeg"}}],"updated":"2026-02-06T00:00:00Z","id":"https:\/\/factor10.com\/news\/katharina-will-be-talking-at-scan-agile-in-march\/","content":" Katharina<\/a> will be in Helsinki on March 17-18, 2026,<\/strong> to visit Scan Agile<\/a>, the most established agile event in the Nordics.<\/p>\n In her upcoming session, she will share her journey and experiences with implementing Domain-driven Design and how focusing on Value Objects reshaped her understanding of the problem space and unlocked deeper conversations with domain experts.<\/p>\n Attendees can expect to learn:<\/p>\n This presentation is designed for those who want to move past the theory and begin implementing practical modeling techniques immediately, rather than waiting for a time when they have all the answers.<\/p>\n Don't miss Katharina's session to learn how to transform your approach to domain modeling. You can find the full schedule and ticket information on the Scan Agile website<\/a>.<\/p>\n"},{"title":"Dual-use","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/dual-use\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/BgeHdmSGJX-1024.jpeg"}}],"updated":"2026-02-04T00:00:00Z","id":"https:\/\/factor10.com\/news\/dual-use\/","content":" Reading about Ukraine\u2019s successful use of its system \u201cDOT-Chain Defence\u201d, a digital platform that allows military units to order defence products directly from manufacturers, made me realise that dual-use also works on a conceptual level, and not just for hardware.<\/p>\n You can read more about it in the article "How DOT-Chain Defence is changing rules of game for Ukraine\u2019s drone industry"<\/a>.<\/p>\n The article covers many things, but my main takeaway from it is four concepts that I think about, and work with, all the time in the civilian world:<\/p>\n Moving from \u201ceconomies of cost\u201d to \u201ceconomies of speed\u201d. Just-in-time deliveries (pull rather than push) increase adaptability. (Ironically it also reduces the risk of large stocks becoming worthless.)<\/p>\n Using \u201cplatform as a business strategy\u201d. It creates \u201cnetwork effects\u201d, but also help distil quality and surface the most effective solutions for different situations.<\/p>\n Balancing centralisation and decentralisation, to reach effect.<\/p>\n The system\u2019s success is achieved even before adding self-service for custom configuration. I assume that addition will unlock a greater level of effect.<\/p>\n Maybe it\u2019s a stretch to call it \u201cdual-use\u201d when applied to concepts. Concepts are generic by their very nature. That said, I found it interesting to see how well those concepts work in a defence context. In the civilian world, we\u2019re usually applying them \u201conly\u201d to create value for businesses. According to the article, the same concepts can also be helpful when lives, freedom and democracy are at stake.<\/p>\n At the same time, I know that I\u2019ve learned a great deal about architecture and organisation by reading about military philosophy. It goes both ways. (More about that in another post.)<\/p>\n Where else do you see concepts moving between civilian and defence contexts, in either direction?<\/p>\n This text has also been published on LinkedIn. Join the discussion here<\/a>.<\/em><\/p>\n"},{"title":"Vue 3 arrived in 2020. Why are so many apps still on Vue 2?","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/vue-3-arrived-in-2020-why-are-so-many-apps-still-on-vue-2\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/2ilu1E4uyJ-1024.jpeg"}}],"updated":"2026-01-23T00:00:00Z","id":"https:\/\/factor10.com\/news\/vue-3-arrived-in-2020-why-are-so-many-apps-still-on-vue-2\/","content":" This article marks the beginning of a series where I'll explore what it actually takes to migrate a real-world Vue 2 application to Vue 3.\nBefore we get into tooling, strategies, and trade-offs, we need to understand how we got here in the first place.<\/p>\n This year marks the 10th anniversary of the release of Vue 2.0.<\/strong>\nI remember that period fondly, a kind of renaissance for web development, where the goal was to make things simpler.\nWhile that goal is never-ending, we are undeniably in a better place today than we were back then.<\/p>\n At the time, I worked as a consultant and dabbled in all sorts of technologies. I vividly remember onboarding a colleague\nonto a project built with AngularJS. He didn't struggle per se, but something felt off. The learning curve wasn't steep, it was wide<\/em>.<\/p>\n Later that day, during lunch, he told me about this thing called Vue<\/em>. From my perspective, it looked like a scaled-down\nversion of AngularJS, but with a far more elegant and intentional component model.<\/p>\n Little did I know that a few years later I'd attend a Vue conference and meet Rolf Haug and Alex Kyriakidis, the founders of VueSchool.<\/p>\n Using Vue was simply... fun!<\/p>\n Over time, its ecosystem grew to include first-class solutions for state management, testing, routing, and more. Vue felt cohesive in a way few frameworks did.<\/p>\n Then, in September 2020, Vue 3.0 landed.<\/p>\n My recollection is that the community didn't take it particularly well. Some were excited. Others were cautiously optimistic.\nMany were frustrated by the sheer number of changes between the two versions. Vue 3 shipped, but the ecosystem lagged behind.\nIn hindsight, that gap likely hurt adoption and migration efforts more than anything else.<\/p>\n At the end of 2023, Vue 2 officially reached end of life. Prior to that, Vue 2.7 was released as a kind of bridge:\na compatibility release where some, but not all, Vue 3 features were backported to ease the transition.<\/p>\n But all of that belongs to the past.<\/p>\n Vue 3 is better than its predecessor in virtually every way. We're almost six years into its lifecycle. Surely, people have moved on?<\/p>\n Out of plain curiosity, I looked at the download numbers for the period between January 16 and January 23, 2026:<\/p>\n Those numbers are ... surprising.<\/p>\n Of course, downloads don't equal active applications. But the signal is still hard to ignore. Vue 2 clearly hasn't disappeared.<\/p>\n Migrating from Vue 2 to Vue 3 is hard.<\/strong> Migrating a small project is one thing, migrating a large, long-lived application is something else entirely.<\/p>\n Over the course of this series, I'll walk through how I approach migrating a Vue 2 application to Vue 3. Not toy examples or full-on rewrites,\nbut large codebases with history, constraints, and active development.<\/p>\n In the next part, we'll start where every successful migration should: with a plan.<\/p>\n"},{"title":"Implementing Value Objects in Kotlin","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/implementing-value-objects-in-kotlin\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/RksSnsoIoV-1024.jpeg"}}],"updated":"2026-01-06T00:00:00Z","id":"https:\/\/factor10.com\/news\/implementing-value-objects-in-kotlin\/","content":" I started my software development career as a structural engineer who programmed, developing analytical applications for other engineers. When I moved to a traditional software company, I went from one extreme to another, from having all the roles of a software development team at once to becoming a "code monkey" with no context about what I was building and why.<\/p>\n In search of a middle ground I came across Domain-Driven Design (DDD)<\/em>, which in its essence is about getting to know the Domain you are developing software for. But without being a Domain expert yourself.<\/p>\n For my next project I started my DDD journey by implementing what is known as tactical Domain-Driven Design. These are patterns applied at the code level. There is also Strategic Domain-Driven Design which describes patterns that can be applied on a higher, architectural level.<\/p>\n I quickly started seeing advantages of applying tactical patterns that went beyond the separation of concerns, that an isolated Domain Layer with a model containing data and behavior (Rich Domain Model<\/em>) brings.\nThe pattern that stood out to me was Value Objects. It is relatively straightforward to grasp and implement and still allow you to practice the philosophy of DDD.<\/p>\n In this post I will show which features of the Kotlin<\/a> Language I find especially useful to implement Value Objects<\/em> (including Domain Primitives<\/a>) while developing the SwatchIt Android application<\/a>.<\/p>\n A swatch is a small sample of fabric knitted before starting a project. Because every knitter\u2019s tension and materials vary, swatches allow you to measure your stitch and row count (gauge). This ensures your finished piece will be the correct size.<\/p>\n<\/blockquote>\n All data objects in a Domain-Driven Design Model are either Entities<\/em> or Value Objects<\/em>.\nValue Objects<\/em> are objects without an identity that are primarily defined by their attributes. Entities<\/em> are defined primarily by their identity, because we need to keep track of them over their whole lifecycle, even if all their attributes change. In the context of SwatchIt a swatch is an entity. The attributes, like the yarn or the notes, might be changed by the user, but we still see it as the same swatch. There could be two swatches with the same attributes in our system, but we see them as conceptually different swatches. So we cannot use the attributes to track the swatch. We need something that makes the swatch unique and identifiable in our system: an identity usually implemented as an Int, or a UUID.<\/p>\n In real life all physical objects have an identity. They might change, but we usually still see them as the same objects. The aim of modelling is to make things analyzable and calculable. To achieve that aim we usually have to strip everything from reality that is not relevant to our analysis.<\/p>\n Modelling means distilling reality into a concept that is exactly as complex as it absolutely needs to be for the task at hand. The model needs to strike a balance between being too naive to make any useful assumptions and being too complex to be analyzable and calculable. Distinguishing Value Objects and Entities is one tool to achieve that.<\/p>\n If you are not interested in following an object over its whole lifecycle, you model this object as a Value Object<\/em>, without an identity. If the user changes the knitting needle size, it is not important which exact pair of knitting needles the user had in mind. All that is important in the context of SwatchIt is the size of the needles. The knitting needle object is defined by it's attributes (the size) and not by an identity.<\/p>\n There are no general rules. What is considered a Value Object<\/em> and what an Entity<\/em> can change from context to context and every team decides for themselves what should be modelled as what.<\/p>\n Not requiring an identity has several advantages:<\/p>\n Leveraging immutability has several advantages:<\/p>\n When implementing Value Objects you can make use of features that your chosen language and framework offer you. Here comes an overview over what I found useful in Kotlin\/JVM.\nMost of the examples are taken directly from the code of the SwatchIt Android application<\/a>.<\/p>\n When you compare Value Objects they are considered equal when they have the same attributes. You can use two knitting needle objects interchangeably as long as they have the same size value. To reflect that in the code you would override the Equals and HashCode methods to reflect that.<\/p>\n Instead of doing that manually for each Value Object<\/em> you can leverage\nKotlin's Data class<\/a>. It automatically implements the Equals and HashCode methods based on the attributes of the class, which is exactly what we want.<\/p>\n It is also quite easy to create immutable data classes by defining all properties in the primary constructor as readonly with the If a property should not be considered for comparing it can be defined in the class body:<\/p>\n Additionally data classes come with some useful standard methods implemented, for example a The automatic As someone being familiar with C# I see resemblances between Records in C# and data classes in Kotlin. One difference I noticed is that you cannot have a private constructor in data classes. So forcing the creation of instances via a factory method is not possible. However you must use the Primary Constructor<\/a>. Validation can be added to an init block<\/a> like this:<\/p>\n The Another difference is that Kotlin's data classes implement structural equality by default<\/a> even for collection properties (be careful with Arrays though<\/a>).<\/p>\n Furthermore, it is possible to inherit from Records in C#. Records use an In Kotlin all classes are by default closed for inheritance ( Interfaces in Kotlin can be As an example SwatchIt uses a sealed interface to distinguish between two types of measurements (rows and stitches) like this:<\/p>\n As all possible inheritors are known at compile time, there's no need to add a default value in Again: less boilerplate, yay!<\/p>\n Inline value classes<\/a> are meant for wrapping underlying types (like Inline value classes are defined by the keyword To ensure they can be "unwrapped" into a single value, these classes are limited. They must have exactly one primary constructor parameter and no other backing fields. However, you can still add computed properties and member functions. These are compiled to static Java methods, meaning you can add logic to your domain primitives without breaking the performance optimization.<\/p>\n You might want to override the ![\"Felienne](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/FelienneHermans.jpg\")
\n<\/div>\n![\"Felienne](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/FelienneHermans2.jpg\")
\n<\/div>\nWorkshops and conversations on the second day<\/h2>\n
![\"Martin](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/XinYao_MartinGuenther.jpg\")
\n<\/div>\n![\"Krisztina](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/EventStorming.jpg\")
\n<\/div>\n![\"Panel](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/FowlerEvansVerschatse.jpg\")
\n<\/div>\nTalks from the final day<\/h2>\n
![\"Michael](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/MichaelFeathers.jpg\")
\n<\/div>\n![\"Susanne](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/SusanneKaiser.jpg\")
\n<\/div>\n![\"William](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/WilliamBartlett.jpg\")
\n<\/div>\n![\"Frances](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/FrancesSun.jpg\")
\n<\/div>\n![\"Diana](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/DianaMontalion.jpg\")
\n<\/div>\nThe conference itself<\/h2>\n
![\"The](\"https:\/\/factor10.com\/uploads\/DDDEurope26\/venue.jpg\")
\n<\/div>\nBoth are about self-service<\/h2>\n
One is about hygiene, the other about differentiation<\/h2>\n
\n
Phase 1: create and offer the best product<\/h2>\n
![\"The](\"https:\/\/factor10.com\/img\/EcPR4oKN1R-384.jpeg\")
<\/picture><\/p>\nPhase 2: sell your product in an e-shop<\/h2>\n
![\"The](\"https:\/\/factor10.com\/img\/AdtobbyM0y-384.jpeg\")
<\/picture><\/p>\nPhase 3: offer a self-service solution configurator<\/h3>\n
<\/picture><\/p>\nPhase 4: offer customisations by category or by customer<\/h2>\n
![\"The](\"https:\/\/factor10.com\/img\/NhqMgScJGZ-384.jpeg\")
<\/picture><\/p>\nIs it really that simple?<\/h2>\n
1.<\/h2>\n
2.<\/h2>\n
3.<\/h2>\n
1 - Develop a shared language<\/h2>\n
2 - Really understand why<\/h2>\n
3 - Ask the \u201cstupid\u201d questions<\/h2>\n
4 \u2013 Use different model presentations<\/h2>\n
5 \u2013 Understand the core objectives of the business<\/h2>\n
6 \u2013 Read up on the basics<\/h2>\n
\n
7 \u2013 Say thanks and mean it<\/h2>\n
\n
8 \u2013 Act like a mirror<\/h2>\n
\n
9 \u2013 Talk in four dimensions<\/h2>\n
\n
10 \u2013 Make it a dialogue<\/h2>\n
11 \u2013 Create a sense of belonging<\/h2>\n
12 \u2013 Check alignment<\/h2>\n
\n
13 \u2013 Create the situation<\/h2>\n
\n
14 \u2013 Language as an icebreaker<\/h2>\n
15 \u2013 No derogatory thoughts<\/h2>\n
Bonus<\/h2>\n
\n
\n
The harder you push, the worse it gets<\/h2>\n
The wrong fix: adding more people<\/h2>\n
What actually works<\/h2>\n
Why teams don't fix this themselves<\/h2>\n
The hidden cost of high friction<\/h2>\n
How we can help<\/h2>\n
1. Communication gets more complicated<\/h2>\n
2. Lack of trust<\/h2>\n
3. Onboarding takes time<\/h2>\n
4. The real problem is the cognitive load<\/h2>\n
5. The architecture does not support it<\/h2>\n
What to do?<\/h2>\n
What kind of data are we talking about?<\/h2>\n
How we solve this<\/h2>\n
What about internal challenges?<\/h2>\n
Better data across the organisation<\/h2>\n
The bottom line<\/h2>\n
1.<\/h2>\n
2.<\/h2>\n
1<\/h2>\n
2<\/h2>\n
3<\/h2>\n
To keep track of all of his upcoming events and talks, we recommend checking out Raniz's Sessionize page<\/a>.<\/p>\n"},{"title":"Expert generalists","link":[{"@attributes":{"href":"https:\/\/factor10.com\/news\/expert-generalists\/"}},{"@attributes":{"rel":"enclosure","type":"image\/jpeg","href":"https:\/\/factor10.com\/img\/BgeHdmSGJX-1024.jpeg"}}],"updated":"2026-02-11T00:00:00Z","id":"https:\/\/factor10.com\/news\/expert-generalists\/","content":"\n
That\u2019s where our turbo architecture review comes in: analysis, diagnosis and recommended next steps in just two weeks. We\u2019ve written more about how it works here<\/a>.<\/p>\n\n
1.<\/h2>\n
2.<\/h2>\n
3.<\/h2>\n
4.<\/h2>\n
The arrival of Vue 3<\/h2>\n
\n
\n
About Value Objects<\/h2>\n
\n
\n
Implementation in Kotlin<\/h2>\n
Data classes<\/h3>\n
val<\/code> keyword:<\/p>\ndata class Yarn(\n val name: YarnName?, \n val manufacturer: YarnManufacturer?\n)\n<\/code><\/pre>\ndata class GaugeSize(val value: Double) {\n val unit: LengthUnit = LengthUnit.CM\n...\n}\n\/\/ Equality will be determined by the value only, \n\/\/ the unit property is not taken into account\n<\/code><\/pre>\ncopy<\/code> method that makes handling immutable objects easier and reduces boilerplate:<\/p>\nval newYarn =\n oldYarn.copy(name = Name("new yarn name"))\n\/\/ creates a new yarn instance with the same manufacturer value\n\/\/ as oldYarn, but a different name\n<\/code><\/pre>\ntoString<\/code> method of a Yarn instance generates: "Yarn(name="new yarn name", manufacturer = "manufacturer")"<\/code>, which is helpful for debugging.<\/p>\ndata class Yarn(\n val name: YarnName?,\n val manufacturer: YarnManufacturer?\n) {\n init {\n require(name != null || manufacturer != null) {\n "Yarn must have at least a name or manufacturer"\n }\n }\n ...\n}\n<\/code><\/pre>\ninit<\/code> block is run when the Primary Constructor is executed. This behavior makes sure that the validation logic in the init block is always run, even if an object is created via the copy method. This can be somewhat of a pitfall in C#, unless you are careful, the with<\/code> expression (which is C# equivalent to copy<\/code>) can bypass constructor-based validation, leading to invalid domain states. Also with<\/code> clones the whole object and then sets the properties one by one<\/a>. The init<\/code> block makes validation of Cross-Field Invariants easier, as it ensures the object is only fully initialized if the entire state passes validation in one atomic operation.<\/p>\ndata class Yarn(val skeins: List<Skein>)\n\ndata class Skein(val yardage: Long, val color: String)\n\nclass Swatch(val skeins: List<Skein>)\n\nfun main() {\n val blueSkein = Skein(200, "blue")\n val redSkein = Skein(220, "red")\n\n val skeins1 = listOf(blueSkein, redSkein)\n val skeins2 = listOf(blueSkein, redSkein)\n\n \/\/ structural equality for collections\n println(skeins1 == skeins2) \/\/ true\n\n val yarn1 = Yarn(listOf(blueSkein, redSkein))\n val yarn2 = Yarn(listOf(blueSkein, redSkein))\n\n \/\/ structural equality in data classes\n println(yarn1 == yarn2) \/\/ true\n\n val swatch1 = Swatch(listOf(blueSkein, redSkein))\n val swatch2 = Swatch(listOf(blueSkein, redSkein))\n\n \/\/ referential equality in classes\n println(swatch1 == swatch2) \/\/ false\n}\n<\/code><\/pre>\nEqualityContract<\/code> property to make sure that you are comparing the same type (and not a parent with a child for example)<\/a>. That makes overriding the Equals and HashCode methods of records a little tricky as you need to remember to add a check EqualityContract == other.EqualityContract<\/code> to maintain type-safety. So not only do you have to override those methods as soon as you use a collection property, you also have to remember the EqualityContract<\/code>.<\/p>\nfinal<\/code>). To open a class for inheritance you need to add the open<\/code> keyword. But Data classes can never be open. If you need inheritance you typically use a sealed interface<\/code> or a regular abstract class<\/code> instead.<\/p>\nsealed<\/code>, which means that only classes within the same module can inherit from the interface. All the inheritors are therefore known at compile-time. This is nice because it gives you full control over your interfaces in the Domain Layer and makes it clear that this interface should only be extended within the context of this module.<\/p>\nsealed interface Measurement {\n val count: GaugeCount\n val size: GaugeSize\n\n data class Rows(\n override val count: GaugeCount,\n override val size: GaugeSize\n ) : Measurement\n\n data class Stitches(\n override val count: GaugeCount,\n override val size: GaugeSize\n ) : Measurement\n}\n<\/code><\/pre>\nwhen<\/code> expression blocks, when checking the type of the Measurement instance, because the compiler enforces exhaustiveness:<\/p>\nprivate fun Measurement.toListItem(): MeasurementListItem = when (this) {\n is Measurement.Stitches -> MeasurementListItem.Stitches(\n count = count.value,\n size = size.value\n )\n\n is Measurement.Rows -> MeasurementListItem.Rows(\n count = count.value,\n size = size.value\n )\n}\n<\/code><\/pre>\nInline value classes<\/h3>\n
Long<\/code>, Int<\/code>, String<\/code>..). They give you the possibility to use more domain specific types without increasing the runtime overhead (in most cases). This is perfect for wrapping these simple values into small Value Objects (also called Domain Primitives<\/a>). You get type safety, immutability and validation without any performance overhead.<\/p>\nvalue<\/code>, and they need the @JvmInline<\/code> attribute if your code is supposed to be run on the JVM:<\/p>\n@JvmInline\nvalue class YarnName private constructor(val value: String)\n<\/code><\/pre>\ntoString()<\/code> method of your inline value classes. By default, the Kotlin compiler generates a toString()<\/code> that includes the class name, like