Sunken Ships and Pirates
I have finished rebuilding the main parts of the Wilson WebPortal. I have been so impressed with its simplicity and its effectiveness that I have given great thought to whether to move the best of Charlie to the WebPortal, or the best of the WebPortal to Charlie.
While I would naturally have some misgivings about kicking the chair out from under Charlie, I am very cognisant of the economic concept of a sunk cost. Specifically, the time and effort I have put into Charlie is a sunk cost—a cost incurred in the past that should have no bearing on future decisions. All that is relevant to future decisions is future costs. In this case, the future cost will be either the time taken to move Charlie to the WebPortal, or the time taken to move the WebPortal’s ideas to Charlie. Whichever approach provides the greatest benefits to costs ratio is the approach to take, regardless of the sunk cost of Charlie’s past development.
So what would be the benefits to switching to the Wilson WebPortal? I can see three benefits. First, I would be using a website framework that would be developed and maintained by someone else, leaving me free to focus on creating websites rather than the underlying framework. Second, I could use any modules created by Paul or other developers. Third, I could potentially sell any really good modules that I might create.
What then would be the costs involved in switching to the Wilson WebPortal? I can see two costs. First, I would need to spend time learning the new framework. Second, I would be limited to the functionality that the framework provides. Most notably, the current version of the Wilson WebPortal does not support globalization in its code or in its database schema, so I would be giving this up.
Now, since I am a subscriber to Paul’s website, I have the source to the Wilson WebPortal. Strictly speaking I could tweak the framework’s code to do whatever I like. However, I cannot see that this is a sustainable option. The moment I touch the core framework, I will be taking it down another development path that will prevent me from then “upgrading” to any future versions released by Paul. And if I cannot upgrade to future versions, then that immediately kills the benefit of having someone else maintain the base framework.
To solve this problem, I considered introducing a façade layer. Any “tweaks” could be applied to this façade layer, so that the underlying WebPortal framework could be kept in sync with any releases from Paul. However, while this sounds like a workable approach, a façade layer can only introduce relatively superficial enhancements to the underlying framework. Globalization, for example, is too deep an enhancement to be implemented in a façade layer. Globalization affects everything from threading to the business objects to the database schema to the persistence code. Even more problematic is that such an enhancement to the framework would be a breaking change. Even if I submitted my code revisions to Paul, he could not include them in future versions of the WebPortal without breaking everyone’s existing website. These concerns mean that I cannot see that tweaking the WebPortal framework is a sustainable approach. In turn this means that by moving to the Wilson WebPortal, I would be giving up Charlie’s working globalisation, which would be a major cost to incur.
So what would be the benefits of taking the approach of a pirate? I could take my cutlass to the Wilson WebPortal, steal its treasures, and bury them in the sand of Charlie under the light of the full moon. (This would be within the terms of use of the WebPortal, by the way.) I can see two benefits. First, I can apply some of Paul’s great ideas to Charlie, most notably his KeepAlive code and custom Cache code. This would mean adopting about 100 lines of Paul’s code. It’s not much, but it’s code that I could not have written myself. Second, Charlie would stay a bespoke application, whereas the WebPortal is a general application, and having a bespoke application has many attendant benefits.
What then is the cost involved in sticking with Charlie over moving to the Wilson WebPortal? Well, the cost is the same cost that has long been bothering me: that I’m creating and maintaining everything myself.
So which approach provides the greatest ratio of benefits to costs? Should I sink the Charlie ship and move to the WebPortal ship? Or should I keep the Charlie ship afloat and plunder the treasures of the WebPortal ship?
After thinking about this at some great length, I have decided to keep the Charlie ship afloat, and let it take the pirate approach of plundering goodies from any other ship it finds on the high seas of ASP.NET. Unlike pirates, however, I’ll only take what I’m entitled to take.
by Alister Jones | Next up: The Cache is a Shadow, Not a Box →
----
Post a Comment