July 2019 – Sledgeworx Software

Rework book review

I read REWORK by Jason Fried and David Heinemeier Hansson the founders of basecamp. The book is a series of short 200-500 word ‘sections’ that elaborate on a point. No wasted space or pages full of empty words where the point has already been made. As a result the book flows incredibly well. It is a quick and light read. The ideas in the book are commonsense lessons learned from running a successful small business. A lot of the ideas are shared with agile and the ‘lean startup’ schools of thought. But REWORK is a superior book to the ‘The Lean Startup’. Comparing the two books its clear Hansson and Fried understand the space better.

A few points from the book stuck with me so I will go over them.

Don’t write it down

The top customer complaints will come up so often you will never be able to forget them. You shouldn’t need a long list of customer issues, if you are listening to your customers regularly you won’t be able to ignore the top issues. If you get ten customer complaints each day and five of them are the same issue, you know what to work on.

The myth of the overnight sensation

“And on the rare occasion that instant success does come along, it usually doesn’t last —there’s no foundation there to support it.” — page 196.

I liked this phrasing of the overnight sensation. These days social media constantly spams us with success stories and lavish lifestyles we could be living. But if you are relying on luck to succeed it might not come a second time, and then you don’t have anything left.

Don’t scar on the first cut

Policies are only meant for situations that come up over and over again. You create a policy to make a common problem easier to solve. Without a policy you have to rely on judgement and escalating up the chain of command. That is expensive, but having a policy takes all the flexibility out of the situation. Don’t create policies unless its obvious that the issue is common and thinking about it is wasting people’s limited time.

Four letter words

Don’t use the words “Easy”, “Fast”, etc. Things are rarely done fast or easily. If they could be we would have done it already. Using those words implies things that we probably don’t know.

Inspiration is perishable

If you want to do something, you have got to do it now. You can’t do it later because you won’t be inspired to do it later.

Looking from the inside out.

I started my software engineering career in consulting. We did application development for large companies that did not have enough engineers on staff to get their projects done. We had a Statement of Work and a list of stories to do. Then we handed over the code and went back to our nice benches. Consulting was a big thing, we had executives, million dollar contracts, etc. I often ran in situations where I was spinning my wheels waiting for people to make decisions or to sell another contract. We ran some internal projects, but they were always an after thought.

Now I work in a product company somewhat similar to the companies we used to consult with. We have what is essentially an unlimited amount of work. There isn’t any time for anyone to be ‘on the bench’. We have enough work for double our headcount. I have 5 real, valuable projects that I want to work on. It is just an issue of prioritizing and getting things done. But the thing is, a lot of stuff is falling through the cracks.

We don’t have time to do everything, but we do need a lot of things improved.

We could use an expert on CI/CD pipelines to come in for a month and upgrade our pipeline. We could use a java performance expert to come in and help us cut end user latency by 50%. We could use a consultant to help us break up the monolith. We have opportunities for a dozen consultants, but from the outside you don’t see the internal workings of the product company. You can’t see that we have hundreds of ways to make the product better and no where near enough work to do it.

Solutions Pyramid

In College Computer Science Majors worry a lot about the optimal solution to algorithmic problems. What is the optimal solution? Is it in logarithmic or polynomial time? Did you pass or fail the test? My Algorithms class had a group class competition to see which team could find the best solution to a particular algorithmic problem.

Then when they start looking for jobs they run into whiteboarding interviews where they are supposed to find the optimal solution in 50 minutes so we have time for questions.

But once you enter the workforce, no one cares about the optimal solution anymore. If you look at the Solutions pyramid above there only one optimal solution. But right underneath there are 10 excellent solutions and a 100 good solutions. In the corporate world a good solution is an A grade, and an acceptable solution is passing. Typically as long as a enterprise software project avoids clearly ‘bad’ algorithms it will probably meet its throughput and latency goals.

When your team has found multiple approaches to solving a problem and can’t seem to agree on the ‘right’ one. Ask yourself whether any of the solutions are in a higher level of the pyramid than the others. Don’t try to find the best solution, try to get a solution from the highest level of the pyramid implemented. And if all the proposed solutions are from the same level of the pyramid, sit back and relax, it doesn’t matter who wins.

You should not “build it here” even if your core competency IS Software.

Some companies try to avoid developing software that doesn’t directly contribute to making money. Other companies do the opposite and try to only use internal software. Falling into the “not invented here” trap.

Large software companies fall into a different failure case where they build large massively integrated internal development platforms.

At the beginning these companies were solving a problem that had no existing solution and they correctly chose to create internal solutions.

But it has been a long time. You should not be maintaining your own containerization system anymore. Use Docker.

But for a big tech company moving to docker could be a five year effort costing millions. It is easier to keep the old system.

That large tech company gradually becomes trapped by internal software, that the rest of the industry has never heard of. As the company’s internal tech stack drifts away from the rest of the industry employees pay less attention to the mainstream.

Eventually the company loses perspective on what they are missing. The people who have worked there the longest who have the most power to improve things think the internal software is better.

These companies are big enough that they have internal developer conference where employees can learn about the latest in internal tooling.

Today most of the components of these stacks are worse than the industry mainstream alternative. But there is no upgrade path on the horizon.