Red Green Repeat Adventures of a Spec Driven Junkie

Specify What and Why: System Up

I’m starting a new project at work with the team using brand new technology stack. We are in new territory. That makes me scared and excited.

At the same time, we are short handed and backfilling. The team is busy interviewing, learning new technology, and delivering work.

One area that the team blew my mind on recently is the result they delivered for my request for simplified system setup.

In the previous project, getting the system up was 14 different steps, probably more because there is one step that is:

Download all the repositories and set them up.

The project has six code repositories. The old project doesn’t have 14 different steps, it has (at least) 20 steps.

Each step is not quick as new team members have mentioned setup time takes at least a week! (This is also another reason why I don’t have the application running locally - I don’t have the time for application setup! 😅) I do know it’s a problem. How to prioritize this work??

For the new project, I wanted to fix this - not for me, but for future team members. Honestly, I want the team to be developing new features or fixing bugs or improving the system, NOT debugging local system anomalies. The team has lost time because of something “weird” happening and they had to go in and figure out what happened. Database mis-configuration? Weird library update? The list goes on and the problem is a major blocker. Resetting is scarier getting a new computer is not joyful.

Approach: Specify WHAT and My Motivation

The approach I took in solving this problem was not to specify HOW I wanted the setup to work (as I have a strong , I specified: WHAT the setup should use and the goal.

  • Bring up the application with one step setup.

The team asked for additional guidance and I provided:

  • Be compatible with Docker (because the production system will use it).
  • Postgres Database (similar to Docker).
  • Monorepo (I kind of pushed the team on this 😅 because the old project had distributed repositories and I think we were hitting limits.)

Result

Currently, what the team delivered is:

  • the whole system is up running one command
  • seed data in SQL files for all service’s databases
  • pgAdmin integrated into the application

Basically, not only did the team deliver on the original ask of: one step setup, they threw in the seed data and pgAdmin into the mix.

Mind Blown: pgAdmin??

The pgAdmin blows me away because I avoid direct connections to databases. It’s too easy to “fat finger” something, lose access, and spend a week debugging my database configuration.

The team bootstrapped necessary tools for not only development, but for database administration too.

Would this have happened if I specified HOW the work should happen? From my experience, probably not. I know if I was the person implementing the work, I would just deliver what’s asked. No more, no less.

Difference Now??

I shared with the team my motivation I wanted this work, each requirement’s background, as much as possible, be impartial/objective for each of those.

I believe the team took those motivations and reasons, internalized it themselves to deliver something they would be proud of, that happens to be beyond my expectations.

Because of the result they chose to take, adding more components into the setup is possible - something I look forward to working with them on.

I have written about specifying why and what, not how before. This is an instance where that result is better than expected.

It’s moments like this that make me love being a manager.