I’ve been writing software a loooong time. I’ve seen a lot of ways to do things. Scrum, Agile, XP, Waterfall, etc. This is my own dumb way of doing things. It’s one that makes more sense. I call it D.I.S.A.R.M. after all, in real life, your business is trying to disarm the competition.
This is a series of steps, which you apply, in order. Chances are, you’ve always been in the first step and never even considered the others. If you’re writing code 5 days a week (or more!), then there’s a good chance you’re just banging out busy work.
Oh, and you’re going to need a dartboard. That’s not a typo.
There’s a phrase in the Army: Slow is smooth; smooth is fast. I’ve seen medics do their jobs under stress. You know who the successful medics were? They were slow, so slow they were fast.
The one’s who rushed though. They were slow. They didn’t take the time to get it right the first time and they paid the highest price. Their patients would bleed out, bandages would fall off, tourniquets would come undone. They would even triage incorrectly.
The one’s who took their time to make sure they got it right the first time saved lives. They accomplished more in 3 minutes than their rushing counterparts did in 10. People survived.
I saw hundreds of these medics perform the same tasks over and over again during a Best Medic Competition. This was the biggest difference between the good, the bad, and the best.
Deploy
Our job as Software Engineers is to build things deploy software. We’re not computer scientists, we’re not craftsmen, however we’re tradesmen. We don’t make the company money by discussing Linked List vs. HashMap. If it’s not obvious, and there’s no evidence as to which one to pick, just pick one.
When we refine, we’ll decide which one. While we’re trying to deploy software, we just need to build it. The rest is implementation details, which aren’t important here.
Once you push that big red button, right down every feature you’ve built out during this phase. One feature per slip of paper and glue it on that dartboard.
Innovate or Integrate
Now, we’ve deployed our software. We’ll let it sit in production collecting metrics (you are collecting metrics aren’t you?) Our job now is to have a hack day or two or three. This is supposed to be fun, moral boosting even.
Put it behind a feature flag. This is a requirement.
Your goal is to innovate or integrate. Don’t reinvent something someone else is focused on doing well, integrate it. If no one is doing it, great, you’re innovating. Do it.
Don’t worry about the implementation details. Just hack it. It just kinda works.
Build what your users want, build what the business needs, build whatever strikes your fancy. Just have fun.
Sell
Take whatever you’ve hacked in the previous step: can you sell it? Would people pay for it? Deploy it to a separate environment and try marketing it. Do people convert and buy it because of this new feature?
If a feature won’t sell, then toss it out. If it’s something you can’t sell (like a new piece of infrastructure or a nice refactor), keep it around for measure.
While you’re waiting on this data to give you some direction, continue on to Anger and Refine.
If you ended up throwing everything out: go back to Innovate and Integrate again…
Anger
Stand in front of the dartboard, regulation distance. Throw the dart at the dartboard, try for a bullseye. Did it hit a feature? Rip it off the board and disable access to the feature.
Did anyone notice? Did people get mad? Did your boss notice? If no one noticed and nobody got mad, stop advertising it and delete the code. It was just adding complexity and didn’t actually create any value. Try emailing a few users, ask them why they didn’t use it. Learn from it.
However, if people did get mad. You better turn it back on, it’s actually valuable. You don’t have to glue it back on the dartboard as it earned it’s worth. Meanwhile, ask these angry users what they used it for, do not make assumptions. Learn from it.
Refine
By now, we should have some metrics from our last Deploy. How does performance look? Maybe we need to revisit a design decision. Maybe not. Now’s the time to decide if and what needs to be refined.
Measure
Now come the meetings… Like any good engineer in any other industry, we need to actually measure our material before we cut it. As a team, review any refactors and infrastructure pieces, features that are sellable and, any refinements that need to be made. Now’s the time to have that discussion about HashMaps vs. Linked Lists.
- Plan it out.
- Is there anything wrong with the hack?
- Why is performance what it is?
- Can it be refactored into production quality software or should it be rewritten?
If it needs to be rewritten, or is fundamentally flawed, toss it out until the next time you Innovate or Integrate, it needs more love and fun put into it. This ensures you’ll only be working on deploying stuff that will work instead of floundering and rewriting something from scratch. Rewrite it when you have time.
Go back to Deploy and deploy this to the masses.
At the end of each phase
Time to have a review. This should be informal, but, everyone should be present. Don’t take notes, just discuss.
Here’s the key points, keep it open-ended:
- Review the objectives of the phase (build x feature, etc)
- Review the intent of the phase (we were supposed to deploy/innovate/measure/etc)
- Review the tactics/procedures/techniques (how did we do handling bugs while deploying/were we too (a)sync?)
- What actually happened?
- Why did it happen and how to improve?
- Misc issues
- Any closing comments and summarize.
Why does this work?
There’s another good phrase, and this one comes from the software industry itself: It always takes three rewrites to really understand something.
By the time you’re team is actually building something for production. There’s a damn good chance the feature has been refactored and rewritten several times. This is good, this means it’s probably understood, performs well, and delivers it’s promise. I say probably, because you can still muck this up.