How a single refined recipe can better meet your kneads... errr, needs.
Early last Saturday morning, Isabelle awoke with a breakfast craving for a couple of slices of raisin bread on which to slather some jam. She walked to her corner bakery and bought a loaf, still warm from the oven. The bread was delicious. As she finished the last bite, she thought "this bread is truly wonderful but it could be even better." She returned to the bakery and mentioned that she enjoyed the raisin bread and would return next weekend for a second loaf. In this one, however, she would like to have hazelnuts, pecans, and dates added, and half the raisins removed. The baker, Henri, mentioned that every morning, they bake 25 loaves of raisin bread from a recipe that has been passed down for generations and has been continually improved over the years. This raisin bread recipe is clearly appreciated by the clientele since it is common for all 25 loaves to be sold by mid-afternoon.
Henri mentioned to Isabelle that, regrettably, the bakery cannot bake custom loaves of bread for individual clients. Doing so would reduce the bakery's ability to bake 25 loaves of raisin bread per day since many loaves would need to be individually mixed, kneaded, and baked. Custom baking would also make the process of improving the recipe more difficult. A change that would benefit one custom-loaf recipe may be detrimental to another. Imagine if Henri had 25 custom loaves to bake and decided to take a holiday and had to teach an apprentice all 25 recipes. Or what if he bought new pans? Or a new oven? Henri concluded his argument for the single-raisin-bread-recipe approach by pointing out that if a specific client failed to purchase his or her custom-baked loaf, selling that loaf to another client may be difficult. "After all", Henri said, "not everyone likes the idea of dates in their raisin bread."
Could you add some pecans to my LMS?
Few of us would think of asking our baker to produce a custom loaf of bread based on our specific requirements. Oddly, though, it's very typical for clients to ask for custom features to be added to cloud-based, SaaS business software. Some software vendors agree to these custom-feature requests and create separate versions of the software for specific clients. This is a bad idea. Here's why: If the vendor departs from the single codebase approach and decides to create customized versions of the software for specific clients, the pace of upgrades and bug fixes will suffer. New features will need to be tested across all versions to ensure interoperability. Clients will soon complain that the software isn't evolving as quickly as they want. More than two years ago we wrote that:
- If you come to us and say you like our system a lot but could we please create new features just for you, we might say no. It's not that we don't want to help you out. But, we've been doing this long enough to know that having a lot of highly customized implementations can be a nightmare for both our clients and for us when the time comes to upgrade to new versions. We prefer a single, super-stable codebase everyone uses that's highly configurable, with features turned on or off as needed. (If, however, you have an idea for a great new feature we should include in our roadmap, we'd love to hear about it.)
Single codebase software is easier to maintain. Bugs are easier to squash and new features that benefit the majority of clients can be added quickly. Software customized just for you may make you feel special but you'll soon be disappointed with the inability of the software to keep up with changes in your industry. Remember, a single codebase still plays well with other systems like an HRIS or your SSO. Try Absorb LMS for yourself and see what it can do. Sign up for a free instant demo portal of the learner interface and our team will help set you up with full software sandbox access.
