The extreme circumstances surrounding humanitarian relief require extreme making
Brad lays out a set of three "non-comprehensive loose set of guidelines" to help solve problems fast, and in adverse environments:
- Roll in it.
- Make it/break it
- Deliver. Fast.
His case in point was going down to St. Thomas after the hurricanes of 2017. Utter destruction. He likened it to a war zone.
The problem was almost too big to comprehend. How does ... one even begin to dig in and make a difference? Well, sort of like peeling an orange, you just jam your thumb in and get after it.
That's too true. In a previous position, at a start-up, a co-founder would more than often be overwhelmed to the point of losing any focus and productivity. Now, granted, we were not in the same environment as a storm ravished island, but the fear was the same. I recall having to remind him many times that it's just baby steps. Break the task down into smaller bits. Make a list.
Check off items.
It may be psychological, but it sure feels good to see things being done.
Back to Brad and Extreme Making...
At a minimum this process is iterative, moves fast, and gets intertwined quickly.
This is starting to sound a lot like Scrum. I've always worked in the way of the Scrum, even if the roles I filled blurred across some of the lines, like owning and prioritizing the product backlog. I've always been a mentor (Stackoverflow) with junior members of the team which probably harkens back to my days of teaching in graduate school. Of course Scrum uses an agile and iterative process. Maybe this was drilled into my work flow when we were making web applications at Shareholder.com when the SEC was putting in place many new laws governing how public companies needed to communicate with their shareholders. There were quite a few investor relations officers that would drive product development. I found that when I became a Certified Scrum Master, that I felt at home (at work).
Roll In It
This can be true with agile teams as well as with disaster survivors:
Immersion must be with eyes and ears open and brain firing, but also mouth moving. Communicating ideas and the understanding of the problem to others ... concisely and frequently helps in the rapid prototyping process, even if the prototype is designed, developed, tested, and subsequently killed all in your head.
This early product development process is obviously important in the field, but also in the office when the software team is learning about the product. Some of the best products are created to solve a need that the developers have. Why? Because they know the problem well. Think Slack, or Basecamp. So if you're not the creator of the need, then you, as a development team need to become immersive with the product owner and other stakeholders.
Losing sight (i.e. immersive understanding) of what is helpful to the person operating the technology results in cool gadgets that won't get used (e.g. Google Glass).
Make It/Break It
Don't roll in it for too long! The environment is always changing.
Boy is that ever true in software development! SCOPE CREEP We all know it. We've all seen it. Put can we control it?
One never has all the information that is needed. This is why agile is so valuable...how many times have you heard "I didn't think of that, but it's a great idea," or "Oh, I forgot," or even, "which means that you need to..." As Brad states it, one "ever has the entire picture or all the parameters when" when the process is started. Even in Waterfall methodology where so many resources are spent in the design phase, everything isn't a known quantity prior to building.
So, what happens? You fail. Hopefully not in a big ball of flames where you have to throw the whole codebase out, but hey, failure is failure. That's only acceptable if you can learn from those mistakes/failures.
Here's the one major difference between Brad's view while on the ground, and my view developing software: The people Brad is helping "have a high risk-tolerance. They are desperate for help." Me: I have a client that wants a product out the door, but they might have brand awareness, or a reputation to uphold and pushing out some code just to see where it fails, could be problematic. (However, we do have beta testing, and even focus groups.)
The single most important thing you can do when making a solution for someone is to deliver it. Show up and deliver
This doesn't really seem to be a product attribute, but rather a maker/developer attribute. There's a survivor/team that needs you. Do your job. This is super important in disaster recovery zones, and less so, in the grand scheme of things, for developers. Brad needs to deliver fast because it may be life saving and his "clients" are a "population that is already suffering, exhausted, and feeling abandoned."
Yes, our clients are worried. They have a reputation. They don't want to waste money or lose users. Where we do have to deliver fast is when there is a bug that is prohibiting users from buying product, for example. Another need for speed is for entrepreneurs when there is a small window to take advantage of an opportunity -- think getting your MVP -- Minimum Viable Product, out the door as soon as possible. (As a side note, I highly recommend reading the book Rework by the owners of 37signals -- creators of Basecamp.)
I'd like to finish with a quote from Brad's article and it really hits home. Maybe not for you and me, but it does speak truth, and if you follow it in spirit, you'll be a good team player:
The important lesson is this: all of that rolling in it and iterative making is for naught if you don't show up quickly with something in hand. Not in a month -- tomorrow. Extreme making demands this kind of turnaround. Because if you can't deliver quickly, the people in need will lose faith in your ability to help them. You'll quickly become a marginalized battlefield or disaster zone tinkerer. And that's not cool.
Life is short.
Make something important.