We don’t talk about uncategorized software all that often. We almost always include an adjective to indicate something about the code we’re discussing, usually as a means of describing the problem domain. As a few quick examples, there’s e-commerce software, marketing software, educational software, or inventory management software. That clarification is handy, since it provides context about the code being discussed. The problem (and I would not be at all surprised if Java people – and I largely write Java at my job – did this), is when we over-generalize how we categorize software in a way that adds no value. For example, “administrative software” or “enterprise software.”
Some categorizations are narrow enough that you can safely guess the user base and what types of problems they solve. In the examples I listed above, inventory management is probably used by retailers to keep track of how much product they have, and where it is. Likewise, marketing software is going to be used by marketing departments for advertising and promotion. In each case, I’d expect to be able to count on 0 hands the number of people from the HR department using each product.
Other categories are a little less specific, but not much more so. Educational software could be used by students or teachers, depending on which end of the education process you’re on. E-commerce software could be used by businesses to manage their online stores, or be the online store, used by shoppers. Either way, you still have a good idea about the problem domain, and just need a bit of clarification on the specific problem so you know which direction you’re approaching from.
“Enterprise software,” on the other hand, tells you next to nothing about the software in question. A huge part of that is because the term “enterprise” offers little to no context. Sure, you can just say it means “big business,” but big how? 37Signals makes millions of dollars a year (per DHH), so in that sense, it’s probably big. But it doesn’t employ a lot of people, so maybe it’s just a small business with an outlier-level of success? Does it refer to software that is written by large companies that has lots of users? Because then Netflix and Google are “enterprise software,” although I doubt anyone would call them that. Maybe it’s just “software written for businesses,” which doesn’t really narrow things down all that much. Even the aforementioned medical offices and educational providers technically falls in that category (medical offices are still businesses, and even public schools have employees and the associated “business” class of problems that come with being an employer).
The reality is there’s no special type of software known as “enterprise software.” To be fair, there’s no type of special software known as “e-commerce software,” “marketing software,”, “medical software,” or “inventory management software.” Those are just adjectives we use to describe the context of the problems the software addresses. There’s just software, and which solves a problem and has requirements. That’s it, it’s that simple (sure, the combination of problems and solution requirements may be hard, but that’s a separate thing). Now, the problems some other companies have solved may be similar to yours. In fact, they may be similar enough that you can use their solution as-is, or at the very least use it as a starting point for your solution. But there’s no rule or law that says “because your company is {X} size, you have to write your software this way.” Other companies do things a certain way for a large variety of reasons, some of which are related to the problem, some of which are related to how they’ve done things in other places, some of which are related to their corporate rules and process. Knowing how other businesses do things isn’t useful until you also know why they did them.
You can think of any rule as having 2 parts – the text of the rule (“Do this,” “Don’t do that,”), which we often think of as being the rule itself, and the reason for the rule, which we don’t usually state but is still important. That why is short for why the rule works. Just taking the text of a rule and adopting it without confirming you have the same other problems, requirements, and corporate environment as the businesses you’re copying them from is cargo culting, and ultimately ends in failure. We’re in a profession that likes to over-abstract, and that leaves you in architecture astronaut territory, and that’s what leads to Enterprise FizzBuzz. But at the end of the day, you have concrete problems that need concrete solutions. You have to take the time to compare the specifics for what you’re trying to copy with what you’re trying to accomplish and make sure they match.
That’s not to say there aren’t useful insights in how other companies solve their problems, because there are, and there are underlying principles that most certainly apply to whatever you’re trying to do. But it takes a lot of time and analysis to get from a “here’s what we do to achieve {X}” blog post to get the principles being applied. It also takes trying to find something more in-depth than a “how we coded {X}” article being released as a recruitment and/or marketing tool to understand the motivations behind the technical decisions involved. Some places are better at highlighting that kind of decision-making than others, but without all the factors that actually went into the decision-making, you don’t actually understand what these other companies did.
Making decisions to do something because that’s what everyone else is doing is such a bad idea, that odds are nearly everyone reading this grew up hearing some variation of “If all your friends jumped off a cliff would you do it too?” Just because another company did something 1 way, or implemented a particular feature (I’m looking at you, exit intent pop-up people), doesn’t mean you have to do things that way or add that exact behavior. If you think something’s a good idea that’s worth trying, at least do yourself the courtesy of thinking it through first. Every developer can parrot the canard that everything has tradeoffs, but the ones that are actually good at what they do can list the tradeoffs, and justify their decision in that context.
Software written by and for big companies comes with a lot of requirements around performance, security, and reliability, although the weights associated with each set of requirements varies from company to company (and from service to service). Before cargo culting whatever any company whose name starts with “F,” “A,”, “A,” “N,” or “G” does, make sure you have similar problems. The stuff people do in order to get this kind of performance, security, and reliability makes software more complex. Start with “Plan G,”1 and then go back and add the complexity to the places where it matters.
Just like the basic justifiable cost for something is a function of {% chance it happens} * {cost of that thing happening}2, you should have a similar mental arithmetic for the technical decisions you make that don’t directly solve the business problem presented. When you start doing that, you tend to develop an instinctive avoidance of a lot of patterns people typically push in things like “enterprise software” until you have no other option. Queues and events? Only when I absolutely, positively, can not lose a single event. Hardcore multithreading logic? Only if I can have a lot of dedicated cores dedicated to a highly parallelizable problem. But I’m not going to try to get clever with anything until I absolutely have to. That kind of code and architecture is harder to understand, which makes it harder to work with, and harder to do anything with because it’s now easier to introduce bugs. I’d rather spend brain cycles on the problem at hand, not understanding the code that’s already there.
Look, big tech companies are doing some cool stuff, and there’s some good inspiration out there for the stuff we’re doing (who wouldn’t want to be able to say we wrote something so reliable we run Chaos Monkey in production). Sometimes, these other companies are doing things that are worth bringing into your organization (I’ve finally come around on feature flags – thanks Charity Majors – and am slowly trying to pester my way to trying to get them introduced at my job). The key is taking the time to think through what we’re doing and make sure that thing other companies are doing is something that solves 1 of our problems. If we can’t justify our reason for doing something without saying “because that’s what {big companies} do,” or “because {tech personality} says so,” we don’t actually have a reason, just envy. Instead of trying to find an excuse to remake your entire codebase in the image of that cool demo/example, try to think about what you’re doing in terms of specific classes of problems. If you start with the problem, and it sounds like a similar you’ve heard about someone else running into, that’s the time to go back and see how they solved it, and think about if all the conditions that made the solution work for them apply to you. Always pay attention to where you’re going with some proposed idea, lest you find yourself falling off that aforementioned proverbial cliff.
- Jump to 39 minutes, 22 seconds for an explanation of what “Plan G” is. ↩︎
- Wise words I was given starting out – don’t be the person who assigns “the cost of that thing happening” to human health and safety – it’s inevitable that something eventually happens, and you really don’t want to be in the deposition or called to the witness stand as the a**hole who said this person’s beloved and irreplaceable family member’s life was worth $X. ↩︎
Sorry, the comment form is closed at this time.