Becoming wide-eyed

As with anything new, give developers some shiny new something to work on and there’s always the temptation to dive right in and get started churning out features. This often means that you’re starting from the inside-out of a problem space and often some operational details are overlooked. When we’re done solving that problem, trying to release that or to push that to production is often a problem nobody had perceived.

I had recently experienced this on a project where we’d resorted to creating the application where we had added features and didn’t think about how it will be put to production. We had an idea of things like tech limitations and choices at the time, and, deferring that decision seemed right, but it later came to bite us when we wanted to release the first feature.

We had roadblocks after one another, these came in the form of security policies, technology choices on the CI/CD platform and adhering to the existing release process already in place while trying on some new set of libraries that weren’t available to the build agents. This whole thing cost us a couple of months of back and forth between dev/ops/admin folks.

So, if I could tell my past self, I would say, release early so you can overcome the operational barriers and release often even if it means releasing the project skeleton with minimal details just enough for you to get early feedback. You’ll get to collaborate early with people from various disciplines which may sway some technology or design decisions. Hope you have seen my point.

In the context of the book I’ve been reading, establishing a walking skeleton is hugely important.

Please go and read the book for yourself, my opinion doesn’t do it justice 🙂

Becoming wide-eyed

Written by Danish J