Software Updates are a liability for customers. Imagine a business, say a restaurant, which uses some POS (point of sale) software to run its business. Every time the software is updated the business’s employees have to relearn some of the software. That costs money. They would rather buy software that never needs to be updated.
You might say “Well, what if there are security vulnerabilities”. Fixing those vulnerabilities still costs money. Customers will have to update their software which costs money even if there is no functional change. Its essentially saying, “Hey, Customers, we shipped you a defective product, please spend money to get the update which fixes this vulnerability”.
Many companies have moved to SAAS (software as a service) which solves the problem of getting customers to install updates by forcing them to. Now, instead of customers constantly digging in their heels and refusing to update anything, we can ship them updates constantly.
Customers hate software updates. They are slow, buttons move around, and people lose the fluid mastery that they painstakingly learned. Software should empower customers, every time you ship an update that breaks fluid mastery, customers are kicked off of Olympus.
I was surfing reddit this week and I saw a great comment from u/Swordbow.
“Thus as the obligation stretches across time, the cash flow must stretch across time.”
–Quote from u/Swordbow on reddit
Computer software isn’t like classical machinery in that bugs and vulnerabilities can be discovered after release that destroy the security of the application. A year after release you might have to perform an urgent patch to protect your customers from hacking. If your company goes bankrupt during that year, customers are in a very bad situation. Software needs to be maintained and unlike typical machinery it has to be maintained by the creators not the end users.
Selling new releases of software is hard. Programs can be copied at zero marginal cost and don’t really wear out. Getting customers to buy a new version every year is a lot harder than getting customers to pay a monthly subscription. With Software as a Service instead of getting paid when you sell a new version of your software, you get paid as long as customers use your software. And you don’t have to worry about dealing with upgrades.
Companies can reduce consumer surplus by switching to a SAAS model that requires customers to pay as long as they use the software. With SAAS all customers pay for every update.
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.
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.
Following on my earlier post “How much is turnover costing your company?” this post is about how much using non-standard technology stacks costs your company. Lets say company A is high performance company with a custom functional programming stack that uses Haskell and Miso for development. Company A doesn’t ship a lot of bugs to production, in fact they run CI/CD with deployments to prod everyday. Their SAAS product is one of the best in the industry and is growing at a good rate.
Now Company A has a competitor in the form of Company B. In this case B does stand for Boring. Company B offers a SAAS product that is almost identical to the one Company A sells but Company B’s has more bugs because they use Java. In fact Company B uses Java with Spring Boot and ReactJS. Both Company A and Company B started in 2018 when React was already mainstream. Company B also uses CI/CD deployments but they can only deploy to production once a week because there are so many bugs. Company B also hired a QA Engineer to help support the pipeline because of an embarrassing outage that CompanyA used in a humiliating Ad.
In January 2019 both companies raise a round of founding for 10 million dollars. The mandate from the VCs is to 10x the company in size and destroy the competition. Both companies need to start hiring fast. Throughout 2019 CompanyA has an advantage, there are a bunch of passionate Haskell engineers that want to work on their product. Both Company A and B reach their growth targets and hit 100 engineers that year.
Fortunately, things go well for both companies in 2020. The market is growing and revenues are increasing. The VCs call for more growth. Now we want to grow engineering to 500 engineers.
Now Company A has a problem. They already hired all the passionate Haskell+Miso engineers they could find. Any new engineers will take 12 months to train on their technology stack. CompanyB doesn’t have this problem everyone still remembers how ReactJS and Spring Boot work even though they are no longer the top technologies. Company B only needs 6 months to train a new engineer on their technology stack.
Lets run the numbers. How much is it going to cost to onboard 400 new engineers for each company?
We will keep our 2 year average tenure estimate and use 12 months of onboarding for company A. Each engineer has a total cost of 200k including salary, equity, benefits, taxes and insurance.
Each engineer is going to cost around 100k to onboard at Company A.
Each engineer is going to cost about 50k to onboard at Company B.
Now the next question, how long will it take each company to get all 400 new engineers fully operational?
My assumption is that it takes 1 fully onboarded engineer to train a new engineer. Each company has 100 engineers to start so at the beginning the first 100 engineers will train the next 100. Then each company will have 200 engineers to train the next 200. Then things calm down a little and we have 400 engineers to train the last 100.
After 12 months Company B has double the trained engineers Company A has. At 18 months Company B is finished onboarding and can have all 500 engineers focus on the product. Company A won’t catch up for another 18 months.
Most people will agree that Company A’s functional programming stack is not going to make up for the extra engineer years that Company B has at this point.
