Most decisions have positive and negative outcomes. When it comes to choosing what technologies to use for a software development team, it often comes down to two different “right” choices. They are right for different reasons and optimize for different things. A smart move is to optimize those things which serve peoples’ best interests (and the interests of their company) even at the expense of other concerns.
Imagine this situation brought to my attention: A team member observes upcoming code duplication between two systems down the road between an iOS and Android product. Among other things, they point out a technological solution that involves adding an additional language that would let them share code between iOS and Android.
From that single point of view, a solution like that sounds OK. Yet, what are the consequences? As you would expect there are pros and cons.
Let’s start with the cons. Adding new things to a technology stack of this kind may cause the following things:
- Overstressed team by spreading the team too thin
- Integration overhead
- Expertise silos
- Resistance to refactoring
- Unforeseen issues due to an increase in overall architecture complexity
- Increased time and pain around troubleshooting
- Longer time to get new team members up to speed
- Enjoyment of work going down for some and potentially all
Overstressed Team by Spreading the Team Too Thin
This deserves diving into a little. Imagine the team has recently adopted Android. Let’s say they recently also adopted a new programming paradigm such as Functional Reactive Programming. Now add a couple new team members. What’s the potential result? A magnification of the concerns listed above.
Good things that come can come from adding more to the technology stack:
- Reduction of duplicate code
- A new thing to learn (which can be good or bad depending on how much one has to learn currently already)
Which idea is right? Both are right in some ways and painful in other ways. As someone once said:
The hardest decisions in life are not between good and bad or right and wrong, but between two goods or two rights.
Of course decisions need to be made in part against the “-ilities” of architecture. In this case, Architecture complexity increases as one adds technologies. Lessons of the past have taught me that with the adoption of any addition to a technology stack, there can be costs to pay from an architecture and team point of view.
However, consider the people aspect of this too. The quality of a person’s life and their happiness affects productivity. So, measure decisions against those things that will make you excited about working and contributing as well. I highly suggest keeping those in mind. Otherwise, nothing will get done if you are fighting against the human nature of people seeking happiness.