So @bwertz posted on the Version One Ventures that one should s.i.m.p.l.i.f.y.
I couldn't agree more, after all one of my email signatures is a quote from Alan Perlis about it. What does bother me a little (hence this post) is the quote that accompanies his post:
That's just bullshit, in the sense that there's absolutely nothing modern about the difficulty of simplifying. Yes it's hard. And yes it's what one needs to aim for. And it's much, much, much harder than its opposite.
The core of the issue is this: it's much easier to add than to remove.
When adding, you don't care about what was, you just look ahead and think that you're doing good by creating. That's very good, in general. Where it starts becoming really bad is when you add so much that the whole system collapses from its inwards gravitational pull. In other words, it calcifies because there's so much going on that one either doesn't understand how it works or is afraid of doing anything to upset it.
This applies to everything, including interfaces: when you don't know how the users are interacting with your site, you are fearful of change. So you spend resources tracking them. Then you get too much data. Then you have to sift through that data to truly understand what matters. Finally you can take action. And that's assuming your site hasn't grown so big with so much spaghetti code that you need to refactor (i.e. simplify -- that word again -- the code) before doing anything.
For entrepreneurs, my advice would be: don't let anything grow too big that it becomes a huge undertaking to bring it down to a manageable size. Decouple as much as you can. Define clearly the communication protocols between those small pieces. That's what matters in the end: how your people communicate within the organization, how your users communicate with you (web clicks, apps, etc...), how your system modules communicate with each others.
In one word: APIs
What was Alan Perlis' quote that I alluded to at the top of the post? Glad you asked:
I couldn't agree more, after all one of my email signatures is a quote from Alan Perlis about it. What does bother me a little (hence this post) is the quote that accompanies his post:
“A modern paradox is that it’s simpler to create complex interfaces because it’s so complex to simplify them.” (Pär Almqvist)
That's just bullshit, in the sense that there's absolutely nothing modern about the difficulty of simplifying. Yes it's hard. And yes it's what one needs to aim for. And it's much, much, much harder than its opposite.
The core of the issue is this: it's much easier to add than to remove.
When adding, you don't care about what was, you just look ahead and think that you're doing good by creating. That's very good, in general. Where it starts becoming really bad is when you add so much that the whole system collapses from its inwards gravitational pull. In other words, it calcifies because there's so much going on that one either doesn't understand how it works or is afraid of doing anything to upset it.
This applies to everything, including interfaces: when you don't know how the users are interacting with your site, you are fearful of change. So you spend resources tracking them. Then you get too much data. Then you have to sift through that data to truly understand what matters. Finally you can take action. And that's assuming your site hasn't grown so big with so much spaghetti code that you need to refactor (i.e. simplify -- that word again -- the code) before doing anything.
For entrepreneurs, my advice would be: don't let anything grow too big that it becomes a huge undertaking to bring it down to a manageable size. Decouple as much as you can. Define clearly the communication protocols between those small pieces. That's what matters in the end: how your people communicate within the organization, how your users communicate with you (web clicks, apps, etc...), how your system modules communicate with each others.
In one word: APIs
What was Alan Perlis' quote that I alluded to at the top of the post? Glad you asked:
"Fools ignore complexity; pragmatists suffer it; experts avoid it; geniuses remove it." - Alan Perlis
