Front-end / back-end isn’t a useful distinction

Home » Blog » Business » Front-end / back-end isn’t a useful distinction

Leider ist der Eintrag nur auf Britisches Englisch verfügbar.

Answering a Hacker News Ask HN titled “Why companies look for “full stack” developers instead of specialists?” I wrote this:

Front-end / back-end isn’t a particularly useful distinction in my opinion. Differentiating between those 2 is just another way of creating information silos.

I’m old enough to have experienced at least 2 full thin-client-fat-client cycles and I’m certain the current one won’t be the last (at least it seems to have been a recurring pattern since the beginning of modern computer science). While the front-end / back-end paradigm might make some sense right now because the technologies used for each of those layers conceptually seem to be quite different from each other I doubt it’s really that much of a benefit. On the contrary, it might even be detrimental to effective software development:

I’m not in the business of creating either front-end or back-end code. Neither is useful without the other. I’m in the business of creating value and solving problems with software. Depending on the problem at hand this can involve different tools at varying degrees.

Focusing on just one tool or layer can lead to a potentially harmful mindset. A mindset in which you just throw your part of the work over the wall thinking that it’s not your problem anymore.

The arguable benefit of having specialists churn out stuff in their respective layer more quickly than a generalist would quite likely is offset by communication and interface overhead: The difficult problems in business applications nowadays mostly arise at their boundaries. Software development for the most part means communication.

I wanted to share this here as well because I think it’s essential to think about software engineering not in terms of specific technologies and technological silos but rather in a more wholistic way:

  • What’s the problem we’re trying to solve?
  • How do we reliably find out about the requirements of a particular solution?
  • Who’ll be involved in the creation of this solution and how do I interact with those stakeholders effectively?
  • How do we communicate the intent of the code we create in as clear a manner as possible?
  • How does the solution fit into the bigger picture? How will it be connected to other components? How will it communicate with the outside world?
About the author: Bjoern
Independent IT consultant, entrepreneur

Leave a Comment