(or, Think Twice Before Your Company Builds Its Own Software)
Shortly before Mike Loukides introduced me to the term "repair-ware", longtime friend and colleague Thomas Fuller presented his latest problem-solving idea: NoSoftware. You know how NoSQL is about doing away with relational data stores? NoSoftware, he says, is all about doing away with software projects. That means no deadlines, no bugs, no budget overruns...
We both had a laugh but, as with all good jokes, there was that uncomfortable kernel of truth. Tom's NoSoftware quip had given a name to something we'd known for some time: among the truly useful and occasionally amazing custom software projects that launch inside company walls, there are still a lot of software projects that needn't exist.
I don't mean little one-off tools, either. I mean medium-sized to large projects of department- or even company-wide scale. The home-grown accounting app. The custom content management system for the website. The hand-crafted systems-management tool. You name it, it's been done. Each one started off as a Great Idea That Would Save Money And Time, and ended up a Painful, Expensive Albatross That Someone Had To Hide In The Budget Numbers (And Possibly Became A Feature On The Daily WTF). These applications simply failed to deliver sufficient value. The companies that built them should have used off-the-shelf software and gotten on with their business.
Company owners, CTOs, and even developers: it's time to clear the weeds from your software garden, and prevent new ones from taking root.
How did we get here?
If you've inherited or even birthed one of these ball-and-chain applications, you already understand that they stem from two unfortunate circumstances:
It's too easy to skip the hard questions. Over the years, I've developed a list of questions to help people think through issues and explore solutions. For example: "Do we need to do this?" "What problems is it meant to solve? and what problems could it create?" "What are our viable alternatives?" These are short questions, but they can really open up a discussion and lead to meaningful fact-finding. It's critical that you ask these questions, and thoroughly explore the solutions, before you dive into a custom software project.
You also need the discipline to answer the hard questions before writing any code. A reasonably skilled developer can build a working prototype long before you've determined whether your company needs to move forward. By that point, it's too tempting to skip the hard questions and move straight to a full implementation ... which can lead to that fragile, hard-to-support, and possibly useless beast of an app down the line.
It looks easy to write software. and it kind of is. but it's really not. People often complain about software they use, but for the most part it "just works." The software industry has really honed its craft, to the point that a lot of development shops -- both commercial and free -- shield their end-users from the time, effort, discipline, and experience required to bring those products into being. Combine this with free, easy access to high-level software development tools, and many people who lack that experience reach the mistaken conclusion that it's cheap and easy to build solid, robust, business-grade software.
Having trivialized the required effort, it's too easy to grossly underestimate costs and hurdles beyond the initial development. This makes many prepackaged alternatives seem very much overpriced when they are actually cheaper than going your own way.
How do we get out?
These needless software projects create a host of problems. The most visible of which are holes in your budget, though you may also suffer low morale and even turnover in your application development team.
Leaders, managers, and yes, software developers, you need to push back. Sometimes, quite simply, you need to buy your software and not make it. This says nothing about the talent of your app dev staff, but about your decision-making process. It does you no good to have skilled developers in-house if you have them building useless apps.
Take a default stance of Buy, Don't Build, then research whether it's feasible to build in-house. Ask all of the hard questions, thoroughly explore the answers, and understand what you're getting into before you even build a prototype. If you do this, you'll find yourself well on the road to avoiding costly, morale-draining software projects, and your developers can focus on building the apps that will actually bring business value.
(NOTE: This post was inspired by a conversation with Thomas Fuller, a consultant software engineer who lives in Virginia.)