S-Curves seem to be pretty pervasive in technology. An S-Curve exists for cumulative, delivered functionality or behaviour in a system over time. A coarse sketch is shown below:

S-Curve-1

Simply, this shows that in the first stage of a systems life, little or no functionality is being delivered as the system is being built. After the system is first delivered there is a period of rapid expansion as more and more behaviour and functionality is being delivered to the users. Finally, the system becomes overwhelmed and old and as each new delivery creates more and more bugs and the time to deliver even a quantum piece of functionality lengthens the system is finally laid to rest. The developers have a party (original developers have left) and those remaining express joy both at not having to maintain a legacy system and also at the opportunity to start again and not make the same mistakes that the original guys made.

And so we begin again.

And so we begin again because although we learn from the visible mistakes of the previous team we do not learn from the trade-offs that are hidden or not understood. The chart below shows the S-Curve for a badly engineered system (assumed same as the one above) and what we can call a well engineered system. Again, the charts are coarse and do not capture everything that is going on. They are designed to make a point and not to be accurate or as a start of a research project.

S-Curve-2

The original curve is now a dashed line and the well engineered project the red line. Forget about the fact that the lines are drawn skewy - the only important point is the shift in position of the line. These are the points:

  • The well engineered system takes longer to deliver so delivers initial value later
  • The rapid delivery value section occurs for a much greater length of time
  • The system still dies eventually.

The effect of shifting this line is, in investment banking parlance, to sell the present and buy the future. The red shaded area is the short term functionality gap - the badly engineered system is delivering more value to the users. The blue shaded area is also a functionality gap but clearly one where the well engineered system is delivering more value. As the graph is cumulative functionality, the gap at the end represents how much more user value. we have accrued by engineering a system well.

What this should also indicate is the constant trading between users and engineers between short-term delivery of value and long-term continuation of value delivery. Users know what they want and they want it now and pity the poor engineer who tries to explain that it may be better in the long-term to deliver the initial value later.

Investment Banking is merely life only more so. This functionality gap can very often be measured not in terms of some abstraction of value but in real money. Moreover, given the nature of the business, this money may no longer be available to accrue if the system is not delivered as soon as possible as the margins from a particular product collapse as it becomes commoditised.

As an engineer in Investment Banking one must constantly be valuing this trade this is only one of the reasons why it is so fascinating.

And also fascinating if you can do both - deliver something quickly to accrue early value and engineer it well to accrue more value over time.