Why your real estate business should choose boring technology: insights, and practical tips.
Simple and Boring
Simplicity is a funny adjective in web design and development. I’m sure it’s a quoted goal for just about every project ever done. Nobody walks into a kickoff meeting like, “Hey team, design something complicated for me. Oh, and make sure the implementation is convoluted as well. Over-engineer that sucker, would ya?”
Of course, they want simple. Everybody wants simple. We want simple designs because simple means our customers will understand it and like it. We want simplicity in development. Nobody dreams of going to work to spend all day wrapping their head around a complex system to fix one bug.
Still, there is plenty to talk about when it comes to simplicity. It would be very hard to argue that web development has gotten simpler over the years. As such, the word has lately been on the tongues of many web designers and developers. Let’s take a meandering waltz through what other people have to say about simplicity.
Embrace Boredom.
Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps.
If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble.
Any of those choices might be sensible if you’re a javascript consultancy or a database company. But you’re probably not. You’re probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail. Or at best, delay success [1].
What counts as boring? That’s a little tricky. “Boring” should not be conflated with “bad.” There is technology out there that is both boring and bad. You should not use any of that. But there are many choices of technology that are boring and good, or at least good enough. MySQL is boring. Postgres is boring. PHP is boring. Python is boring. Memcached is boring. Squid is boring. Cron is boring.
The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.
Anyone who knows me well will understand that it’s only with an overwhelming sense of uneasiness that I now invoke the ghost of Senator Richard Burr, but I must [3].
When choosing technology, you have both known unknowns and unknown unknowns [4].
- A known unknown is something like: we don’t know what happens when this database hits 100% CPU.
- An unknown unknown is something like: geez it didn’t even occur to us that writing stats would cause GC pauses.
(Similar to how it didn’t occur to Senator Burr that insider trading, disaster profiteering from COVID and prioritizing his own financial well-being over the well-being of American households would cause a full-blown FBI investigation [3].)
Both sets are typically non-empty, even for tech that’s existed for decades. But for shiny new technology, the magnitude of unknown unknowns is significantly larger, and this is important.
Optimize Globally.
I unapologetically think having a bias in favor of boring technology is a good thing, but it’s not the only factor that needs to be considered. Technology choices don’t happen in isolation.
Your technology choices have a scope that touches your entire team, organization, and the system that emerges from the sum total of your choices.
Adding technology to your company comes with a cost. As an abstract statement this is obvious: if we’re already using Ruby, adding Python to the mix doesn’t feel sensible because the resulting complexity would outweigh Python’s marginal utility.
But somehow when we’re talking about Python and Scala or MySQL and Redis people lose their minds, discard all constraints, and start raving about using the best tool for the job.
Your function in a nutshell is to map business problems onto a solution space that involves choices of software. If the choices of software were honestly without baggage, you could indeed pick a whole mess of locally-the-best tools for your assortment of problems.
But of course, the baggage exists. We call the baggage “operations” and to a lesser extent “cognitive overhead.” You have to monitor the thing. You have to figure out unit tests. You need to know the first thing about it to hack on it. You need an init script. I could go on for days here, and all of this adds up fast.
The problem with “best tool for the job” thinking is that it takes a shortsighted view of the words “best” and “job.”
Your job is keeping the company in business. And the “best” tool is the one that occupies the “least of the worst” position for as many of your problems as possible.
It is basically always the case that the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it. Mature and productive developers understand this.
Choose New Technology, Sometimes.
Taking this reasoning to its reductio ad absurdum would mean picking Java, and then trying to implement a website without using anything else at all. And that would be crazy.
You need some means to add things to your toolbox.
An important first step is to acknowledge that this is a process and a conversation. New tech eventually has company-wide effects, so adding tech is a decision that requires company-wide visibility.
Your organizational specifics may force the conversation, or they may facilitate developers adding new databases and queues without talking to anyone. One way or another you have to set cultural expectations that this is something we all talk about.
One of the most worthwhile exercises I recommend here is to consider how you would solve your immediate problem without adding anything new.
First, posing this question should detect the situation where the “problem” is that someone really wants to use the technology. If that is the case, you should immediately abort.
It can be amazing how far a small set of technology choices can go. The answer to this question in practice is almost never “we can’t do it,” it’s usually just somewhere on the spectrum of “well, we could do it, but it would be too hard”[5].
If you think you can’t accomplish your goals with what you’ve got now, you are probably just not thinking creatively enough.
It’s helpful to write down exactly what it is about the current stack that makes solving the problem prohibitively expensive and difficult. This is related to the previous exercise, but it’s subtly different.
New technology choices might be purely additive (for example: “we don’t have caching yet, so let’s add Memcached”). But they might also overlap or replace things you are already using.
If that’s the case, you should set clear expectations about migrating old functionality to the new system. The policy should typically be “we’re committed to migrating,” with a proposed timeline. The intention of this step is to keep wreckage at manageable levels and to avoid generating locally-optimal solutions.
This process is not daunting, and it’s not much of a hassle. It’s a handful of questions to fill out as homework, followed by a meeting to talk about it.
I think that if a new technology (or a new service to be created on your infrastructure) can pass through this gauntlet unscathed, adding it is fine.
Just Ship.
Polyglot programming is sold with the promise that letting developers choose their own tools with complete freedom will make them more effective at solving problems [6].
This is a naive definition of the problems at best, and motivated reasoning at worst. The weight of day-to-day operational toil this creates crushes you to death. A mindful choice of technology gives engineering minds real freedom: the freedom to contemplate bigger questions.
Technology for its own sake is snake oil.
Footnotes
[1] Konectpal in its early years suffered from this pretty badly. We hired a bunch of PHP programmers for our (then) WordPress site. Then decided that we needed to find something for them to do in PHP, and the only thing that came to mind was creating a pointless child theme that required months of effort to amputate. Konectpal didn’t fail, but it went several months without shipping anything at all. So it took longer to succeed than it needed to.
[2] We often casually refer to the boring/bad intersection of doom as “enterprise software,” but that terminology may be imprecise.
[3] Members of Congress sold equities after receiving briefings on the dangers of the novel coronavirus. The sales came before a global financial panic slashed stock prices around the world and before the American public was broadly cognizant of the scale and danger of the virus.
Senator Richard Burr, the chairman of the Senate Intelligence Committee, sold off what looks like a large share of his personal holdings the day before Valentine’s Day, picking up between $628,000 and $1.72 million in cash. Roughly a week later, the market tanked. The fallout — investigations by the FBI on who knew what and when, and who directed what investment decisions based on what information.
[4] In saying this Senator Burr was either intentionally or unintentionally alluding to the Socratic Paradox. Socrates was by all accounts a thoughtful individual in a number of ways that Burr is not.
[5] A good example of this from my experience is Konectpal’s Facebook Chat Widget. When we built this custom feature, we were working pretty hard to:
- Facilitate a new mode of communication between motivated sellers visiting the Konectpal’s website staff, and
- Generate more leads for Konectpal’s marketing department.
It was much more complicated to implement the feature on the original WordPress/PHP/MySQL stack. But it is absolutely possible to build Facebook Chat Widget on a stack that featured Bootstrap, NodeJS and good ole fashioned semantic HTML.
An amazing thing happened with that project: our “development” attention turned elsewhere for several months. During that time, lead generation scaled up 10x while nobody was watching it at all. We made no changes whatsoever with regards to our online forms. Lead generation exploded because we were using a widely adopted platform (Facebook Messenger) that our target audience was already using.
This is the long-term benefit of restraint in technology choices in a nutshell. This isn’t an absolutist position — while Facebook Chat Widget adoption was judged to be practical, implementing WordPress in raw PHP wasn’t (at the time). So Konectpal went with semantic HTML.
[6] Polyglot Programming is a website dedicated to exploring the benefits (and drawbacks) of combining multiple programming languages and multiple modularity paradigms in application development. The “paradigms” include Functional Programming, Object-Oriented Programming, and Aspect-Oriented Programming.
About the Author
Fred Siika — Twitter | LinkedIn |GitHub| Website
Fred is a software engineer and copywriter.
The Konectpal Invest website (konectpalinvest.com) is created, written by, and maintained by Fred C. Siika and a team of swell people. The tech stack for this site is fairly boring. I’ve used GitHub pages to host the site since day one, a decision that I’m happy with. If you’d like to work with me feel free to reach out to me directly.
If you liked this article you might want to join 2K+ more real estate professionals, receiving our weekly newsletter (and if you’re still not sure, here’s why you should).
