My dad’s family had a chain of men’s clothing stores. It wasn’t the highest margin business, but it provided a very comfortable living for several families – and ensured my brother and I were probably the best dressed boys in our high school class.
(Having worked in the stores during Christmas, I learned I I never wanted to work directly with consumers. But I digress).
My family sold a lot of men’s suits. Because off-the-rack men’s suits need to be adjusted, at the company’s height, my dad employed over a dozen tailors, tucking in, letting out, shortening, and lengthening.
What does this possibly have to do with software development?
I’ve spent most of my career around software applications and software projects. I myself have written thousands of lines of code (and still work on the occasional piece of SQL).
I’ve managed/employed/contracted dozens of folks who’ve written thousands of lines of code as well.
But I think it’s really important to distinguish between the kind of software development I do and what I’ve stayed away from (and plan to stay away from).
Essentially, I have (almost) always worked with a “let’s tailor something off the rack” approach.” This means that my clients have already purchased software to handle 90% of their needs. (The analogy with suits doesn’t exactly work. If your suit isn’t 98% perfect before tailoring starts, it’s going to be a disaster.)
These systems range from ERPs like Dynamics, Infor or Sage (or God forbid Oracle) to a CRM or payroll system or an electronic health records system.
When you buy these systems, you don’t get everything out of the box. Thus, it’s the kind of software development that’s kept me busy. It’s also the type of development that many consultancies classify as “RICE elements.”
RICE stands for Reports, Interfaces, Customization, and Extensions. As in:
- If you want to see the data a different way or need to combine data from multiple systems, you build a R
- If you need to bring employee data into your EHR, you create an I
- If you need to calculate sales commission your own special way (and everyone does), you may Customize your order entry screens.
- And if that 90% solution is really missing some functionality, as in it doesn’t really calculate your manufacturing plans the way you’d like, you build an E
In each case though, the data structures and fundamental processes have been built by someone else.
While there can be extensive work to be done, it’s all done with those definitions in place. You’re not starting with a blank sheet of paper. The constraints may be annoying, but they give you a major place to start.
The Saville Row approach – or software built from the ground up
While in the past I’ve purchased custom dress shirts, I’ve never had to purchase a fully custom suit. Some folks, with lots of money or a desire to have things just so, still do buy fully custom suits. These suits come with lots and lots of measurements, fittings and adjustments.
So too, with software, some people refuse to choose off-the-rack products.
While (almost) no one builds their own payroll or general ledger, almost everything else can be fair game for a certain corporate personality. Their needs are special, or so they think. Rather than buying, they build from the ground up. They start from scratch – or from the ground up. (I use the term “ground up” because all software we build is in a sense custom.)
When you start from the ground up, you can have anything you want. Which is the big advantage.
Unfortunately, when you start from the ground up, you can have anything you want. Which is the big disadvantage.
Why? You have to decide EVERYTHING.
From how big the order number would be to how many steps any process would require, to the colors on each screen.
And this is where the custom suit analogy breaks down.
When you buy a suit, both you and the tailor know what a suit looks like. You’re buying a suit. Not a shirt, a skirt, a dress or a toga.
In software, when folks start out, they really may not know if they want a dress or a toga or army camouflage. Or a mattress. Or a tea pot.
And what’s worse, you can change your mind whenever you want. Which can risk becoming the song that never ends.
Ground up software = big, big costs
If you’re not a software company and haven’t made a major investment in development talent, going “ground up” is almost never a good way to go.
Indeed, I had one customer that loved building their own software. They spent several years and probably seven figures building an order system that, in the spirit of Microsoft’s dot net, was referred to by the water cooler as the “Not net” project.
I, thankfully, wasn’t involved it their custom development. But I did make a lot of money from it because they generally gave in and purchased off-the-shelf solutions. I spent many years helping them get those key “RICE” elements completed so that the off-the-shelf solutions would meet their needs.
Is there ever a place for ground up software?
Of course. But I think many folks don’t distinguish between these different kinds of development needs and get themselves in trouble.
More to the point, if you really want to do ground up software development, I’m probably not your guy.
At the same time, I’m planning to return to the subject. It’s because the drive for the “ground up” approach is often, to use a term taken from Ronald Heifetz, a work avoidance strategy. It fits right back into the distinction between technical and adaptive challenges which is a key part of my work.
If you think your folks want to try ground up development, and you think that maybe it’s not the best idea, we should talk.