An accomplished CTO spoke to me recently, lamenting the technology stack choice of the previous CTO. She noted the team’s inability to easily deploy software and wondered if the previous CTO’s choices were the cause. A bit of additional probing revealed underlying architectural, design, and quality problems that prevented rapid and safe delivery. Her opinion was that using back-end JavaScript instead of an older language would both open the doors to a larger field of potential employees and result in faster software delivery. The current CTO focused on the shiny technology stack, but their problems are deeper and largely irrespective of technology choice.
Painting on a blank canvas is one of the most thrilling and unnerving responsibilities of a CTO. The business may provide a vague notion of what they’re hoping to accomplish and leave it to the CTO to harness a vision, pick a technology stack, hire a team, and start executing.
You may think the make or break decision is selecting a winning set of technologies that comprise the stack. If so, you’d think wrong.
More often, a CTO doesn’t begin with an entirely blank slate. Unless it’s a startup situation with no employees, there is usually a cadre of people on staff and maybe a legacy product to rebuild. In these circumstances, practical concerns often influence technology choice. Should the skill-sets of current employees influence technology choice, aka the “If you can’t be with the one you love, love the one you’re with” model? Should technology decisions hew to the labor pool and result in a flashy stack that attracts top-notch talent?
Many software developers are early technology adopters, always on the lookout for the next great language. Many developers will, indeed, gravitate to companies that offer the most cutting-edge, obscure technology stacks. It’s understandable, but also unfortunate that engineers run to the latest and greatest and lose interest in older but perfectly great technologies.
Developers tend to fall in love with esoteric languages that promise to address the shortcomings of previous languages. In the chart above, developers trend toward lesser-known and difficult languages. Smart CTOs recognize the quixotic developer quest for the perfect language and balance it with practical concerns like choosing a stack that’s secure, maintainable, scalable, proven, and addresses the specific requirements of the implementation. The chart below shows the most widely used languages of 2020. Note the dichotomy between the two charts reflecting languages developers want to use versus languages they’re actually using.
One of the biggies of late is the MERN (MongoDB, Express.js, React.js, NodeJS) stack or a variant like MEAN (MongoDB, Express.js, Angular.js, NodeJS). Development teams are flocking to these JavaScript-based technologies with NoSQL databases in lieu of older stacks like Ruby on Rails and LAMP (Linux, Apache, MySQL, PHP). Many of the coding academies, which act as bellwethers of technology trends, also appear to be migrating from Ruby on Rails to MERN.
Here’s the big secret: The technology stack decision is a big, shiny distraction from what really matters most. Any of the stacks in the previous paragraph can work just fine. Although the selection of technology isn’t a one-size-fits-all decision and each technology has its strengths and weaknesses, none of them will doom a company to failure or guarantee its success. On the other hand, there are plenty of unsexy, less acronym-laden CTO-level decisions that can make or break a company.
Some of the CTO-level decisions that can sink or elevate companies:
- Architecture —Monolith versus micro-services? Typically, most companies begin with a monolith because, without practical experience in the business domain, it’s difficult to carve the boundaries of micro-services. Most teams that begin with a monolith reason that eventually they will carve it into services; the architecture determines the ease of doing so.
- Database Design- Regardless of the database technology (NoSQL versus Relational), a well-designed schema or model is crucial to long-term success. If, for example, a Customer has multiple meanings in the product, a DBA should represent each context separately in the database. An understandable database model that doesn’t overload entities is a recipe for success.
- Deployment Pipeline- A constellation of important items include quality, automation, and continuous integration/delivery. Frequent, safe, and undramatic software releases are the goal — easy to say but require a muscular and sustained effort.
- Branching Strategy- Sounds trivial, but one of a CTO’s most consequential decisions is how a team uses version control. The right choice facilitates easy and frequent deployments and the wrong one makes it difficult to release software on a regular cadence. Branching strategy isn’t one-size-fits-all (see this Continuous Delivery blog post), so it’s important for a CTO to understand the workflow that best aligns with the needs of the business.
The risk of choosing tired, outdated technology is attracting tired, outdated developers. In contrast, choosing red-hot, unproven technologies may cause an Icarus-like meltdown. Anything between these two extremes is probably just fine. The common denominator of technology stacks is that none of them solve the four crucial elements for success. As the CTO I spoke with recently discovered, technology stack decisions mask problems resulting from failure to focus on the unglamorous but essential side of software development.
