VI #001: Picking the Right Tech for Software Architecture: 5 Considerations

Read time: 6 minutes

As a software architect, choosing the right programming language(s), frameworks, and technologies is an important decision that will have a major impact on the design and performance of a product or platform. It’s important to carefully consider the strengths and weaknesses of different languages and tools and choose the one that best fits the needs of a project.

Over the years I’ve been building software and building teams to build software, I’ve worked with and been responsible for selecting a wide range of programming language(s), frameworks, and technologies and experienced first hand the good, bad, and the ugly that can come from such decisions. Here, I attempt to share some of what I have learned along the way in this topic. I hope it’s helpful.

1. Consider the fundamentals - requirements, team, resources, maintainability

The following fundamentals should always be considered when deciding the right programming language(s), frameworks, and tech for a given project:

1. The requirements of the project: What are the specific needs of the project? For example, is a language needed that is efficient for handling large amounts of data, or one that is easy to learn and use?
2. The skills of the team: What languages are the team members familiar with, and which ones would they be comfortable using for this project? It's important to choose a language that the team is comfortable with, it will make the development process smoother and more efficient.
3. The resources and tools available: Are there robust libraries, frameworks, and other resources available for the language being considered? Are there strong tools for debugging and testing in this language?
4. The long-term maintainability of the code: Will the language chosen make it easy to maintain and update the codebase over time?

2. Prove feasibility and value before adopting more widely

What is the real value that adopting AI/ML, Big Data, Blockchain, NFTs, HotNewFramework.js, or <insert favorite buzzword here> is going to bring to the project? How will it benefit clients and the business and how has this been validated? Furthermore, will it even work? How will it integrate with existing application ecosystems? Before making a large investment in a particular technology direction, it can be helpful to identify the riskiest assumptions, and then devise and carry out small experiment(s) in the technology in question before jumping head-first into adoption.

Such proof-of-feasibility and proof-of-value experiments can be achieved in many ways and a good leader should challenge and coach their team to help them figure out concrete actions they can take quickly to de-risk the bigger decision. Want to migrate from React to Stencil? From Oracle to Snowflake? Maybe a “spike” could be a worthwhile first step. The faster the experiment can be carried out and the less that needs to be built to get the answer, the better. Even using a cloud API, SaaS or no/low-code tool, wireframe, or even a whiteboard session may be sufficient instead of or before building out a proof, depending on the situation. Many of the ideas of The Lean Startup, Design Sprints, and other lean/agile approaches can be helpful here. This evidence-based approach can also help in overcoming cognitive biases and other human elements, addressed in the next point.

3. Consider the human element

There is always a human element to decision making and software architecture decisions are no different. It’s important to be cognizant of the humans involved in the decision - the decision makers, the influencers, who will be impacted and who stands to benefit, and to consider the various agendas, blind spots, and other psychological and political factors that may be at play. Engineers often want to work with the latest tools, techniques, and trends to grow professionally. When starting a new project and hiring new developers, it can often be easier to find high quality candidates with experience and desire to work in newer, “trendy” languages and frameworks rather than older, more established ones. However, beware of Resume-Driven Development - the latest trend itself may not be the best fit for the project itself and every language, framework, and technology naturally has its respective focuses, strengths, and weaknesses.

The “law of the instrument” cognitive bias can also come into play (”to a person with a hammer, every problem looks like a nail”), whereby a particular individual may specialize in a certain technology and wants to continue using this regardless of whether it’s best for the project. As a leader, developing awareness of such factors for the decisions they are involved in an responsible for is important, as is helping establish a culture and process for the organization to consistently make sound evidence-based architectural decisions themselves in a collaborative, positive, scalable way.

4. Consider “buy” or “use” vs. build

A software architect should always ask themselves before starting a given product or feature, will this help us build a sustainable competitive advantage for our organization that highly differentiates us from our competitors or are we essentially copying them or even “reinventing the wheel”, so to speak? Should we build, or should we “buy” or “use” a tool from elsewhere, either externally or internally from the company to address the requirements? With the growing no-code and low-code movement, the advent of generative AI, cloud APIs, open source, and other tools, it is becoming easier and faster every day to create high-quality, production-ready software applications.

A key challenge for software architects then becomes selecting and integrating between various tools, to most effectively serve the needs of the project in question. For example, a company providing enterprise SaaS software might choose to invest in ML-powered features that help them deliver a highly-differentiated user experience for their clients, whereas it might make sense to source ML-powered security and privacy scanning tools from a third-party that specializes in this, rather than building this aspect of their overall tech stack in-house. Even within the hypothetical decision to “build” ML-powered features in-house, there can be the opportunity to leverage state-of-the-art open source pre-trained ML models, fine-tuning them for their specific domain and project needs, benefiting from a combination of both closed and open innovation in unique and commercially valuable ways.

5. Embrace agile architecture

In today's increasingly fast-paced, constantly-changing technology landscape, naturally software architecture decisions need to evolve too. If components of or the entire architecture itself can be changed in the future, best to not overthink it. Take a decision quickly, act, and adjust later if needed. Proof-of-concepts can and often should be thrown away, and using a modular approach can be helpful to allow architectural components to evolve independently. Want to migrate an existing system to a new tech stack, to gain advantages from some hot new technology? Rather than an expensive and time-consuming “lift-and-shift” exercise that could take a long time before users can benefit from it, maybe a phased-approach might help - e.g. building new features and development, while splitting out a separate project for migrating the legacy system.

Embracing agile architecture means being open to making changes and adjustments as needed, and being willing to pivot and iterate as you learn more about your users and their needs. It can also be helpful to emphasize the importance of collaboration and communication in agile software development, as this can help teams stay aligned and make the most of their flexibility and adaptability.

That’s it for today.

TL;DR

5 considerations to help choose the right programming languages, frameworks, and other technologies for your software architecture. I hope these help you as much as they’ve helped my teams and me.

1. The fundamentals - requirements, team, resources, maintainability
2. Prove out the value
3. The human element
4. “Buy or “use” vs. build
5. Embrace agile architecture

See you next Sunday.

Whenever you’re ready, there are 2 ways I can help you:

1. Work with me 1:1 to build your team, product, platform, or career.
2. Book a free discovery call with me and let's explore if your business needs would be a good fit for my advisory services. If we’re not a good fit, rest assured I’ll kindly let you know - I prefer the right founder and the right company at the right time.