There was one concept from the video that I found interesting. The idea is that software that’s complicated to test can’t maintain quality.
I’ve been working on SaaS platforms every user is on the same code base. Users have the option to tailor the system to fit their needs.
This leads to many settings and options that allow the user “customize” the platform.
This never seemed unusual to me. It’s always been the norm. Only one company that I’ve worked for until now hasn’t been in this scenario.
MPJ says that adding settings and toggles in software cost more than one might think. They create a combinatorial explosion of complexity. That’s because they multiply the number of test cases for the settings affected. This is often not worth it. 95% of users don’t change settings, so the choice that you’re giving users is an illusion.
I couldn’t agree more with this viewpoint. The main problem I’m asked to solve deal with issue around software quality. I’m currently working as a software quality assurance engineer. So the quality issues brought up by complicated software is the reason why I’m employed.
I don’t feel like software needs to be complex to meet the needs of most users. Even if that means less job security for me.
So what happens when you’re building a SaaS platform? Something that should fit many different users needs.
One question you could ask is, could we solve this problem only using subtraction. I’m thinking that breaking down the system into smaller self-contained services would help. If 80% of your users have a setting one way maybe try to convince the other 20% to move also.
Lowering complexity can improve the lives of everyone on the development team.
In most cases your startup needs automated test. But remember, you can stop some complexity at the source. That would be at a product level of decision-making.
I think we follow MPJ’s suggestion. Be careful about adding settings, and always try to design around adding more.
When was the last time you changed the default settings?