How I'm fighting software bloat at FM Dashboard.
Software bloat turns good software into a mess and makes developers hate their jobs. This is what we are doing about it.
I started FM Dashboard because I wanted to be the antidote to bloated, complicated, maintenance software. I was intoxicated with 37 Signals and The Lean Startup philosophies. It started small and simple. We asked our customers what they wanted, and only built those things.
We built a reputation for being the helpful software company that doesn’t tell its customers “No,” to things the big companies were unwilling to do.
I don’t want to lose that reputation, but I also don’t want our beautiful, speedy software to turn into the thing I originally set out to displace.
Which is why we needed some rules to make sure we have the best of both worlds.
We started adhering to these ideas at the beginning of the year, and I am happy with the results. Here they are, and feel free to use what you like.
"Not yet," policy.
We will accept any and all customer feature requests. But, we do not react to customer requests.
All new requests are vetted through the following criteria:
1. They must be directly tied to a major customer initiative.
2. They must be based on a proven and vetted customer process.
3. They must be helpful to all (or most) customers.
Six-week development cycles.
Will commit to 8, six-week development cycles each year. This is 2 cycles per quarter with some time in between for planning and review.
Six-week cycles break down as follows:
Week 1: Scope development and mockups.
Week 2: Front end design.
Weeks 3-4: Development.
Week 5: Quality assurance and refinement.
Week 6: Documentation, announcements, and rollout.
50/50 rule for developers.
50% of developers time should be spent on new features. The other 50% should be spend on bugs, refinement, refactoring, and speeding up the application.
So, we should not commit to any feature product that will take up more than 50% of a week's work.
Start with the slowest pages and refine them according the refinement algorithm.
Refinement algorithm. (I stole this idea from SpaceX.)
The current application and new features must meet the following refinement requirements in order to keep FM Dashboard lightest, snappiest, and easiest-to-use maintenance platform in the industry:
1. Question every requirement.
2. Delete unnecessary features and processes.
3. Make it as simple as possible.
4. Make it obvious to layperson.
5. Make it searchable.
6. Make it configurable.
7. Make every page load in less than 0.3 seconds.
I want FM Dashboard to be the simplest, yet most configurable maintenance and environmental compliance software in the industry. That can't happen if we are not focused and strategic about how we build new features.
It’s so easy to react to what’s coming at you and forget about what you originally set out to do.
What are you reacting to?
Take some time and think about how you do things compared to how you want to do things. You don’t have to have rigid processes (I hate them), but I think you are dragging around unnecessary weight if you don’t have some guidelines about what you say yes and no to.
Stuff to check out.
Die with Zero: A friend recommended this book to me, and I really love the message. There is less stuff we can do the older we get, so enjoy your money now by having great experiences. You can’t take any of it with you.
Elon Musk: Love him or hate him (I’m indifferent), there is a lot to learn about one of the most influential people of our time. It’s funny, most of the bad reviews about this book are really bad reviews of the man himself. Walter Isaacson did an amazing job of giving a 360 degree portrait. Each chapter reads like a short vignette which makes this giant book more digestible.