The Mortal Enemy of Done is Perfect
Hey pals, welcome back to the Adventures of Blink! For today's adventure, I want to explore the concept of Agility. Wait, Blink, you covered Agile already Yeah, I know. We've talked about the value of agile thinking before. So why revisit? I ran across a really interesting post over at Pulumi... a story about "Your Perfect Infrastructure". As I read the story, it occurred to me that this is a very common pitfall for us as technologists... particularly those of the Architect persuasion, who spend their days in design and don't crack open the code very often anymore. Simen's story is super short, but immensely powerful... he designed "the perfect infrastructure". He future-proofed everything. But then as he worked to get it implemented, he found that his design had actually become his biggest constraint! How does that happen? It's about Commitment Not like relationship commitment... like database commitment. A 'commit' step is when you finalize your request and confirm that you want the database to actually do the command. Designing a system is a lot like that - at some point in the design process, you'll realize that you have to put in more work to undo something than you would to complete the build... and if you find a major design flaw after this point, it's super painful and expensive to alter the plan. Applying a little logic It stands to reason that if it's going to be expensive and painful to alter your design after committing to it... you should delay that commitment as long as possible. (Ok, on second thought, maybe it is like relationship commitment after all!
Hey pals, welcome back to the Adventures of Blink!
For today's adventure, I want to explore the concept of Agility.
Wait, Blink, you covered Agile already
Yeah, I know. We've talked about the value of agile thinking before. So why revisit?
I ran across a really interesting post over at Pulumi... a story about "Your Perfect Infrastructure". As I read the story, it occurred to me that this is a very common pitfall for us as technologists... particularly those of the Architect persuasion, who spend their days in design and don't crack open the code very often anymore.
Simen's story is super short, but immensely powerful... he designed "the perfect infrastructure". He future-proofed everything. But then as he worked to get it implemented, he found that his design had actually become his biggest constraint! How does that happen?
It's about Commitment
Not like relationship commitment... like database commitment. A 'commit' step is when you finalize your request and confirm that you want the database to actually do the command.
Designing a system is a lot like that - at some point in the design process, you'll realize that you have to put in more work to undo something than you would to complete the build... and if you find a major design flaw after this point, it's super painful and expensive to alter the plan.
Applying a little logic
It stands to reason that if it's going to be expensive and painful to alter your design after committing to it... you should delay that commitment as long as possible. (Ok, on second thought, maybe it is like relationship commitment after all!
