Thu 7 Sep 2006
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:

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.

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.
September 29th, 2006 at 7:57 am
[...] … and here we are after a few years of reading other people’s views I’ve finally launched myself into the blogging world. If I’m looking for the tipping point, Malc’s post on The Engineering Trade is certainly was probably it, but constant conversation with Tom regarding the state of project management in IT has to be up there too. [...]
October 2nd, 2006 at 2:08 pm
This is the constant tension of the “Get it right first time!” brigade, of which I’m a fully paid up member.
The blue hashed area is the last 20%, but the “I just want it to work now!” style of management may well earn the early fruit of the red hashed area, but they’ll always end up restricted to the dotted line…
October 8th, 2006 at 6:54 pm
[...] In either case we fail to deliver what the customer actually wants. Even worse, The Engineering Trade points out that embarking on The Big Re-write is selling the present to buy the future. Considering that the customer only wanted a small addition in functionality this is terrible, they’ve already waited for the application to be written once. [...]