Skip links

Technologies Don’t Matter *

So there you are. The new proposal lands on your desk. And it’s a doozy.

Totally greenfield. Nothing holding you back. A consumer-oriented marketplace for in-demand goods. Buyers and sellers, coming together, exchanging goods in breathless rapture. Disembodied hands floating through the ether, swiping credit cards and picking up heavy shopping bags. Commerce!

And you are the one who gets to make it happen!

This is exciting, right? And you get to lead it.

All those mistakes of projects past can be wiped away. You’ll do it right this time! Not tied to some legacy platform, you can choose any direction you’d like. The correct direction.

So how do you wanna make it?

Then the dread sets in.

The Agony of Choice

It turns out that technology is a pretty dynamic field, and it changes constantly. Consequently, “common knowledge” within the industry is also constantly shifting. If you end up staying at one job long enough, building an application in a stack that was state of the art when you started, it’s only a matter of time before your application is considered legacy and you are, as the kids say, an old head.

When starting out on a new project, it is easy to be overwhelmed by the sheer number of new technologies and frameworks that have popped up since the last time you were building something from scratch. Additionally, technologies can emerge that fit in very specific places in the stack, or that add a new bit of functionality to some other framework, and these also have rather vocal fan clubs. And then there are all of the startups and SAAS vendors each claiming to help fix one or another very specific pain point in your technology stack, and they all scale to 100k simultaneous users and are best-of-breed.

Best-of-Breed!

There’s nothing better than best.

It would seem to the untrained eye that if you make the wrong choice, or choose the wrong vendor, then your shiny new application will quickly be relegated to the dustbin of history, either dashing user expectations through clunky responsiveness or falling over when your user odometer rolled past 99,999, killing whatever momentum your project has.

Well, gentle reader, I’m here to tell you that things aren’t quite so bad, because technologies don’t matter. *

Quick aside about the *. In the time-honored tradition of internet analysts, I’m making bold, sweeping statements as a way to create engagement; these statements require qualifications that make the headline hit a little less hard. I could have called it “Technologies Don’t Matter, Unless You’re Dealing with Systems Programs That Require Specific Languages or Certain Verticals Like High-Frequency Trading Where Every Microsecond Counts” but it doesn’t have the same ring to it.

Of course technologies matter sometimes. This article is more geared at the developer working in a corporation, building internal applications for 200 people, or for consumer-focused developers just getting started with their new product, where their concern is trying to move quickly and find product-market fit rather than late-stage startups with the resources to build all of their own custom infrastructure.

Let’s go over some reasons why that’s the case.

1. Projects Rarely Fail Because of Their Technology

If you think back to projects you’ve worked on in the past, how many can you say failed purely because of the technology they used? I can’t think of any.

You know what makes projects fail?

  • Missing a market opportunity because development took too long.
  • Getting the specifications wrong from the client so that the completed application didn’t do what the users needed, or didn’t do it well enough.
  • Launching the wrong product, and not finding a market for what did get released.
  • Poor marketing.
  • Creating a great product for a market that doesn’t exist.
  • Long sales cycles causing the company to run out of money before they got enough customers.
  • A million other things.

You know what isn’t on that list? Having a great product with happy users throwing money at it, that somehow couldn’t figure out scalability when it became an issue.

Now to make a baseless assertion: It is 103 times more important to build the right thing than to build that thing in a particular way. 103 times! That’s a big number.

Way too often we don’t question the assumptions that go into the project and just sort of give them a pass because it’s so fun to just jump in and start building. The client calls us and says they want to make something. We should ask why. We should dig deep into what their (potential) users currently experience, and how this will be better. And if the users will care. We should ask how they plan to go to market. Is this another “if we build it they will come” scenario? Have they looked at their closest competitors? Do they know they already have competitors?

When a project goes bad it can affect relationships, and in some cases livelihoods. It’s important that people understand that you can’t “tech” your way out of a crappy idea.

2. Most Technologies Don’t Really Change Much

So one of the biggest changes to hit the webdev world in the last few years is the rise of the Single Page Application, where instead of having a web server render (or just serve up) a new page each time the user navigates to a new URL, the website instead uses its internal code to render new screens without ever going back to the server. Essentially, the Javascript application owns the user’s experience during the web visit.

This has opened up whole new worlds for developers. It helped support the development of component libraries that live entirely inside the browser. It helped offload computation from the web server and into the browser, creating more responsive user experiences with less lag. It let front-end developers control the entire user experience from soup-to-nuts without ever needing to interact with the back-end team. (Unless they need data. But who cares about that?)

And do you know what it did for customers of those websites?

It made their page reloads slightly faster, at least when the sites weren’t database-constrained.

Earth shattering!

Ok, I’m (slightly) farming for engagement again, but the point remains: The biggest change in the web development world in the last few years is much more important for producers of websites than consumers. And this is a problem.

