Derek Smart

Blog

  • When Safeguards Fail: Optimize for recovery

    Meet Kevin.

    She (yes, Kevin, a story for another day) loves spending time on our third-floor balcony. While I trust her inherent cat skills, my wife is less convinced. It prompted me to install lattice-style garden netting around the balcony. I spent arguably too much time ensuring no holes, no weaknesses in this safeguard. Certainly this will protect her!

    Despite my meticulous efforts, one day I spotted Kevin on the other side of the fence. She calmly attempted to return to safety, while I hastily dismantled parts of the fence to help her get back to the other side. Unfortunately, she either didn’t trust or understand what I was doing, as if not knowing she was inches away from a three-story fall…

    As I reached over the railing, Kevin playfully swatted at my hands, lost her footing, and fell like a flying squirrel to the grassy lawn below. Thankfully, she landed unscathed but shaken.

    This incident made me wonder: Did the fence, acting as a safeguard, help or hinder the situation? The fence (arguably) reduced exposure to potential accidents. However it also hindered a swift and safe resolution to the situation once the safeguard was breached. Would she have fallen at all if it wasn’t there?

    Optimize for Recovery

    In software development, we employ numerous safeguards like code reviews, CI tests, and staging or canary deploys prevent errors from reaching production. These measures help maintain high-quality, reliable, and bug-free code, mitigating risks associated with deploying to production and are there to ultimately protect our users.

    As we know, bugs are inevitable. No amount of safeguards can guarantee flawless software. When issues do arise, it’s essential to swiftly address them and learn from the experience.

    Kevin’s balcony situation surfaced some relatable takeaways when setting up your safeguards in software development:

    • Expect the Unexpected: Be prepared for the occasional breach of safeguards, and have a plan in place to manage such incidents quickly.
    • Optimize for Recovery: Safeguards shouldn’t impede quick resolution or reversion. Prioritize incident response time.
    • Striking a Balance: It’s crucial to find the right equilibrium between safety checks and slowing down your team from responding to issues.

    Consider these additional tips to improve response time when the safeguards fail:

    • Have a clear “In Case of Emergency” document. Ensure everyone knows where to find it, and has a reflex to check there. Put the link to it into the alerting or monitoring itself.
    • Equip your team with revert commands that can bypass required CI checks or time-consuming builds, enabling a faster resolution.
    • Don’t let a single individual or team become a bottleneck in the incident response process. Ensure that anyone with deploy permissions can revert a bad commit, increasing your team’s overall agility.

    Kevin’s balcony adventure served me a reminder of the delicate balance between implementing safeguards and trusting our abilities, whether we’re dealing with cats and fences, or developers and code.

  • Shipit of Theseus

    When all the code has been rewritten, is it still the same product?

    Refactors. If you’ve worked in the same codebase for long enough you will have experienced one. Or two. Three? Maybe you’ve lost count.

    Maybe you started by bringing the frontend up to the current Twitter-driven JS trend. Then wrote a new API namespace to feed it the data. And maybe as the product and feature set grew, there became a need to make it more modular and Composer packages seem like a good idea. The cowboy code you onboarded into isn’t PSR-4 compliant, and over time all the features get re-written.

    And so on.

    All of the code is different than when you started. It can be said to be better; Testable, readable, maintainable, documented.

    Yet the features it provides end users are the same.

    Is it still the same product? I find myself thinking about the ship of Theseus.

    The ship of Theseus is a thought experiment that raises the question of whether an object that has had all of its components replaced remains fundamentally the same object.

    A software product, just like a ship, is not just one thing. But to answer the question, a thing needs to be defined!

    Let’s use Aristotle’s four causes to explain “what is a software product?”:

    The material cause: “that out of which”
    This is the code that is written. The frameworks or libraries used.

    The formal cause: “the form”
    I think of it as the UX. How it looks visually and how users interact with it.

    The efficient cause: “the primary source of the change or rest”
    These could be the developers. The people behind the thing. Or maybe the product’s name.

    The final cause: “the end, that for the sake of which a thing is done”
    I think of this as the value it provides the end user. Like how an analytics product helps them be informed of traffic to their site, and how a caching product makes their site faster.

    A refactor, by definition, does not change the external behavior of the code. In a pure sense, we can say that the only thing changed is the form.

    Of course many software products evolve beyond pure refactors and the material cause. UI, UX, rebranding, new staff, and so on.

    I think it’s the final cause that matters most. It’s the value it provides that defines the product.

  • Look at me

    Look at me

    It’s the Law of Attraction. Life is Beautiful. 

  • Get WordPress.org plugin info api

    I keep losing this link. Maybe I won’t need to Google it every time if I actually write it down.

    http://api.wordpress.org/plugins/info/1.0/jetpack.json

    So, for example, get a nice list of all Jetpack versions (tags) in the .org svn repo. 

    $jetpack_info = json_decode( file_get_contents( 'http://api.wordpress.org/plugins/info/1.0/jetpack.json' ) );
var_dump( $jetpack_info->versions );

  • 7 Years with WordPress

    7 Years with WordPress

    Happy WordPressiversary, WordPress!