Micro-frontends are the rage. I suppose the microservices movement just had to breach the firewall and conquer the frontend frontier. That's all good by me: if small is in, count me in!

However, is this the only appropriate use of micro-frontends? If you don't have microservices yet, how might you get started with micro-frontends.Or do you need to be even taller to use micro-frontends than you had to be to use microservices?

Before you inject growth hormones into your architecture (or your physique), give me 45 minutes of your time. I may be able to convince you that micro-frontends make just as much sense with legacy, monolothic backends as they do with sleek, svelte microservices.

Perhaps it's evolution, perhaps it's the post-agricultural-revolution culture. Whatever the reason, we like to categorize things. Young children play "Name, Place, Animal, Thing", and older ones Dungeons and Dragons -- learning from an early age how to classify objects. Still older "kids" compartmentalize roles, tasks, opportunities, and risks at work.

This need to categorize things can hinder our ability to solve problems. We create categories too early, allow them to seduce our mental models too deeply, defend and fight for them with much zealotry, and cling on to them for too long. When designing and building software, things change swiftly and often -- a rigid categorization scheme can be a stumbling block.

In this talk, I'll present some common (and surprising) categorization schemes that are best used sparingly in software design. With example, candor, and humor, I'll show you how we'd all be better software artisans (and perhaps, people), if we used categories less frequently.