I attended GopherCon India 2016 last week and it was a great learning experience for me. One of the talks in the conference was on Minio by their CEO, AB Periasamy. This blog post is not about Minio, which by the way makes a fantastic, simple to install and run “Distributed Object Storage Server”. This post is more about one comment that he made towards the end in his talk that has been constantly ringing in my head since that day and I thought it best to put it down.
AB mentioned that Minio is an Open Source project and contributors are most welcome. But then he made a statement that went something like this : “I will be more than happy to get contributions to the project that tell us what we should remove V/S what additions we should do”. That statement does resonate with the Go community and especially the core Go Language team that has kept the language small, simple yet modern, powerful and easy to use. And I believe their design discussions might be more around what to keep out of the language v/s adding to the language and its core packages.
AB’s statement is something that I believe I should have been doing more with lots of software that I have written over the years. I can think of tons of features that we added after hours of discussions, hours of development which actually no one ever used, had low impact or never really went anywhere. Whether those options existed in our software was something that most users probably never even knew. Or to put it more bluntly, “did not even care about”.
I believe the time has come for more of our software to be simple, to have less options and for it to just work with minimal configuration or even smart assumptions in the code, that almost give it a brain of its own for the problem that the software is trying to address. After having developed software for 20 years, frankly I am getting tired of not being able to put some software to immediate use due to complex setup requirements, esoteric switches and what more. It has to just work and for that removing features from your product is one way of looking at it. Maybe even from existing systems!
Like my former editor at ProgrammableWeb, Adam DuVander, from whom I first learnt the term “TTFHW”, which stands for “Time To First Hello World” – I think it is more relevant today and the more quickly a developer can setup your stuff and get going with a version of Hello World for your software, the better off everyone will be. And thinking in terms of “Removing Features” could be one of your guiding principles.