A couple of months back, my wife was working on updating our fence. Specifically, she was improving the gates.
We had two gates. On the west side of the house, we had a small gate – mostly for people but wide enough for a mower. On the east side, we had a more massive vehicle entry. When we first built the fence about ten years ago, we had no idea what we were doing. We worked with what we had, and, in the end, we built a solid, working fence.
The large gate was held closed with four screws. (I kinda wish I had taken photos of all this…) The small gate had a latch, but the gate was a tidge too beefy and would rub when it closed, making it difficult to latch the lock.
Put simply, it sucked. It wasn't the best experience, but the fence and gates served us well for ten years.
Fence: Mark II
The new gates are a considerable improvement. In fact, there are now three gates. Two small gates, one on each side, and one large gate that actually swings open without having to unscrew it.
Armed with slightly more knowledge than ten years ago, we began the rebuild with diligence. It also helps that the internet is a more vibrant place in terms of sharing knowledge compared to last decade.
The first thing my wife built was the new, small gate. The kick-off for the project was drilling into cement so the latch post could go up. Apparently, drilling into cement was fun - I didn't participate in much of the build if any. (I just fund this operation. She gets to do all the fun stuff! 😆 ). After the first gate went up, a section of fencing went up. The next day, another part of fencing went up then another and another.
Eventually, she made it to the large gate. The large gate we thought about and researched for a bit. It was a swinging gate, so we knew it was going to be heavy and would need additional support. The large gate went up, and she continued to move along.
This was when I noticed what she was doing. She was releasing something every day. It’s a common strategy in software development. Yet, it was interesting seeing my wife commit to deliverables for that day and work towards her goals. Some days she would hit her targets, while other days, challenges would force her to revisit her commitments. Either way, she tried to “release” something every day.
Between the two of us - her building and me helping as needed, mostly to bounce ideas off of - we were able to make changes daily. Sometimes more frequent than that! Compared to software, a fence is straightforward, so two people working on something of this complexity makes sense.
The Perils of Releasing Often
"Releasing often" can be dangerous. It requires discipline from the team at every level - from users to managers and beyond. These days, the term "releasing often" seems to come more often from business managers than engineering managers and serves as a buzzword to convince stakeholders that the team can, and will, deliver value incredibly fast. That isn't fair to the people in the trenches. Often because engineering teams are understaffed and middle managers are forced to overpromise on deliverables to director level folk.
One could argue that the above is all just a communication break down. I agree with that, but there's more to the story than only communication. I think there's a systemic problem brewing. But that's a post for another day.
Our fence was built by people that had the autonomy to decide timelines, research solutions, and choose the build strategies. Along with more ethical decision making in engineering, I hope to see more independence given to engineering teams. Which should result in more fair representation at the decision table.
I'm not saying work should be easy, we should be challenged! But there is no need to sacrifice quality and humanity.
Our fence isn't software. But it is really hard to CMD+Z a cemented post. Yet, we got much more beautiful and usable fence this time around.