INTRO- This post is the second of three about custom software. You can read the opening post here.
Custom software is built to meet your exact needs! How can you go wrong?!?
But before I go too far, I do want to say there is a right time for custom software, but with new choices available today I think those times are minimal. To help you think through if custom software is right, I would read this post on when to build your own solution. I would also like to add that when I talk about custom software in this post, I am talking about true software development from scratch, not configuring or personalizing an existing platform. Anyway....
Question #1 - who will support it when it breaks?
If you build something no one else has, who will you ask for help? It is like buying a custom built car that runs on garbage and flies, then expecting any mechanic to fix it. How will they know what parts to use? You will either need to hunt down the person that built it, good luck finding them McFly. Or you will need to find someone who understands garbage powered flying cars and then let them take the time to learn how your car is setup... every time it needs repairs, not to mention improvements.
A custom software will have custom problems no one has seen before. There won't be a user group to turn to, documentation on how other's solved it or FAQs. You will be the first to ask.
Question #2 - how will you keep it fresh?
How many movies start with someone finding an ancient, super powerful technology, but no one knows how it works? Often custom software is awesome when it is launched. But then process changes, technology changes, users change, leadership changes and time passes. No one remembers why it was built the way it was, no one remembers what the key development decisions were or what the purpose was. So a new team comes in, finds the custom software and looks at it like the apes in 2000 a Space Odyssey.
Question #3 - who will support the users?
If you build custom software, there should be a plan to have experts on hand to support it, plus a back up plan if that expert resource disappears. Because people who like to build new, cool software are typically not the same people who like to stick around to help users. They will often move on to the next cool project. So you will need a couple types of experts, people to fix it, expand it, support it, document it, train users, support users, etc.... You might get lucky to find the one person that can do it all, but we all know where that ends in burnout (not to mention what happens when you replace the custom software).
Question #4 - how will you course correct?
Custom software relies on someone understanding the processes to be built, data to be collected, problems to be solved, reporting needs, user needs and so much more. There is bound to be something built, implemented and later found to not meet the intended purpose. Often this is where work-arounds built with spreadsheets start to grow. But as this happens people rely on the data in the work-arounds more than the system because they control it and know how it works.
So once the custom software is built but isn't working, you will have a new custom problem to address. Who is watching for these issues, does the analysis, creates the process map, designs the solution, implements it and then trains the staff (plus supports it). These course corrections will not stop, things change and developers don't always get it right (especially if the original request wasn't clear).
Custom software is built to meet your exact needs! How can you go wrong?!?
Things will go wrong or change with software. With custom software is your custom problem. But hey, if you really are solving a new problem
Addendum: Custom Software vs Configured Software
I know this post seems very negative on Custom Software, which frankly it is (sorry if it was snarky). I will restate that I do think there are situations which demand innovation and outweigh the risks of custom software. But I would stress exploring new cloud platforms which allow configuration (click not code) to meet your needs, plus allow for code. This allows personalizing to meet your orgs needs, but keeps you in a sustainable environment. You will have flexibility within limits but still get updates, support, enhancements and be in a community. Today's solutions provide you the tools to customize many parts of the system as an administrator through wizards and user interfaces to make changes without code.
Side thought...
This post really could apply to custom websites or any custom code really.
The next post will focus on Custom Process vs Best Practice.
This post is a part of a series of posts, to get more context read the first post.
5 comments:
I'm not going to debate you (for a change!). I just want to say how happy I am that the need for custom development has lessened dramatically with the advent of Software as a Platform solutions like Salesforce, Box, and some company named Net-something or other. NetHotelRoom? NetLobby? ;-)
I developed a custom retail management system for a Goodwill in 2003. I believe that it was justified, as a thorough search for thrift retail management solutions came up cold - every inventory management package out their assumed that we purchased goods and resold them, and therefore had little support for our retail processes. But that Goodwill was still stuck with software that I wrote, no one else, and they were still using it years after I left - which is scary. Had we had a platform like Netsuite or Salesforce to build on, we could have done something that, while still customized, was understandable by platform-specific consultants. Far more sustainable. It's great when a shrink-wrap option meets your needs. And it's sometimes worthwhile to modify your processes to meet software assumptions, so that you can use less customized products. But we can't always make those compromises, and I've seen too many cases of customizing a commercial product to the point where it's corrupted. So platforms fill a gap between shrink-wrap and custom that can be a real win for resource-strained nonprofits.
Just like anything else in the software world, the right answer is "it depends." Packaged software is built for the masses. As long as your company and\or business processes fit within that circle then I totally agree. However, if buy one of these packages and you require serious customization or modification then you will be paying some consultants or developers somewhere to do the exact same thing on a platform that may never meet your specific needs. At that point every argument above will also apply even though you are running a packaged solution.
Thanks for the comment Peter! And yeah, times sure have changed. When I started in the YMCA we used a custom software as well, built for YMCAs by YMCAs. The Houston YMCA even created custom software to do Bank Drafting (EFT) before it was available.
John, the difference to me is that if you start on a platform and then add some customization, you are still ahead of the game. If the solution was fully custom, you have no peers, you rely on the developers. If you customize on top of a platform, you have peers using the platform and consultants with platform knowledge, platform support services, platform training, etc. A platform narrows the customization needs by allowing configuration first. It is the difference between searching for the right developer versus someone with platform experience in your industry. Platform experience will be more common. Another way to explain the difference is during RFP. A custom software development is almost impossible to create and include support in the RFP. A platform with customization will always include support.
Steve,
I love a good opinionated post. Also, honored to see our blog post about build vs. buy included, thank you and happy you found it valuable. I've got multiple drafts started on the follow-up about building your own if you find yourself on that side of the decision tree ... it's likely more ebook than article ... but we'll see. Tough and big topic to share value to those whom don't do it for a living.
You know, I am firm believer in a theres a time for custom and you raise many good considerations such as ongoing support and continued investment. I think there is place for nonprofits to have technology driven product and a time when powering by "your own" software is needed.
Biggest challenge is "why" ... why build something custom ... why do we need something custom ... is this truly worth being "unique" for? That said ... my mind and comment went elsewhere when I read this post. I had two thoughts come to mind both in reaction to "custom" as you mentioned as "true software development from scratch":
Reality is that we inherit and have been around so many solutions that have "custom" needs that are built on platforms such as Drupal and other similar platforms ... that hit points, quite easily sometimes, where notable modules, add-ons, sidecar apps, and custom code take these to places the platform has an identity crisis creating confusion for all about what is out of the box and not. You end up with these hybrids and often are Frankenstein's monsters ... no more or less challenging to support, invest in, and find help with.
Another thought is when you say custom software ... or build from scratch ... it's just not that "from scratch" now is it? We use frameworks and libraries whole messes of technology to deliver "custom" solutions. I can't remember the last time we coded in raw PHP without some sore of MVC framework to help deliver a more easy to use, robust, and better support codebase. If you are building on a framework with a great community, "custom", is a very much less "custom" in some ways.
Seth, Thanks for taking the time to read my post and leave such a well thought out comment!
I totally agree with the "why" build something custom, which doesn't seem like the way most people think.
Frankensystems are indeed tough to deal with and "from scratch" sure has changed.
Looking forward to your ebook, feel free to let me know @steveheye on Twitter when you do and I will be sure to check it out\share.
Thanks! Steve
Post a Comment