Mewlo Web Framework Blog Entry #2 - August 29, 2013 - A DigressionI was talking to another DonationCoder member recently about offering web services to people on the site, and it struck a cord with me that I'd like to share, that is relevant to Mewlo and coding in general.
If I have learned one lesson over and over again in my 7+ year experience with DonationCoder, it's to
fear maintenance costs.
Now as a programmer, this should not be news to me -- the famous "
Mythical Man Month" book talks about maintenance costs quite a bit, and how a substantial amount of time is spent maintaining code.
But different projects, attitudes, and lifestyles may put you in very different positions in terms of how much you have to worry about maintenance. Sometimes we are in positions, by choice or fate, where we do not feel the pain and fear of maintenance issues directly or often. Other times we find ourselves almost accidentally committed to supporting a system the requires near constant maintenance and care.
When we decided to upgrade the server that runs this website, we had the swell idea of pooling together money from people on the site, and then providing hosting services to our members. We hosted websites, email, etc. It's really not too much trouble to set up -- and we had a brilliant site administrator who was gung ho to set up any kind of custom setup people would want. What I didn't anticipate was how much work would be involved in the maintenance of such things, and how difficult it would be to walk back from such an idea. Whether it's worrying about operating system upgrades, dealing with outages, worrying about backups and failures, worrying about malicious users, etc. It gives me cold sweats just thinking about it.
Some people are intuitively suspicious of doing anything -- adding any feature, because they have a voice in their head that tells them that any added feature or service brings with it the potential for maintenance headaches.
Now by nature I'm the kind of person inclined to add features to software if I think it might be a useful addition. I tend not to worry too much about the increase in complexity of code to maintain, or the increased complexity of the configuration options. But I'm increasingly aware of the price to be paid for such decisions -- a price in terms of complexity of configuration dialogs, and a price to be paid for the growth of the code base.
I'm not suggesting a course of action here -- just advocating for a very healthy fear of maintenance costs -- and of keeping such things always in the forefront of your design decisions.
I can say that such fears are foremost in my thoughts when thinking about the DonationCoder site and in thinking about the Mewlo web framework. Over the last couple of years I've talked with people on DC about setting up a standalone "Self-Teaching Programming School" to replace the one that
we have now on the site. And talked and experimented with moving the site over to a proper content management solution.
In such discussions I find myself in the regular position of having to throw water on a proposed idea that, to the person suggesting it, seems like "not too much work to set up". The problem of course is not that some new solution would be too much work to set up, but that the maintenance costs and risks associated with it are unbearable in the long term.
I'm particularly skeptical of solutions that involve connecting up multiple independent components made by different parties. My experience is that the more moving parts, the more frequent the incompatibility problems come up. And I've learned that even minor manual tasks (like merging in some changes into some source code) soon become painful and error prone when they have to be done over and over again, or after long delays when one has forgotten the steps needed.
And I'm especially skeptical about anything that requires specialty knowledge to do, because it means that the people involved in maintaining the system become indispensable.
That's another lesson I've learned -- avoid any solution where the steps required to maintain it are not codified into a document that can be passed on to a replacement maintenance person.
So let me wrap up by relating all of this to the Mewlo web framework. I think these lessons effect the framework in two very different ways..
The first way is in the design of Mewlo itself. Clean, documented, maintainable code has to be the primary organizational principle for the entire system. That's mostly common sense.
Slightly more controversial is my skepticism about the risks associated with interacting components maintained by different groups. That has led me to a fairly broad classification of certain "modules" in Mewlo as being part of the core system. Mewlo includes core "official" modules that many web frameworks delegate to unofficial, interacting (and often existing as multiple implementations written by different teams, and often abandoned). These are things like user groups/messaging/profiles/etc.
But the second way in which Mewlo is driven by this concept of a healthy fear of maintenance is in the role Mewlo is trying to play on the web. It would be fair to say that the primary mission of Mewlo is to ease the job of maintenance for creators of community-driven web services.
Supporting maintenance is exactly the thing that Mewlo is trying to do better than existing frameworks. The goal is to implement all of the support structures that are key to maintaining a site and keeping it running smoothly. This means extensive support for logging, upgrading, detecting and alerting on problems, monitoring operating conditions and detecting bad behavior or performance problems, and it means providing tools for moderators and administrators so that they can do their jobs easily.
You might say that Mewlo is designed for the Maintainers, and those who have a healthy fear of the cost of maintenance.
Recent Posts