This post was written back when Adelie was openly accepting new inquiries and projects.
I once heard two friends arguing. One of them had recently come upon a windfall of cash, and wanted to make a big purchase: an upscale sports car. Upon hearing this, his miserly friend fired back, “you don’t even go places! Don’t buy a Porsche to drive to 711.”
When I heard this biting exchange, I chuckled. But as I shampooed my hair into a glorious, frothy bubble afro later that night, I realized it was a much-needed lesson for web developers.
The quote itself plays on the relationship between utilization and cost. In other words: don’t pay for a Porsche if you’re not going to use it to its fullest. But the inverse of this idea is that if you are, in fact, going to use the Porsche to blaze across open tundras, then yes — it’s worth it! The quote also acknowledges that there are various kinds of drivers.
So far, I’ve simplified the types of drivers down to two (hilarious) extremes:
But obviously, it’s not so binary — drivers exist on a diverse horizontal spectrum. And unsurprisingly, a variety of car models and brands exist to accommodate that spectrum.
I believe this is a functional and healthy model. But I’ve noticed a troubling trend recently.
All the same analogies exist in the realm of websites and web development: there are different kinds of clients with different kinds of needs. Some clients have modest budgets, others have limitless budgets. Some clients are tech-savvy, others will buy two routers to double their internet speed. (Of course, we love them both just the same!) And just as with cars, a variety of web development tools exist to accommodate the needs of every client.
This indirectly hurts the developer, the client, and the industry as a whole.
My parents are entrepreneurs with a successful interior design & reupholstery business. (Hi Mama Oh, Hi Papa Oh!) Several years ago, my mother was approached by some local web developers, who handed her a pamphlet. Intrigued, I read it over.
They offered to build a website on Shopify with 3–4 static informational pages for $750. They hailed Shopify as “the best web platform, hands down,” or something like that. If I’m being extremely generous, replicating their services would have taken me (or any competent web developer) around half of a work day — about 4.5 hours if I’m working efficiently. That amounts to about $170/hr!
For the services provided, this rate was (and still is) grotesquely over-inflated. The $750 package didn’t even include the configuration of a functional shopping cart. It was just a static website.
Let’s take a quick look at the numbers. Shopify’s lowest plan (that offers an online website) is $29/mo. A year would cost $350. Add it all up, and you get 4 static pages for a whopping $1100 for the first year alone. That’s too much. Overkill, much like purchasing a Porsche to drive to 711.
Relying too heavily on a single tool has a limiting, pigeon-holing effect. Take the case above. If a developer stubbornly only uses Shopify, what do they do for a client that requests changes to their WordPress+WooCommerce website? Do you turn them away? You might be tempted to suggest a full migration from WordPress to Shopify, but that’s a hefty undertaking for the client, both financially and logistically. My guess: they’ll go elsewhere, and that’s lost business.
It also puts “all your eggs in one basket,” so to speak. What if Shopify goes out of business? That’s extremely unlikely, but things aren’t exactly unchanging in this industry. What if a new tool is released that completely eclipses Shopify in popularity or functionality? This point is more of an afterthought, but it still stands.
Before I continue, a quick note: I’ve been using Shopify in my examples, since it’s relatively well-known and because Shopify’s back-end is directly seen and used by the client. It affects both parties more directly. But these problems extend to internal tooling as well. If you do all your work with Bootstrap, or if you strictly use NoSQL or Static-Site-Generators or whatever, you may encounter problems.
This point isn’t localized to web development, so skip ahead if you want. Everyone’s seen it: anytime a conversation starts to get overly one-sided, it becomes less productive. Consider the arguments between iOS and Android users. Between Mac and PC users. Between Vim and Emacs users. Those forums are a wasteland where each side simply gets further entrenched in their existing views.
Of course, some playful jest is welcome and fun. (Sublime Text w/ Vintage Mode all the way!) But taken too far — and it very frequently goes too far — it just stagnates productive conversation. I’ve seen many a Quora/Reddit/StackOverflow post where one-sided opinions have resulted in flame wars. Worse still, I’ve seen overly opinionated developers misleading newbies who are trying to get an objective overview of the web development scene.
These problems have a simple solution. Diversify your tools so that you can better accommodate your client, not just yourself.
As an overview, here are a few examples of how I’d build websites differently depending on the client’s needs. (I’m always open to suggestions, so if you have any, please feel free to share!)
A final caveat before we wrap up: I am not advising all developers to learn every single technology. That would completely defy the ideas I espoused in my last blog post. And I’m not even advising to blindly learning the “latest and greatest” stuff. I am issuing a gentle, friendly reminder to my fellow devs: don’t blindly fall in love with — or become overly dependent on — your tools. A hammer is a hammer, a package manager is a package manager. Learn and master the specific tools that will help your client first. If every single person in your demographic is using Middleman to blog, maybe it’d be best not to learn Jekyll quite right now. If everyone around you loves and utilizes Rails, it’s okay to postpone learning Laravel or Express. You get the point.
By Kevin Oh on .View All Posts