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
- Introduction
- 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
- Q/A
Learning Outcome
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
Target Audience
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).
Links
Presenter for 15 + years at a variety of conferences in US, Europe, Asia and Africa. Some links are attached.
"This is how we Sonic -- lessons learned from builiding an integrated customer engagement platform" - NYC, 2018
"Versioning your APIs" - Chicago, 2017
"TDD Zen: Let's Test Drive like we mean it" - Chicago 2017
"Essential and Incidental Complexity of Software" - Seoul, South Korea, 2013
"Using Conway's Law and Human Psychology to do better Software Testing" - Malmö, Sweden, 2013
"Mr. Jenkins takes to the cloud" - NYC, 2012
schedule Submitted 1 year ago
People who liked this proposal, also liked:
-
keyboard_arrow_down
Saleem Siddiqui - "Monoliths for Micro-frontends" -- why old architectures lobby for modern web apps
40 Mins
Experience Report
Intermediate
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.
-
keyboard_arrow_down
Saleem Siddiqui - The Tyranny of Taxonomy -- how our need to categorize things makes every problem harder
40 Mins
Talk
Intermediate
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.