If you are curious about history and politics, you will notice that extremes often look powerful at the beginning. They move fast, talk with certainty, and produce visible results in a short period time. However, over the time, the same force making them effective works in the opposite way. Systems survive longer are usually not the ones built on purity, but the ones that learn how to live with tension, correction, and balance.
Software development has its own version of this tension. I will categorise these into two main tendencies: idealism and pragmatism. Almost all disagreements between software engineers are shaped by the conflict between these two forces. After 21 years in software development, I have come to believe that becoming dogmatic about either one will derail a project soon or late. The real challenge is not choosing one and rejecting the other, just understanding and managing them, utilising them when needed.
Idealism in Software Development
Idealism in software usually begins with a good intention. It is mainly about doing the job in the best possible way. You want the system to have clear boundaries, meaningful abstractions, consistent naming. In short, you want to make it manageable and predictable. The instinct itself looks healthy because its purpose is to protect the future of the project. However, like many other sins in software engineering, it often grows out of a virtue and good intention. The desire to do things properly can turn into architectural purity, fear of imperfection, and a constant urge to solve problems before they truly exist.
First of all, idealism often surfaces in the form of solving problems that do not exist yet. You design for a scale that you do not have yet, complexity you have not suffered from yet. Or teams that are not here yet. This is where premature abstraction begins. You start introducing layers, extension points, and generic structures not because the system already needs them, but because it may need them one day. One caveat here: this does not mean we should ignore risks that are almost certain to become real problems. If, for example, you write passwords to a database without encrypting them, sooner or later you will have a severe issue, that is not hard to predict. However, this is different from building for hypothetical future requirements. For a pilot project with zero real-life customers, you may not need ElasticSearch to store and search logs, for example. Writing them as plain text in the initial phase may be entirely reasonable.
Another common form of idealism is falling into the over-engineering trap. People shape their architecture to handle millions of requests even before handling a single request in production. If such scale is part of the actual requirements, then of course it must be considered from the beginning. But if you are building a startup product or an experimental internal platform, designing everything around imagined hyper-scale can become a form of gold-plating. Think of a startup where developers build an automated, highly scalable Kubernetes platform for an early-stage project but no customers yet. In reality, running the system on a few virtual machines from a cloud provider might be more than enough in the beginning. You can always evolve the architecture later if the product moves in a positive direction and the business has the budget to support that change. Otherwise, you end up spending energy on a future problem instead of learning from the present one.
Idealism can also push teams into analysis paralysis. The search for the best design, the cleanest abstraction, or the most future-proof structure slows down progress to the point where learning itself is delayed. In many cases, software does not become better through extended speculation, but through contact with reality. Real users, real traffic, real operational pain, and real product pressure will reveal which abstractions are necessary and which ones were only “intellectually attractive”. This is why the danger of excessive idealism is not only wasted effort; it is also distance from reality. The team starts optimising for elegance rather than evidence.
That is the paradox of idealism in software development. It begins as care for quality, maintainability, and the future of the system. But when detached from context, it can turn into premature abstraction, over-engineering, and complexity the project has not yet earned.
Pragmatism in Software Development
Pragmatism is mainly about survival in the real world. In an environment where deadlines are taken seriously, priorities change, and delivery pressure is unavoidable. You may have to pick the path that ships the needed features as quickly as possible. Your focus is delivering value in the short run or middle run. Sometimes, insisting on the technically proper path in every case might even look like a kind of “lumpen” attitude. In this sense, pragmatism presents itself as realism. It says: “do what works, deliver what matters now, and do not let ideal discussions block visible progress.”
This, as a sin, also derives from good intentions just as idealism does. Effective use of limited time, budget, or team capacity are usually the main reasons. It pushes teams to turn their limited resources into immediate value. However, in many cases, teams find themselves in a situation where they start negotiating away from best practices, maintainability, and even parts of the project’s future for the sake of quick delivery. What begins as realism can slowly turn into short-termism. One shortcut makes the next shortcut easier to justify, and after a while the exception quietly becomes the norm.
By being too pragmatic, you borrow a high-interest loan from the project’s future. You may gain something very quickly in the short term, but the system can become unmanageable just as quickly. Technical debt starts to accumulate, under-engineering becomes normal, and local optimisation of today’s priorities begins to damage the whole system. Teams may solve each immediate problem in isolation, without noticing that they are creating accidental complexity around the codebase. Over time, architectural erosion begins. The structure of the system becomes weaker, consistency starts to disappear, and even simple changes require more effort than they should.
At that point, pragmatism starts producing the opposite of what it originally promised, and also delivered. The team is no longer moving fast; it is only trying to keep the system standing. Delivery slows down, confidence drops, and every new change carries more risk than before. And in some cases, the experienced people seeing where the project is heading, look for an opportunity to move to a different project or team. In other words, excessive pragmatism does not remove cost; it merely postpones it, usually with interest.
Managing the Balance
If we compare these two approaches, being ultra-idealistic may help you build future-proof software that is going to last for a very long time, but you may run out of time and budget before you start harvesting the effort. On the other hand, an ultra-pragmatic approach may give you immediate value, but it can also turn the project into a monster that even you have no control over. So, the practical question is not “should we be idealistic or pragmatic?” As you may guess, the overall answer is that we need both. Nevertheless, the balance is never fifty-fifty. It depends on the context: the stage of the project, the pressure of delivery, the risk level, the team’s capacity, and the cost of getting a decision wrong.
Prioritisation by considering your resources is the key strategy to solve this problem. You need to consider what you are supposed to deliver as a minimal product, what your capacity and budget are, and what can reasonably be postponed. Then pick what will be delivered wisely, and postpone anything not creating enough value for the initial delivery. At the same time, we should not negotiate everything. Some areas, such as security, data integrity, and the basic maintainability of the system, leaving a room for almost certain potential next steps should not be just sacrificed. Don’t forget, shortcuts are cheap only at the beginning.
There is also another kind of failure here: not idealism or pragmatism by themselves, but applying either one blindly, without reading the context. Some developers start playing the idealism inside a pragmatically built and already damaged project, even when there is no extra time or budget. By doing so, they do not even let others deliver the limited value that is still possible. Some add new tools, posh patterns, or features whose practical impact is trivial, but they look modern and clever. Frankly speaking, they are personally satisfying. The opposite of this also happens. A well-built project may be gradually damaged by a developer who is used to take shortcuts all the time. Even when nobody is asking for more speed, they still reduce quality, weaken consistency, and introduce unnecessary tech-debt just because it has become their default habit. In some cases, they try to cover up their own mistakes by rushing through quick solutions and these attempts leave permanent damage on the project.
If you ask me which side I am on, I am on neither. My strategy is simply an unorthodox one. When I see a team (or just a small group of developers) becoming dominantly idealistic about a solution or a task, I play the pragmatism card. I start asking questions about delivering value, time and budget constraints, and the short- and long-term return of the suggested practice. On the other hand, if I see an environment where pragmatism is the dominant approach and everyone echoes each other, this time I do the opposite. I play the idealism card. This is not because I enjoy debating with people, my purpose here is to remind them that the other perspective also exists. In this way, I try to bring a balance to the team and break the echo chamber in which everyone repeats the same idea over and over.
In a green-field project, what we need is not to choose one side from the beginning, but to carry both perspectives together. Some best practices and principles must be internalised and treated as non-negotiable. Especially basics around security, data integrity, and a certain level of maintainability should be non-negotiable. At the same time, we need enough engineering instinct to smell the pitfalls we are likely to suffer from and keep them in mind, even if we do not address all of them on day one. On the other hand, we must clearly understand the expectations and limitations around us.In other words, simply thinking about what resources we have, what is expected from us to be delivered, where the red lines are, and what the minimum value is that must reach the ground. We should also have a view of the potential future of the product, the areas where it may grow, and the improvements that may become necessary later. However, none of this should break our contact with delivery. Value should move in small and meaningful chunks, not remain as a grand promise waiting at the end. And finally, our technical strategy should not live in isolation. It must align with the direction, priorities, and limits of the other stakeholders around the project.
In a PoC (proof of concept), the balance naturally shifts more towards pragmatism, because the main purpose is not to build a durable system but to test an assumption as quickly and clearly as possible. At that stage, speed of learning matters more than architectural elegance. You are trying to find answers to questions like can this work, does it create value, is it worth taking further? For that reason, a PoC should stay narrow, cheap, and purpose-oriented. You do not build every layer properly, you do not prepare for scale, and you do not spend weeks polishing something that may be thrown away. However, even a PoC should not be built recklessly. Certain red lines still remain, especially around obvious security risks. Furthermore, misleading results and decisions that may accidentally drag a temporary experiment into a production path. The healthy mindset for a PoC is like moving fast, proving or disproving the idea, learning as much as possible, and resisting the temptation to mistake an experiment for a finished foundation.
Conclusion
As a result, a senior needs to notice the moments when the centre of gravity tilts too far towards either pragmatism or idealism. Avoid going too far in both directions. Always use one to balance the other. If politics teaches anything, it is that stability is not achieved by eliminating tension, but by managing it. Software development is not too different. Idealism prevents your codebase from going into chaos. Pragmatism prevents your team from disappearing into theory and helps you deliver visible value. You will feel this dilemma in every sprint and every architectural debate, and that is normal. The goal is not to become the perfect engineer. The goal is to become the engineer who can make deliberate trade-offs, in the specific context they are in, and leave the code and the team a little healthier than before.
Suleyman Cabir Ataman, PhD
Leave a Reply