Why a CEO should care about the programming language the team uses

I’ve seen so many companies dying because they choose the wrong tools to build their unicorn, moreover, this phenomenon not only tears up early startups, but also can destroy big companies.

Managers can’t cope stopping production and invest in the long run. We all need to meet deadlines, right?

My father used to trinked with electric machines and other magic artifacts a lot, he taught me some tricks, so I tried to move some wires around. Suddenly, he called me out for using the wrong tool. Use always the right tool for the job, he used to say.

First of all, why do engineering teams do the job with a flat tire?

Second, why would you avoid using better tools?

And how can someone develop a feature when it takes tons of hours to deliver it?

A real example

Back in 2015, I was part of a big company that provide water management services to Barcelona. At some point, this company obtained the money and resources to recruit a new team of 50 people to develop the next generation of its software suite.

But not only that, they had plenty of time to get the job done. When I joined the team, the project has been running for almost 2 years.

They developed almost nothing more than a complex system and designed a complicated workflows between teams.

At this point, the work speed was so reduced, that it took for a team of 7 a whole week to implement a new simple data field in a form, but this is not even the worst part.

However, since middle managers know that changing anything was a headache, they spent even more time and effort avoiding changes.

In fact this reaction was caused out of fear to overload the already stressed team. So when designers came up with a new idea, managers fought and rejected it, even if those ideas were Albert Einstein level.

Don’t you believe a change per week can stress a team? You might think I’m mocking you. Well, I wish that was a lie too.

The reason why changes take forever

If you never saw a company working, it is difficult to imagine what can cause this terrible mess, so that’s why I like examples a lot, because examples has the highest ratio of human to human information exchange.

I don’t want to bother you with deep technical stuff so I’ll simplify as much as I can.

Let’s face the problem of creating a Date component. We will find out how much complexity a simple Date field can hide from the naked eye.

A calendar field.

To add this Date field the team decided to create their own solution. You as a non-technical person, may think that the problem is just a move in the calendar and it shouldn’t hurt too much.

This is a fatal mindset.

Let’s take a look at how much work a Date field requires:

  • Changing month, also changing the days disposition and count for each month.
  • Changing year, also changing months and days.
  • Create a new date format that the backed could work with.
  • Animations. A new whole animations systems, what could go wrong?
  • Configuration and options to add styles, if you’re lucky JSON (configuration) and CSS (styles) will be used but it may not be that day.
  • Testing, I hope you got some.
  • Bug fixing, this will happen a lot, the most common error in software is overconfidence that things will not break when someone else uses them.
  • Two weeks after releasing the component, another team found that their days are off number. Leap-year, how could be forget about this?
  • Selecting a date from mouse-click.
  • Selecting a date from a mobile tab.
  • Localization, we want other countries to use our app so: Lunes, Martes…
  • Internationalization. Wait, is not localization enough? Well, not every country in the world starts the week at the same day. North America likes Sundays, others prefer Mondays.
  • Search dates using user input. Customers may just want to write down the Date and skip searching using clicks and tabs.

The above list is not even finished, but I think you can get the idea.

Don’t reinvent the wheel

You may wonder if this very problem is already solved.

Yes it is. Teams around the world solved this issue a dozen times.

Then you can start thinking why someone would do the job again. Imagine a car company engineering the brake system for every model, over and over.

I know this could be a bad example as Tesla redesigned the whole car from scratch but Elon Musk recruited skilled car designers to do the job. Teams at Tesla don’t start from zero as they know the problems already, solving them is only half the work, actually knowing the problem is king.

This is just a simple sample, but I’ve seen this same pattern in so many companies, more than I can chew.

Maybe they are just using the incorrect database for a particular use case that the team has to solve.

Maybe they have chosen the wrong language or framework, or even using the so famous Scrum system that could not suit your needs.

But why? Why CTO and tech people tend to choose certain technologies, tools and programming language over others?

Well, only Gods knows. That is why managers must have sufficient knowledge to make effective decisions and lead the team to victory.

Managers must be technical

Software is eating the world, so managers should be prepared for future challenges. Not only you should know the buzzwords like Blockchain or AI, but you should also to use them and see their true potential.

Imagine being in a decision-making position and skipping the Internet revolution. Imagine owning a horse company when the Ford T came along.

You really don’t want to be that guy.

In conclusion, that’s why I decided to create a series of articles that tries to summarize all the knowledge a good manager must master to avoid the major caveats of the software industry.

Leave a Reply

Your email address will not be published. Required fields are marked *