Feel the force March 30, 2026

An important principle in both martial arts and software development is “feeling the force”. By this I mean sensing the strength and direction of the force an opponent is applying (or is about to apply) as well as the opponent's stability in various directions you might consider applying force in. Or, in software architecture, seeing all the forces at play when preparing for a decision. In both cases, feeling the force enables you to anticipate how it might impact you (in a literal or figurative sense), and allows you to find the best (martial arts or software architecture) move in the situation.

Feeling the force in martial arts

In martial arts, the better you can judge the speed and angle of – and the strength behind – an attack, the better you can position yourself outside the direct line of attack and perform a counter movement that neutralizes it. In software architecture, the better you can judge the social, political, and technical forces affecting the system you are designing, the better you can adapt the shape of the system to go along with or withstand these forces as appropriate.

A classic diagram in martial arts shows how to destabilize your typical two-legged opponent.

You apply force perpendicular to the line connecting the two feet. Pulling or pushing in parallel to this line only serves to stabilize your opponent because you end up pushing him onto his own foot, so the force is easily redirected into the ground. However, there is no support on either side of this line, so applying just a little bit of perpendicular force immediately destabilizes your opponent, forcing him to adjust his position or fall over.

Now, in most practical situations, you won't have time to draw a diagram, or to ask opponents to stand still so you can get a good look at their foot position. You have to get the direction right immediately. To get to the point where you can do that, you need to practice. A lot. By doing this, you develop a sense of where the opponent's feet are without looking at them, of the momentum of the opponent's body (which enables you to decide to which side to move), and of the best point in space to position your own body so the opponent has no chance to lean on you to stabilize himself. This is what I mean by feeling the force. You practice until this becomes second nature. At this point, it feels effortless, and it may look like magic to an unskilled observer.

Feeling the force in software architecture

In software architecture, “feeling the force” means being aware of the constraints bearing on decisions you are about to make, of the current trajectory of the system under development and surrounding systems that might potentially have an impact on those decisions, and of the leverage points at your disposal to deal with them. This awareness lets you come up with solutions that fit the constraints and guide the system in the right direction. It can feel as if the architecture “flows” naturally from the context.^[1]

