C++ or Java: What You Need to Consider Before Making Strategic Technical Decisions
1. Overview
Difficult decisions usually involve some risk due to the uncertainty around the consequences of our choices.
In a previous article, we articulated some guidelines that would allow a group of professionals to make efficient and effective decisions.
In this one, we will focus primarily on technical decisions as these occur in a specific context, and their consequences deserve special attention.
Technical decisions are tricky to resolve for two reasons:
- First, their future ramifications cannot be immediately discerned.
- Second, they are usually left to technical experts. This may require some explanation.
In effect, the technical experts will decide solely based on technical criteria. Concerns of a non-technical nature, such as business value and customer satisfaction, are typically ignored.
When presenting the Principles of Operational Excellence in Software Development, we have argued that technology serves the business, not the other way around.
This statement was elaborated in Principle 5: Focus on Business Value and Principle 6: Use Mature and Proven Technology to Serve Your Customers; these topics will be reopened in the following section within the current context.
This article will suggest some guidelines to help you make tough technical decisions. These guidelines should be solid and universal enough to be used in almost any situation where you must decide between equally attractive technological alternatives.
We hope that you find this information useful.
2. Guiding Principles
We will present five guidelines (or criteria) in the following subsections, and we recommend that you use them to facilitate your decision-making processes.
To make the discussion more interesting and undoubtedly practical, we will look at some conventional ways to such issues and then contrast them with the proposed methods.
2.1 Using Mature Technology
2.1.1 Problem Description
Using the latest and most remarkable technologies can bring a lot of self-satisfaction and potential material gains. New technologies can be easier to use, have better security, and offer attractive new features. So why would you be better off using older technologies?
The Gartner Hype Cycle visual represents what a breakthrough technology would go through before becoming mainstream. Have a look at the below graph.
There is various criticism around the usefulness and accuracy of the Gartner Hype Cycle, but these could be safely ignored for the sake of this discussion.
Whether emerging technologies follow this particular cycle or not is immaterial as far as this discussion goes; what we are primarily concerned about is that some emerging technologies make it to become mainstream while others don’t.
The last thing you probably want is to adopt a technology that is unreliable, immature, and gets dropped by the community in the near future. The latter is probably the most vital; technologies improve and mature as more people adopt and contribute to them.
2.1.2 Conventional Wisdom
Fresh graduates and professional experts alike will be biased towards technologies they were already exposed to at the university, during their career, or in some online social group, they are part of.
This bias is known as cognitive ease and adversely and systematically affects people’s judgments. In essence, it states that people tend to have stronger beliefs in the truth of statements if they are easy to read and memorize (presented in a clear font, contain rhymes and familiar words).
Because it is hard to evaluate the merits of technology we are unfamiliar with, we tend to substitute the difficult evaluation question with one whose answer is readily available; do we like the technology or not? The answer will depend on our familiarity with the technology.
2.1.3 Alternative Method
An alternative method to using unproven technology is to use existing mature ones. Here are some arguments to support this argument:
- Life Expectancy: You might wonder whether old technology is immune to being displaced by innovative ones; it’s not. However, the matter of fact is that the older the technology, the more users it has, and the more problematic and slow its replacement would be. In his landmark book Antifragile, Nassim Taleb describes the life expectancy of a good idea to be at least as long as its age today. Architecture that is 100 years old will probably live for another 100.
- Community Support: It’s probably far easier to find support in the online community for an issue encountered by many developers than a rare bug in a niche technology. Multiply that by the number of developers you have, times the number of hours they spend looking for support, times their hourly rate, and you get an estimate of some of the cost of using niche tech.
- Availability of Skilled Resources: Bob Martin maintains that the number of developers in the market doubles every five years. This means that a random sample of developers from a team will have less than 50% of its headcount with more than five years of experience. Compound that with relatively new technology, and you get a shortage of skilled resources. In some of today’s markets, hiring experienced consultants is the norm; you need quick access to good developers.
- Feature Richness and Easy Integration with third-party systems. This category also includes support for various messaging protocols, libraries, utilities and tools. Let’s say you are a provider of a novel database engine. Would you choose to support integration through every programming language, or would you instead focus on the most popular ones? Popularity brings about a cumulative effect (which Nassim Taleb refers to as the Mathew effect in his book The Black Swan); popular concepts, programming languages, and technologies become even more popular in the same way rich people become even more prosperous.
It is crucial to distinguish between business models (such as cloud deployment or Software as a Service) and technology. Business models impact how customers do business with you, whereas technology may or may not.
Business models must be constantly revised and updated to stay ahead of the competition and offer the best value to your clients. In contrast, technology is simply the vehicle transporting business value from your production lines to the end-user. A bit more on that will be presented in the next two sections.
2.2 Focusing on Business Value
2.2.1 Problem Description
Would you pay an extra 100$ for your phone if the software used a “better” programming language?
Placing oneself in the customer’s shoes is no mean feat. Firstly, it requires some genuine effort as it’s not intuitive. Secondly, you need to have been the end-user or have had an excellent vantage point to observe and understand customer needs firsthand.
Unfortunately, the boundaries between what’s good for the customer (or the business) and what you believe is good can be easily blurred if the discussion turns too technical; you can always rationalize a lousy business decision with an excellent technical argument.
That’s not to say that an excellent technical decision is not necessarily a great business one. It’s just that decisions of this nature are usually a compromise between two conflicting requirements.
A widespread example of this compromise is the choice of programming language, naming conventions, database engine, or messaging format.
2.2.2 Conventional Wisdom
Complex and mature organizations usually have a dedicated role in analyzing customer requirements and translating them into technical ones. This role is sometimes referred to as Business Analyst or Business Engineer, the keyword here being business.
Smaller or less mature organizations focus primarily on having development staff who occasionally perform business analysis and solution design functions.
Trained as software or computer engineers, we look at every decision we are supposed to make from a purely technical angle, with almost complete disregard for business or customer interests. Issues of cost, delivery timeframes, and project management are someone else’s problems.
2.2.3 Alternative Method
The alternative approach is reflected in Operational Excellence: Principle 5: Focus on Business Value.
Every time you decide to invest time in a task, you will need to ask yourself whether this effort adds value to your business or not.
To evaluate your position, you can ask the following questions and determine if at least one of them has a positive answer, in which case the additional effort is justified.
| # | Question | Example |
|---|---|---|
| 1 | Enhance user experience | With quality products |
| 2 | Solve an existing business need | Thru innovative and useful features |
| 3 | Reach a new or broader customer base | Offering targeted solutions |
| 4 | Provide an edge over the competition | Deliver faster, cheaper, and better products |
| 5 | Lower costs or increase profit margins | Developing resellable features, lowering lead times and development and testing effort |
| 6 | Improve quality and customer satisfaction | With robust and reliable releases and efficient, fast customer support |
| 7 | Benefit society | With an altruistic purpose for the organization besides maximizing shareholder profit |
| 8 | Enhance your business model | By offering different ways of packaging and deploying your products and services |
Be extra careful when looking at enabling tasks, which are a class of things you do to facilitate value-adding tasks, as these can be easily confused for non-value-adding ones.
2.3 Securing Competitive Advantage
2.3.1 Problem Description
No single organization can secure a competitive edge over its competition forever. Sooner or later, a random competitor, who may only need to be marginally better (see The Black Swan on power laws), can grab the first position and stay there for the next few years.
The struggle can be so fierce in some industries and markets that a single winner emerges and completely dominates everyone else, at least for some time.
Under such extreme conditions, you will need to use every tool you have to secure some advantage over your peers, no matter how small. The technology you use, the time to market, and the cost of your products and services are all legitimate weapons you can deploy.
2.3.2 Conventional Wisdom
It is customary to exclude topics like a cost/benefit analysis, time-to-market, and impact on the customer from technical decisions.
In some cases, these parameters are not recognized as legitimate criteria to be considered, and in other cases, they are just unknown to the decision-makers.
2.3.3 Alternative Method
On every strategic decision you make, consider the following questions.
- Time-to-market: Are there other vendors competing in the same niche? Is there a net benefit if we deliver our new feature before the competition? If the answer is in the affirmative, your time-to-market is crucial. Remember: success is cumulative. The more successful you are, the more customer you get. It’s a positive reinforcing loop.
- Cost/Benefit Analysis: it might be appealing to adopt new technology, replace an aging one, refactor legacy code, address all technical debt, or over-engineer or over-parametrize a specific feature, but have you considered the cost vs the benefit? Is it proportionate?
- Impact on Customer: How does one choice you are about to make impact your customers? Does it constrain how they use the product, either now or in the future? Does it make it harder or costlier for them to maintain it? The evolution of the product needs to be towards flexibility, cost-efficiency, ease of integration with third parties, and the possibility of opening up new markets or broadening existing ones.
2.4 Targeting Specific Customer Base
2.4.1 Problem Description
While many decisions involve compromising between two conflicting requirements, this is especially true when considering technology choices in conjunction with targetting a suitable customer base.
On the one hand, it will be prohibitively challenging to build a one-size-fits-all solution; in such a case, the solution needs maximum flexibility, adaptability, integrability, performance, modularity, and deployment options. You can spend a lifetime building such a solution and never release it.
On the other hand, some choices can bind you for the product’s lifetime.
2.4.2 Conventional Wisdom
Because we are so bad at forecasting and risk-averse by nature (and we prefer to gamble instead of taking sure losses), we will typically try and take the safest path.
This behaviour is fantastic as it prevents us from making strategic errors that inhibit our ability to grow or expand later on.
The problem is that it’s not always the case. It is sometimes possible to take a cost-effective route that does not restrain our future movements, at least not in a prohibitive manner.
Still, we would prefer to take a more expensive (although technically sound) decision. The “rationale” this time is future-proofing.
2.4.3 Alternative Method
The alternative method we propose is the following:
- If the feature you are trying to decide upon is fundamental and strategic in terms of solution architecture and design, take the safest option where you are reasonably sure it will stand the test of time.
- Alternatively, if the feature is not strategic, identify the customer base you are targetting and make sure it fulfils their needs cost-efficiently.
An example of going overboard is overengineering. This is where we typically overestimate a new feature’s adoption rate.
In such cases, we generate an elaborate and costly design that is not justified based on what we know now regarding client requirements. In such cases, future requirements by a different client base can always be added later.
2.5 The Value of Experimenting
2.5.1 Problem Description
In some cases, research alone is not enough; you need to see the software, product, or technology in action before making any decisions.
This situation occurs when the contemplated solution or product is mission-critical, complex, expensive, and hard to change, and its impact will not be visible in the short term.
2.5.2 Conventional Wisdom
Before purchasing their product, big corporations usually conduct a Proof of Concept (POC) with a vendor.
While preparing for the POC, a list of minimal and nice-to-have requirements is set, and the POC determines which subset of items are available off the shelf or through customizations.
POCs are suitable for existing products; it requires more effort to put a new hypothesis to the test. Most vendors would usually set aside an environment for demo purposes only. That luxury may not be available when, for example, you are building a custom application or trying to choose between two different technologies.
In the latter case, professionals might rely on research, consultancy reports, or expert intuition.
2.5.3 Alternative Method
While human beings are generally impatient (this is the primary reason why a dollar today is worth more than a dollar tomorrow!), it pays off to go against our nature when the stakes are high.
Below is a list of things you can do to test the different available options. The goal is to obtain more information, hoping to tip the scale favouring one alternative.
- Step 1: Identify the hypothesis you need to test. For example: Is C++ equivalent to Java for building an IT system?
- Step 2: Determine the technical and logistical feasibility of a POC. If it proves challenging, try reducing the scope. Avoid jumping to conclusions via the expert intuition route.
- Step 3: Make a list of minimum criteria the solution would need to satisfy before adopting it. Make sure the items on the list are measurable and achievable in a predefined timeframe. For example: can I design software using programming language X that achieves 1000 Transactions per Second on specific hardware?
3. Final Words
If we had to summarize this article with three thoughts, they would be as follows:
- The choice of technology should be subordinate to the business strategy, not the other way around.
- Technology is a vehicle for carrying business value, not an objective of its own.
- When in doubt, experiment.
New tools, ideas, and technologies emerge and die every day. You can waste much precious time if you drop everything to try out every new fancy one of them, the time you are better off investing in your products and people.