So what happens after you fail fast?
"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.
Outline/Structure of the Talk
- Activity: what's "failure", anyway?
- Impact of failure
- Resources spent before failure is made
- Resources spent to detect failure
- Resources spent after failure is detected
- So what is "fail fast"?
- The art and science of satisficing
- Activity: how would you design to fail in these scenarios?
- Documentation - the power of story-telling
- Summary: the successful way to fail fast
At the end of the presentation, an attentive and engaged audience member would be able to:
- Distinguish between advisable and inadvisable ("smart" and "silly") ways to fail
- Design ways to fail smartly in situations small and large
- Detect when a silly way to fail is under foot
Software Architects -- who want to learn how to make meaningful mistakes
Prerequisites for Attendees
To get the maximum value from this talk, an audience member:
* Would have been part of a cross-functional software delivery team
* Would understand common, contemporary software development practices, viz: test-driven-development, continuous integration and deployment, pair programming, and iterative and incremental development (using user stories).
schedule Submitted 4 months ago
People who liked this proposal, also liked:
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.
Saleem Siddiqui - The Tyranny of Taxonomy -- how our need to categorize things makes every problem harderSaleem SiddiquiPrincipal ConsultantSPR
schedule 3 months agoSold Out!
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.