For example: Picture an old enterprise with a heterogeneous IT landscape (partially on prem and partially in the cloud) managed by a strong, centralized IT department, where in-house development is focused on Java/Spring Boot and TypeScript/Angular. The enterprise as a whole is highly focused on compliance such as data protection regulation. Now imagine a situation in which one business unit of this enterprise, a mostly agile bubble in this large, not-so-agile organization, is tasked with developing a new customer landing page with some custom functionality, while it is at the same time trying to build an internal integration platform to support several budding value streams. The landing page is important politically, and there is a deadline – not too tight, but not comfortable either. The business unit has a couple of employees who know just enough Python to be dangerous and has already developed some ideas for building the integration platform in the cloud (even though the requirements are very hazy) before the project has come to the attention of the IT department, which is – of course – stretched for resources. One of the ideas is to use the new landing page as a pilot for the integration platform (which doesn't yet exist).

This is a real situation I found myself in a couple of years ago, when I, as part of said IT department, was in the position to establish myself as a solution architect for this project by dint of being in the right place at the right time. So what does “feeling the force” look like in this situation?

It was clear from the outset that letting the business unit loose with an account on the cloud platform by themselves was not going to work out well. At the same time, we (the IT) didn't have spare resources to staff the project ourselves. Nevertheless, positioning yourself as a blocker is never a good start. So the first thing I did was to talk to them and listen to their ideas. This was to the detriment of other commitments, but it enabled me to establish a friendly working relationship, to gather further information, and to get a feeling for the forces they felt (political pressure, promises they had made to their leadership, motivation to get their hands dirty coding themselves etc). I was observing their stance, so to speak. While this may sound obvious when you read about it (“just talk to them”), other IT architects at the company got quite upset about the plans of the business unit and wanted to have an internal discussion about how “IT should position itself” before confronting the business unit with this position. This is the opposite of feeling the force – trying to react before really knowing anything. Feeling the force requires establishing contact first.

Talking to my colleagues in IT was also part of “feeling the force”. One aspect of this was the self-image of certain colleagues, which boiled down to, “We are the IT experts!” Another was the availability – or rather, unavailability – of spare resources. Some others like the IT tech strategy and security policy I already knew.

After some internal negotiation, I managed to secure a part-time commitment from one of our IT cloud architects for the business unit to ensure a reasonable base setup in the public cloud without any major security issues. I also offered to accompany the project as a solution architect, while at the same time juggling with my other commitments to make this work. The people in the business unit accepted this gladly because I framed it as extending a helpful hand rather than coming down on them with compliance and security regulations. In the eyes of my IT colleagues I was reining in the rogue business unit, which served to appease them.

After some back and forth, we settled on a microservices architecture based on Python for the integration platform part (to enable experimentation by the business unit without too much IT involvement, at least in the beginning) and a backend for frontend built by myself and a fresh graduate of our internal training program on the approved tech stack. This backend for frontend served the dual purpose of

1. providing a simple facade to the frontend for the functionality it needed and
2. shielding the potentially not as secure (built by less experienced people using an unfamiliar tech stack) integration services from external access.

I also freed up time by delegating other work so I could take the lead writing the mandatory security concept (including threat modelling and risk assessment) and getting it approved with minimum fuss. In the end, we did manage to get the landing page up in time for the deadline, and development continued within this architectural frame.

How to practice

In martial arts, you learn how to feel the force by practicing the same sequence again and again. The feedback cycle is very quick: you push or pull and see the effect immediately. Did it work? Remember what it felt like and try to reproduce it. It didn't work? Make a slight change to your position, stance, or direction, repeat, and observe the effect. Usually, an instructor will help if you get stuck or have questions.

In software architecture, the feedback cycle is typically much longer, and you get much less repetition. Also, the situation is often not repeatable in the same way – unless you are prepared to discard at least part of the work that has already been done and start over – and how often do you get that chance? Another consequence of this is that there is no instructor who has done the same thing a thousand times before and can tell you what you are doing wrong.

Despite all this, I think you can – and should – practice feeling the forces in software architecture, too. Here are a few ideas:

• Close the feedback loop. Although feedback is often slow to come, it is still valuable. Get feedback on your architecture decisions after enough time so that their effects have made themselves felt. In his lightning talk Tech debt nomads and slash-and-burn development, Einar Høst suggests that this time is about 3 years. From my personal experience, I'd say it's more like 2 years for bigger decisions if you are sensitive to feedback. Feedback on smaller decisions can come much faster, but you still have to look for it. It doesn't always smack you on the head. In any case, make sure to look for feedback, and to learn from it. If I leave a team before the trajectory becomes visible, I try to get in touch with someone on the team later and ask them how the architecture has held up. This is not always possible, but when it is, it's always interesting.
• Try multiple versions. For smaller decisions like, for example, whether to implement a certain feature using inheritance or composition, it is often quite possible to try both versions and see where this takes you. Writing a little bit of code is cheap, and even if you will discard half of it, what you learned will stay with you and make you a little bit smarter.
• Recycle past situations. You may not be able to recreate a situation to practice it again for real, but thinking is cheap. You can always recreate it in your mind and reflect on it. What happened? How did you handle it? What happened as a result? What do you know now that you didn't know then that turned out to be important? How could you have known at the time? In retrospect, what signs were there that you might have missed? Also: What went well, and why? Were you well prepared, or did you get lucky? What could have gone differently, and how would you have reacted to the change – with your knowledge then and with your knowledge now? How could it have gone even better? Asking these questions turns you into your own instructor because having lived through the situation already allows you to see it much clearer, and to come up with your own advice. If you can talk the situation through with someone else (a peer, a mentor), this can help, too, but even if you can't, a little reflection can take you a long way.
• Stress-test your decisions. You can exercise feeling the force in your current situation, too, by taking a step back before committing to a decision and asking challenging questions like, “Why are we even doing this?” This is only half a joke. Surprisingly often, the answer is not really clear. But even if it is, you can play around with the parameters the answer likely contains. What if this requirement changes? What if this assumption turns out to be wrong? What would need to happen for this to blow up politically? Etc. Posing these questions can help you feel out the trajectory you are on and bring hidden forces to the surface so you can deal with them.^[2]
• Do systems thinking exercises. If you want to get a broader perspective, or if you are new to this and don't have a long history of past decisions to draw on, you can do systems thinking exercises like Ruth Malan's Advent(ure) in System Seeing. The early exercises use generic topics to get you used to various kinds of questions to ask, while the later exercises can be applied to a situation of your own choosing. This can be a work situation, but it doesn't have to be. The advantage of these exercises is that some people make their “solutions” public so you can compare them with your own and with each other and examine the differences. Ruth has links to some examples on her site. My own reflections from last year can be found here.

Conclusion

Feeling the force is an important skill for both martial artists and software architects. Noticing all the forces at play in an encounter enables you to respond effectively, while expending only the necessary effort.

If you get this right, in software architecture as in martial arts, it will feel as if you aren't actually doing very much and things are going fine nonetheless. This might make you nervous. You might feel your training partner is not really attacking properly, or that you should be “architecting more”. But don't be fooled! The goal is not to do much. The goal is to do the right things to ensure the result you want. Indeed, having to exert much effort for little gain is one of the surest signs you are not sensing the forces well (or are not responding appropriately). If you find yourself getting hit again and again despite your best efforts, or if you find yourself mired in complexity despite having already done much architectural work, take a step back and reflect! You might not be taking into account the forces around you. Maybe it is time to practice feeling the force a bit more.

Martial artists practice this skill regularly and with quick feedback that is not easy to ignore (like a fist in your mouth). It's more difficult for software architects due to long feedback cycles and because negative feedback is easier to miss (hopefully!). Nevertheless, you can and should practice feeling the force as a software architect, and after reading this, you don't have an excuse not to. 😁