Don’t be an Architecture Hipster – A guide

One of my more popular HN comments was a teardown of an all-too-common engineering subculture. The article in question sought to teach “Software Architecture,” but ultimately annoyed me and many other HN readers.

Tl; dr:
Software architecture discussions are so polluted by software-hipsters that the majority of software engineers are disinclined to discuss and study architecture at all.

Know-it-all / hipster

  • Probably studied philosophy, english, film-studies, or engineering.
  • Lurks around discussions, hoping to overhear a mistake, any mistake. 
  • Uses an unnecessarily complex vocabulary
  • Has a self-righteous and loud tone of voice, especially when correcting people.
  • Enjoys correcting people, even on minor/irrelevant points.
  • If asked him a question you can be sure of two things:
    1) he will never admit he doesn’t know
    2) he will answer with so many niche terms that you will end up more confused than when you began
  • He may be likened to Dwight Shrute, or the comic-book guy.

Architecture  Hipster

  • Loves UML making diagrams. Gladly presents them without a legend to people who don’t know how to read UML diagrams.
  • Love creating new unintuitive names for very simple ideas (e.g “Broker topology”). Proceeds to use these niche names in discussions and judges other people for not knowing what a “Broker Topology” is.
  • Gets really into programming fads that are hailed as panaceas but later get tossed out for a new panacea (e.g. microservices, Layered Architecture, REST).
  • Gets very emotionally attached to programming decisions, even if they will have no effect on the user.
  • Loves engineering around unlikely “what ifs…”.
  • Prefers creating abstraction through classes instead of functions, even if no state is needed.
  • Is bored by “practical details” like logging, debugging, convenience, fail-safes, and delivering quickly.
  • Maximizes the number and obscurity of patterns used, leading to classes named things like EventLoopListenerFactory.
  • Only cares about performance if obscure (e.g. tail-call optimization)
  • Isn’t actually very capable creating software (hasn’t won any coding competitions, has trouble with git reset, hasn’t written any software that people enjoy using)


Know-it-all / hipster
 = Architecture  Hipster 
+ software architecture 

I don’t dislike architecture. Architecture is a beautiful study. However, the complexity of the discipline makes an fertile ground for phonies; a space for phonies to use miscommunication as a tool to create an illusion of their own competence.

8 thoughts on “Don’t be an Architecture Hipster – A guide

  1. Nice article it’s like a conversation I had with a friend, I don’t consider myself a hipster architecture but some points rememered me myself, I’m gonna work.on that 🙂

    1. I think the difference between a hipster trend and a good best practice principle is that a good principle will justify its existence by making development easier or the product superior or more versatile.

  2. Hi Alex. Found this post through twitter, and I thought I’d share my opinion with you on the subject.

    I work as an architect in a small software outsourcing company in Buenos Aires. I mostly code and I love doing it, I agree with the idea that architecture should be part of the software and not some abstract diagram in a wall that doesn’t mean anything to anyone else. While I was reading your post, I felt I should agree with your sentiment, separating “phonies” from real architects, but I found that hard because several things you point out are actually things I know I do. I’ll focus on them to shed a light on our differences, but I still believe that we probably agree on some higher level here!

    The Know-it-all part is pretty clear, and although I sometimes find myself focusing too much on details, I understand that it’s sometimes seen as picky or can be confused with a need to show off. I can personally say it’s not. In most cases, people that feel the need to correct irrelevant things do so because their overall understanding feels flawed, they found that something does not add up, and need to adjust this detail so that “everyone is on the same page”. Of course this can be taken to extreme cases where we don’t really care about that detail, but we, the guys who obsess on those details, have a hard time differentiating those cases. We have a problem on that aspect, not driven by showing off, but by an obsession and a need to be precise, correct. I say this because it’s one of the things that I’ve worked on my entire life, even before getting into software, and has been a major problem for me to relate to other people.

    On the architecture part, there are a few things that we do when we try to communicate ideas, and while most (if not all) of them are aimed to ease understanding, some may need a common ground for everyone to use them, and when it’s not there, they can feel as a barrier instead of helping.
    UML, for instance, is one of them. I don’t do any kind of UML permanent documentation, so when I use it, I oversimplify it. I use it as a drawing, just boxes and arrows, with class names and maybe public methods, but that’s mostly it. I know some of the people I work with haven’t done any CS studies and don’t care about it, so maybe they don’t “know UML”. I don’t tell them it’s UML anyway. It’s a drawing. I’m trying to help them understand something by using both words and drawings. I really hope it helps, because the alternative (just talking) can be really hard to grasp without actually sitting down and getting stuff done. I know, we should all sit down and get stuff done, but my job involves a bit of upfront design, to help people understand our client’s problem, to design some very simple part of solution before coding it. Sometimes it involves refactoring an ongoing project’s model into a better one, same kind of process. Communicating knowledge is hard, specially when you deal with different people with different levels of understanding, studies and background. It all boils down to communication, as usual.

    I know I sometimes use “complicated” words. Again, I don’t do it to show off. I just know (or thing I know) them, and when talking, feel that they mean exactly what I need in that moment. Obsession with precision and detail, again. But, to be honest, if I use a “complicated” word with someone, that says something about that person. I’m not being condescendent, I’m not “simplifying” my way of talking because I believe you won’t understand me. I respect the other person’s knowledge. If the other person doesn’t understand me, I hope they stop me and say “hey… what? what’s flabergarber?” and that’s it, we continue a normal conversation. I believe most professions have their own lingo and lots of words get defined to help us communicate either more precisely or in a more abstracted way. Some may use that to show off… yeah, but let’s not assume all people belong to the worst case. Let’s help them out if we feel they do.

    One thing I do wanted to point out: please don’t call people names. You’ve defined a new term here in your post: The architecture hipster. Is that good? Now people with completely different background than you or me will read this post and use that whenever they feel someone else is giving them a hard time and involves architecture. We should know by now that tagging people is a form of bullying. We shouldn’t encourage it.

    Let’s identify these rough communication spots. Let’s educate on how to avoid them. Let’s treat everyone with respect and assume they don’t have any bad intentions on each thing they say. And, when we feel they do, let’s help them know that. You’d be amazed at how little these “hipsters” actually know about how YOU feel.


    1. My goal with this piece was to educate on how to avoid those who use discussions as a platform of self-promotion instead of a platform of mutual education. So when you say

      Let’s identify these rough communication spots. Let’s educate on how to avoid them.

      I think we’re on the same page.

  3. > Prefers creating abstraction through classes instead of functions, even if no state is needed.

    That’s a weird on in the list. In many languages you get advantages by using classes/interfaces rather than functions beyond shared state between methods.

    1. Yeah this one’s hard to express, but I’ve noticed it. In the Cult of Architecture patterns are for some reason associated to “classes” even though any abstraction that can be done with classes can be done without classes. So if somebody implements an abstraction in a new or creative way (often functional programming-ish), it’s a strong signal that they are actually thinking about and inventing (true enthusiast / non-hipster) rather than parroting something to show they “belong.”

  4. So,
    ( software architecture) == (Architecture Hipster) – (Know-it-all / hipster)

    I think that the important thing is modeling real world, and a reason why write a software.

Leave a Reply

Your email address will not be published. Required fields are marked *