Programming languages and Investment bankers


Anand Kumar Keshavan ( Founder/Partner- SwanSpeed Consulting)

Huh? But you read that right. A few days ago I met a senior executive at a technology company ( who is fairly tech savvy), who told me that all products in the next few years must be built using either node.js or Golang as the language for the backend. Further enquiries ( from a puzzled yours truly) revealed that this is based on advice from very reputable investment bankers.


The influence that investment bankers have on programming languages is not new- after all, Goldman Sachs have been on the Java standards committee for a very long time. Even Credit Suisse seems to be on the committee. And this committee is the one that decides what JSRs will find their way into the next version of Java. And it would seem that Goldman Sachs, and investment bank , has a say in the evolution of Java as a programming language. (A hacker friend of mine said that this is an important revelation as it explains the generally unwieldy nature of Java).


Is it a wise idea to listen to investment bankers when it comes to choosing the programming language or any other component of a tech stack? Well, almost as much sense it makes for a surgeon to choose his tools for diagnosis and surgery based on the advice of an investment banker. Or would it make sense to choose your tech stack based on advice from a surgeon?But this is only software, right?


In my opinion, choosing a tech stack for a new product (or when embarking on a major technological upgrade like migrating a monolithic system to, say a micro-services architecture) on the basis of casual remarks by investment bankers or other kinds of "non-tech" guys would be, well, disastrous. In an industry that is moving towards polyglot tech stacks, such ideas must be avoided at all costs. For example, a system that comprises of several micro-services, it might be advisable to create the services dealing with data and analytics etc , using Python, while the components that need high degree of independent scalability might be better of written using Scala/Akka( or even Erlang/Elixir, if "carrier-grade" scalability is desired), while many mundane configuration services- roles/permissions, session management etc could be written in Node.js or Java. Similar arguments could be made for SQL vs NOSQL vs. Graph databases etc. Horses for courses, is the mantra really!


Choosing the elements of a tech stack is a serious business. It depends on several factors- your application domain, degree of configurability it offers, scalability, maintainability, the capability of your team to learn, ability of your organisation to attract the right talent and so on. It would be a serious mistake to base this on the opinions of investment bankers, lawyers or surgeons!


Well, programming is a craft like carpentry and a carpenter has different tools at his disposal. And generally speaking a carpenter is the best person to determine which tool to use for which part of his craft- not a banker, accountant or a surgeon.






(The author is a computer programmer and a founder partner in SwanSpeed Consulting. If you are building a new product or considering migrating an existing system to a micro-services architecture or are looking for the best ways to solve a very specific or hard problem, do reach out to us. We bring serious muscle to such decisions).

Comments

Post a Comment

Popular posts from this blog

Model correctly and write less code, using Akka Streams

Image
One of my most productive days was throwing away 1000 lines of code. -- Ken Thompson More than two decades of writing software programs to earn some humble money and to keep the home hearth warm, has taught me that writing simple, elegant and readable programs result in much more maintainable and extensible software. Importantly, stakeholders prefer to have maintainable code. One way to ensure that  these properties exist in the code, is to write fewer lines of code , wherever possible. Generations of greats in the world of computer science and programming have been reminding us about this little yet undeniable truth. Yet, it is surprising how often we tend to ignore this, knowingly and to projects’ detriment. If we have to write programs that are simple to understand, we have to understand the problem well, before anything else. If the problem is redefined in simpler and more fundamental terms, then it becomes easier to model the problem in the programming terms. Th...
Read more

Your Microservices are asynchronous. Your approach to testing has to change!

Image
Conceptually, the idea of an application being composed of a number of MicroServices is quite self-evident and therefore, quite appealing. A complex solution, which is broken into a number of self-sufficient modules, each running on its own, each capable of responding to messages, each amenable of upgradation/replacement without letting any other know about: sounds too good to be true! The icing on the cake of course, is that each such service can run on its own containers! No wonder then, that senior stakeholders of software projects or initiatives, love to insist that the application be modelled as a bunch of MicroServices. The technology team responds favourably, of course, because everyone wants to be seen among the pack, if not ahead of the pack! Jumping in sounds exciting, even though the swimming may not be, but we don’t really care, do we? The proverbial devil is in the details. In my experience so far, the term Microservice is thrown about without much thought. T...
Read more

Building a "Platform"?

Image
Anand Kumar Keshavan  ( Founder/Partner- SwanSpeed Consulting ) In recent times, many of our clients have expressed interest in building platforms. But what is a “platform” exactly? How is it different from your regular business applications? What are the challenges that one is likely to face when one attempts to build platforms? We note that this wish to build platforms often overlooks the challenges and possibilities of business success. We have to recognise these challenges to be mentally prepared to take up such an endeavour. So, for most of us, our common day to day experience conditions us to develop applications, and this deflects our attention aways from the crucial aspects in building a successful platform. Before answering these questions let us look at software in general. One may tend to view all software as similar. What is there after all? Write some code, test it, and roll out , right? In reality “software” comes in vastly varying classes of behaviours. ...
Read more