Swan Lake

Srinivas Chillara, Founder partner, SwanSpeed Consulting Ramesh Venkataraman penned a castigating article regarding the state of the ethical stance of managers in India. Somewhere it struck a chord and I've think there is an important parallel to draw in the IT industry. Here I'm not referring to ethics, but how we respond to the Q: Are we true to ourselves? As professionals, programmers, managers etc. The pressures of daily work and several traditions conspire to create a gently debilitating ecosystem. Living on and off in UK and Ireland for just three years, on my return to India, I was struck by how few people here admit not knowing something. We have a strong tendency to pretend that we know very well, even if we have only just heard of it (maybe several times). We mistake this familiarity for knowledge. And we do this over and over again, so this becomes second nature. We see this sort of knowing all around us, and feel part coerced and part comfortable nodding knowl

Anand Kumar Keshavan   Software industry has its own quirks. What the rest of the world calls "defects", we refer to them as a "bugs".  The word has become so common that it is being used in other contexts as well. For example,  does a car company say that a car model has a "bug" in its transmission? No, but  same car company will use the word "bug" for  any defect caused by a flaw in the software running on the onboard computer of one of its models.  I learnt this recently, as the service agent of my car told me that he had to upgrade the software in the ECU due to a "bug". When I asked him what he meant by "bug"... well,  he couldn't define it. Computing folklore tells us that the word was first used by engineers,  colleagues of the pioneer  Grace Hopper  , while working on the early electromechanical computers. It is said that  they had traced a particular  fault in the computer to an actual insect that had lod

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

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. For

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 unwie

Anand Kumar Keshavan  ( Founder/Partner-  SwanSpeed Consulting ) Amongst the many "non-functional" attributes of software - scalability, availability, extensibility and so on- testability remains the one that is most difficult to grasp. Scalability can be tested by using appropriate tools. Availability can be measured by plotting downtime statistics. How does one "test" for testability? Intuitively, testability of a piece of code or a large software system defines its ability to be tested in some kind of repeatable way by a group of humans or by other programs within a reasonable/ predictable period of time. While testability may be vague and hard to define, lack of testability throws up a lot of symptoms. Here are few of them: Release cycles are unpredictable- from the time a set of features have been declared to be "done" by developers to the time such features are deployed. This "last mile" problem has existed for non-trivial

Anand Kumar Keshavan  ( with inputs from  Nirmalya Sengupta ) The world of computer science moves at an excruciatingly slow pace. Foundational work for functional programming was done over fifty years ago and yet ideas from the paradigm have come into mainstream programming only in the recent years- with even the lumbering Java adopting some of its features in its 8th version. Meanwhile, the Haskell community ( and its micro communities led by Idris and Liquid Haskell ones) have been advocating type theory based ideas wherein the goal is  to reach a nirvana-like situation- “ if it compiles, it runs ”.   (The idea behind this are also several decades  old -- computer science minded readers are encouraged to read  Type and Programming Languages ,  by Benjamin C Pierce. and the more mathematically oriented ones are directed to  "Curry- Howard isomorphism" ). Type Driven Development None of this is a prerequisite, nevertheless, to understand the motivation behind