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. The so
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

Who is afraid of immutable data?

Anand Kumar Keshavan   Founder/Partner  Swanspeed Consulting Lately, my LinkedIn feed has been getting posts about events on functional programming with special emphasis on how to deal with immutable data . True, many programmers are puzzled when told that from now onwards you shall not modify the value of a variable once it has been initialised. "But how can I work with  loops? Doesn't incrementing a counter need the value of a counter to be changed?"  This is just the result of doing something  over and over again and can be overcome by learning some programming techniques such as recursion  and map/reduce over collections.  The larger problem, however, lies with the questions of the following nature: "What about real world things like account balances ? How do I change  the account balance of I am not allowed to change the value?".  ( To be fair to programmers who are new to the functional world , such questions have been raised by some eminent though
Read more