Does business care about programming languages?

Developers and software companies often put great emphasis on programming languages or specific frameworks they use. Does it really matter for the business in any meaningful way?

I honestly don’t think so, but is it really the whole story? I don’t think that either.

Short background

The past few years I had the unique opportunity to work as a Senior Software Developer, that has been connected to the business side of the process as well. I’ve been a Tech Lead, Product Owner, Project Manager, Agile Community member and Change Agent (yup, you’ve read that right – sounds like a corpo-role …and it was 😁). My roles forced me to talk to business people everyday and I’ve grown not only to understand their point of view, but also to see how our worlds can learn from each other.

Business needs

Obviously what I’ll write in here is a huge generalization, but there are a few things in common across different businesses needs:

• Deadlines or how I like to call it: time-to-market
• Quality, as in: no bugs
• Cost of development and maintenance
• Throughput, as in: how many users can we work with?

Business perspective is quite straightforward – software development is a means to provide value for the end user and make money from that value. In a perfect world software development would be fast, stable and extremely cheap.

Software development answers for business needs

Not sure when exactly, but at some point I’ve realized that the main reason for software existence is to answer business needs. Pretty much nobody (apart from software developers) cares about technology and specific, beautiful and/or elegant solutions.

On the other hand smart business people understand, that software development is expensive and extremely complicated endeavor, so they are involved in development process, provide fast feedback and know what they need to prioritize (e.g. for some domains, like cryptocurrency main priority will be time-to-market, but for medical field priority will always circle back to quality).

Does business care about programming languages?

Nope. Software needs to fulfill specific needs within business constraints and that’s pretty much it.

Is that really fair? Also: nope. Looking once more at the business needs: all of them are dependent on technology in some way:

• Time-to-market? Try to write a calculator in Assembly – you will take absolutely forever!
• Quality? This just screams JS vs TS discussion (which is a heated argument, that I will not go into today)
• Cost of development and maintenance? Higher level languages make it faster to create the solution, while lower level languages give you more control (especially useful in embedded and performance-dependent systems). Usage of cloud provider make it faster to host properly, but it’s a subscription cost
• Throughput? Proper software architecture will help here immensely, but once again language levels do play a part

This leaves us at a place, where technology and programming language does matter, but will never be the most important factor and as software developers we have to understand that.

So why the heck am I excited about F#?

I’m mainly interested in implementing the logic of the system. I’m usually focused on projects that prioritize quality, rather than time-to-market or performance. This is precisely the reason why I’m working with .Net and C# – I prefer higher level language, with strong, static typing, that provides me with a good balance of time invested in development and quality of code that I write. Moreover, .Net gives me access to a huge library of ready-to-use nuget packages and, since a few years back: deployment on any hosting platform. Additionally ASP .Net Core is a mature framework that provides great levels of throughput for the business needs, so it fits in nicely in the picture.

Main issue with changing the programming language is that you automatically have to sacrifice the whole ecosystem, which costs you development time. This is where F# comes in for me. I can change the language, but stay within the .Net ecosystem with all the deployment and package goodness that I’m familiar with.

To read the full article, follow the link