The Tyranny of Taxonomy -- how our need to categorize things makes every problem harder
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.
Outline/Structure of the Talk
- 1. Intro
- Ice-breaker activity ("how do you see yourself?")
- The need to categorize things
- Survival -- prey or predator, food or poison, friend or foe
- Curiosity -- sensemaking in a maddeningly senseless universe (the frustrating platypus and the annoying noble gases)
- Trade -- bartering and money
- Science -- the need to learn and ignore (the paradox of specialization)
- Some common categorization schemes
- The ledger -- for money and accounting
- The catalog -- for things
- The census -- for people
- Why are these a-priori schemes problematic?
- We want more and more specimens!
- We don't want more and more categories!
- Resolution: Lumpers and Splitters
- Activity: how would you bucket these?
- We don't need so many hard categories in software
- Do away with rigid hierarchies (classes, business rules)
- Favor a posteriori aggregations
- "You don't need to rebuild the bookshelf"
- An example: a food menu
- Traditional menu
- Reimagined menu
- Conclusion and Q/A
By the end of the talk, audience ought to be able to:
- Be critical of rigid categorization schemes, especially in software systems
- Be able to suggest alternates to these rigid schemes
- Gain an appreciation for the categorizations that do work in practice.
Software engineers, solution architects, business analysts, and product owners
Prerequisites for Attendees
A familiarity with the software delivery lifecycle (ideation, analysis, development, testing, deployment).
A familiarity with iterative, incremental software development.
schedule Submitted 3 months ago
People who liked this proposal, also liked:
Saleem Siddiqui - So what happens after you fail fast?Saleem SiddiquiPrincipal ConsultantSPR
schedule 4 months agoSold Out!
"Fail fast" is only half the bumper (or laptop) sticker; and the other half isn't "fail often".
"Fail fast" isn't an invitation to engage in Pyrrhic victories or outright losses. In this talk I'll share how failure can be used as a ratcheting mechanism to increase the probability of long term success. I will draw upon not only my experience, but also the audience's, to elicit the kinds of failures that are worth seeking and those that are worth avoiding.
Saleem Siddiqui - "Monoliths for Micro-frontends" -- why old architectures lobby for modern web appsSaleem SiddiquiPrincipal ConsultantSPR
schedule 3 months agoSold Out!
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.