Do the Real Thing in Software Development

Doing the Real Thing

I read an interesting article recently called “Do the Real Thing” and parts of it resonated with me and some experiences I have run into with software development. There are three elements that are part of doing the real thing listed in the article.

  • Nothing is better than something
  • The hard way is the easy way
  • If you’re not sure what the real thing is, just ask.

Nothing is better than something

There are a lot of unessential activities in your life. You can try something called a “reverse pilot” I learned from a podcast that touched on Essentialism. This involved stopping participating in some activities to see if not having them causes any problems. While this should not be applied to everything, I cut out meetings that weren’t adding value and found meetings I shouldn’t cut out as well. In addition, I usually set an interval for recurring meetings so they can expire naturally and if they don’t continue there’s no loss.

Cancel projects that are going nowhere. It might feel good to make small amounts of progress across many different activities, but they are false gains. Governance is an important activity and neglecting accountability does no one any good.

Saying yes to new functions, features, software is saying no to future activities. There is a cost to everything we build, and it is easy to think of every problem as something that has not been automated yet. It might be a wicked problem in which keeping it solved is too expensive. Never ask yourself if something can be automated. While an Amazon style six-page memo might be overkill at least attempting to write up either what the problem to be solved is or what new opportunities are to be gained is worth doing before over-investing in wasteful initiatives. Try to find any reason not to do something to avoid wasting lots of time and resources on things that do not matter and do not add value.

Do not expect 100% output all the time from your creative staff. Build slack into the system to cope with unexpected events and pivoting due to changes in the market.

It’s ok to do less you’ll get more done that way. A steady trickle of small value is good enough.

The hard way is the easy way

One interpretation from the article is that we know what is worth doing and that it requires hard work and still avoid it. I think this is common but a trend I have seen as well is over-extending effort on difficult tasks because people were confused that difficulty is equal to value. Something might be incredibly hard, time consuming and worthless.

What is easy is to start executing without a plan and then not monitoring for success. We can delude ourselves that on our journey to solve problems we will stumble upon something of value. We need to seek feedback on our designs as soon as possible. Seek disagreement on everything. Seek out risks and save us all time in efforts to avoid working on the wrong things. I value people that are skeptical even if they are wrong, they’re able to give more feedback than people that are only positive.

Figuring out your business and how to continue scaling it without losing coherency is the hardest thing. No consultant will come in knowing more about your business. As technologists we are attracted to complex popular things and building a Kubernetes platform, inventing a new message queue, or a database is highly unlikely a differentiator for your business.

If you’re not sure what the real thing is, just ask

Other people have more than likely walked your path in some fashion. There is no harm in asking and you might get good advice and information. Do not hesitate to at least reach out to others for suggestions and an objective look at what you are trying to achieve. I’ve reached out to a handful of experts on platform product management. While not everyone can reply overall, I have received quality responses from people more than willing to share at least some thoughts on suggestions and improvements. I have also managed to have light consultations with experts in the field on topics like team topologies and chaos engineering simply by asking.

Ask! At worst you will get silence, or a decline, or advice irrelevant to your situation but at least it is something.