blogging, internet, software, software development, web authoring

Matt Mullenweg’s less-is-better approach to software quality

2 Comments

Interview with Matt Mullenweg in the Guardian today. This was done at the Future of Web Apps conference. I enjoyed meeting him. He is open and articulate. I had not appreciated until now that WordPress.com took the opposite decision from Google over the issue of being blocked in countries such as China which are less permissive than the USA about what can be published. He found out that by blocking certain words and tracking certain people the site could be unblocked:

Google had the same decision, and they decided that being there was less evil than not being there, ultimately. For us, we decided that being there under those circumstances isn’t worth it. We’d rather not be there.

A blogging site is not the same as a search engine. It’s arguable that both sites made the right decision. Not easy.

I was also struck by Mullenweg’s espousal of an Apple-like minimalism in software design. He says WordPress has too many options. He was particularly critical of Open Office:

If you open up Open Office, look at the preference screen, there are like 30 or 40 pages of preferences. Stuff that you and I will never care about and should never care about.

I accept the main premise – software should just work. I understand the further implicit argument, that adding options tends to diminish software quality, by adding complexity to the code. But it would be interesting to analyze some of the options in, say, Open Office, and find out why they are there and who is using them. Is having all these options tucked away really a bad thing, or this really more about user interface design?

2 thoughts on “Matt Mullenweg’s less-is-better approach to software quality”

  1. Is having all these options tucked away really a bad thing, or this really more about user interface design?

    Since there has to be code underlying all those options, and some of those options will require redrawing of pages and layouts and so on, having more options must lead to more (a) bloat and (b) bugs, unless you have a fantastically abstracted model.

    More bloat is just annoying, because it makes the package bigger than it needs to be. It makes it harder to coordinate – does changing option 97 affect option 3? And which should be the default?

    In general, UI advances best when it goes with quantum leaps – that is, tiny ones built on what’s gone before. Think of the evolution of the iTunes interface. Open source tends to more by Cambrian evolution – there’s an explosion which is then ruthlessly culled (if anyone gets a hold of it), or else the project dies, or limps along with a huge appendix of unnecessary options & code.

    Good code and UI design has more of the intelligent design approach. In software, it’s a better path.

Comments are closed.