The real benefits of the Single Page Application model are really only felt in a few scenarios:

  • Your developers need to be hip to this new world. There are a lot more React developers nowadays, but I’m pretty certain that they are still a minority among web developers.
  • Said developers also need to be good at writing effective React (or other SPA framework) code. Not a given. It they are less good at it (for instance, copying and pasting components and component code all over different files to “just get it done” rather than refactoring components as new information or requirements become available) your app will be no easier to maintain than an old-school one.
  • Your application needs to be long-lived and constantly maintained. As someone who has spent an inordinate amount of time trying to maintain websites and applications written by others with no documentation, I can tell you for a fact that editing a simple PHP file to fix some copy error is orders of magnitude easier than recreating the development environment somebody had 3 years ago to rebuild the Javascript bundle used to make an SPA website, assuming you even have access to the original source code. And that what was checked in to version control represents what’s on the live site. Sigh.
  • Your developers must be better at the SPA code than they are at their old way of doing things. Anybody who has been coding for any period of time has developed shortcuts for doing their job. Custom libraries that scratch some itch they have had repeatedly for the last 15 years. Pet modules they bring in to everything that make them 5x as productive because they know them so well. For these developers, they can jump into a new project and already visualize all of the steps needed to get it done. Depending on the size of this project, they might be able to pump it out in a week. If you have one of these folks on your team, you may just want to let them do their thing.
  • The application isn’t database-constrained. The single page application saves time and seems more responsive because it doesn’t have to wait for the server to render the next page. Unless, of course, it needs to get data from a database or some other datasource over the network, in which case it will still have to figure out some sort of loading animation. Yes, I know, loading animations are much more appealing to users than loading bars in browsers. But I really don’t think users care as much as developers do. It’s also worth noting that it’s pretty trivial to write a small library on your own that makes links reload just parts of your page rather than actually do a browser reload, so if that’s truly an experience you want your users to have, there are options.

Innovation occurs in a context, and it’s important to note that that context is different for different organizations.

3. Getting the Model Right is More Important than the Tech You Use

It’s important to separate technologies (like NodeJS/Express, or PHP/CakePHP, or NextJS/React) from the underlying models of the applications they are used to build.

Each of these technologies is functionally identical, although there are details that separate them. NodeJS, for instance, is a single threaded, event driven application (I think?)  whereas PHP uses more of a traditional web server model, where the web server (a separate program) gets a request and then either launches a new thread for the PHP binary or punts it out to a different process, and then sends the resulting HTML back to the browser. Despite this, each of these has the primary purpose of generating HTML that can be rendered in a browser. (and accepting user input, etc)

By model, I’m talking more the structure of the application. For example, when you log in a user, do you do a bunch of other lookups for that user to grab various pieces of data to put in the session? Do you record the login someplace? As the user navigates around the site, do you track them? Do you need to send events someplace? When you show a list page, do you do a bunch of joins to generate the data, or do you use a denormalized table somewhere? Do you display data in realtime, or is a lag of a few minutes acceptable?

Getting this design right is more important than which framework or technology (or third party service) you use to implement it.

If you need to look up data with complex joins across 15 tables in 6 different places to display a dashboard, it’s going to take a long time. If, instead, you can have a cron job pump that data into another temporary table every minute and just query that (with appropriate indexes, of course) you can increase performance many times over. Little optimizations like this will let you punt the decision to bring in some third-party service long into the future, and possibly forever.

4. The Team is More Important than the Tech

You’ve already got developers on your team. They work well together, they get along. They buy in.

They also have particular skills that they’ve been honing for years.

In this constantly evolving technology world, developers need to always keep an eye on what’s going on and keep their skills sharp. It’s true. But it’s also true that the job of a development team is to turn programmer hours into working products on a timely basis. Often the most expedient path is the one well traveled.

There is a balance to be struck between working with what you have and integrating new stuff. If your developers are good, they are already keeping an eye on where the industry is going, and can figure out how to integrate the interesting new parts with their existing infrastructure. Good developers like the autonomy to do things their way; it’s worthwhile to point things out or propose ideas, but it’s important that they are the ones figuring out how to fit it all together. They need to take ownership at their own pace, and if it’s forced on them that will never happen.

Often times morale at a company can be the difference between hitting deadlines and not. You put in extra time when you love what you’re doing.

Conclusion

I’m fairly certain I’m not going to convince anyone who lives on the bleeding edge that it isn’t the best place to be. It’s certainly exciting.

Our industry isn’t just one thing, though. For every shiny new project, there is a mainframe running COBOL somewhere. And many websites running WordPress.

Watching it for so many years, it feels like if you miss a couple turns around the carousel, you’re better off retiring than trying to get back on.

That isn’t the case!

The actual fundamentals almost never change. Sending stuff over the wire is still slower than having it locally. Stuff in memory is still faster than stuff on disk. Hashmaps are rad. It’s faster to send stuff over the wire and not care about a response than to need every conversation to be two way.

So take heart, fellow old head. You still have to learn a new trick every now and then, but the skills you have are just as useful as ever.