The Blind Men and the Elephant

A cautionary tale of technology choices in the 2020s

I read an interesting Medium article today. It was well-written but highly subjective — though it did resonate with my own personal experience. What surprised me was the vehemence of the attacks it provoked. Apparently, Angular is more of a religion than a Web framework. That response started me thinking about how we choose our technologies nowadays.

Since I began building software in 1972, a few — really, almost all — things have changed. In fact, for most of my professional life I’ve had the challenge and the pleasure of constantly learning and using new technologies and tools. The only constant has been change.

As I have run development for both startups and large ISVs, I think I have a pretty reasonable perspective on where the challenges and costs are. For what it’s worth, here’s what I believe. Individual technologies and frameworks are useful but transient tools of our trade. Most will pass and ultimately be replaced. Is it likely that you would get emotional over what brand of hammer someone else uses?

I think that one of our profession’s problems is similar to the parable of The Blind Men and the Elephant. We humans have a tendency to claim absolute truth based upon our own limited subjective experiences and ignore other people’s limited subjective experiences, which may be equally valid. Today, many developers work entirely within a constrained problem space: browser-based and mobile apps, server-side services and microservices, SQL and noSQL databases, games, and any of the myriad of other specialties — data center and cloud computing — vendor-specific or hybrid cloud technologies. It is awfully easy to start thinking that one’s small piece of the software development world is the whole world.

Sometimes specializing too much can be detrimental to understanding and applying the software engineering and architectural principles that were hard learned over the past 50 years — and can lead one into the always dangerous trap of thinking one knows more than one really does. It’s OK to specialize, but a reasonable grounding in general software architecture and engineering principles, and a reasonable appreciation of the other aspects of software and software development, are needed if one is to avoid being bitten in the posterior by the ever-present jaws of reality.

Virtually every choice made in the design and implementation of software represents a compromise among competing requirements. To think otherwise is naive. There are no perfect and no best choices — only the compromises that can be made to work.

Most, but not all, of the negative responses to the Medium article were from people whose work was very Angular-centric. I’m not suggesting that Angular is bad. But it is not, and cannot be, perfect. No framework is. In my opinion, a professional software engineer should strive to understand and deal with its weaknesses (no matter how minor they might be perceived to be) — not get angry or emotional in its defense. We all have more to learn, and rationally responding to criticism is one way to do that.

For any who might want to think more deeply on the compromises that frameworks like Angular must make, here are a few that concern me, personally:

1. Separation of concerns: User interface software should focus on the UI/UX and not upon the underlying application implentation. A UI and its components should focus on presenting data and choices to the user and responding to the user’s actions. It should send messages to the underlying application in order to retrieve data and implement the user’s expressed actions. That is a hard-won lesson resulting from building Mac, Windows, Swing, Eclipse SWT, Web, iOS, and Android applications, beginning with the Mac in 1985. Application testing and maintainability is greatly simplified by that separation. From my perspective, Angular mixes UI and application functionality to a degree that might be acceptable for traditional Web (or mobile) apps but is problematic for cloud-based microservice applications.
2. Level of abstraction: Over the years, many of the improvements in software productivity have been from increases in abstraction without sacrificing too much control over the underlying model. Angular presents a high degree of abstraction to the developer, but for me the abstraction departs too much from the underlying technical model for me to be comfortable with it. I suspect that a developer who has used only Angular might have difficulty even describing the underlying technical model. That seems risky to me.
3. Consistent architecture: A consistent architectural model makes a framework easier to learn and exploit. From my perspective as a software architect, Angular is more a collection of useful features than the implementation of a well-designed architecture. It’s most apparent objective is to reduce coding, but it shows little evidence of a central organizing theme. Reducing coding is very useful — but as coding is usually no more than 10% of the cost of implementing a software system, I would rather have the testing, reliability, and maintainability benefits of a more consistent architecture.

The moral of this story is to choose frameworks wisely, with your eyes wide-open and a clear understanding of the compromises. Nothing is perfect and nothing lasts forever. I’m relatively certain that those who attacked the article mentioned in the beginning of this piece are unlikely to be any more receptive to my opinions. The best I can hope for is that some might at least think about the points discussed and perhaps try to learn and evaluate other solutions as well.

Those who do not understand the past are doomed to repeat it.