It depends on the perspective. Re-usability in code can be created by doing more than one thing with the same objects (a good thing, imo, as long as you don’t try to Swiss Army knife it).

From a user perspective however, I feel it can be overwhelming to give too many options at once.

True! Coding cleanly is an exercise in semantics. Find the right words, and you find the right level of abstraction.

Truth.

So true. Yesterday I posted a small rant on Twitter:

E-commerce sucks because everyone thinks they will launch another store on the same platform and make more green without much effort.

Mouthful and not as generic as this realization ;) but hey, I thought I’d share. :)

This is why I try and code with loose coupling and high cohesion. Which basically means that one module doesn’t affect another one and yet they are allowed to work together.

The separation of model, view and controller in most frameworks is an excellent example of a highly cohesive system with loose coupling. It’s understanding high level concepts like loose coupling and high cohesion which separates good programers from great ones.

You can read more about it here: http://c2.com/cgi/wiki?CouplingAndCohesion

Sounds like a great way to describe the Single Responsibility Principle.

I think this quote (and often 37s in general) use the word complex in an interesting fashion. I think complexity is actually a good thing, and that more complex structures are more adaptive to changing situations. They are more agile and on this scale, better.

This is separate to ‘complicated’. Complicated to me means there is waste and unnecessary stuff in the system.

I think it’s safe to say we both like the concept of ‘simple’, because that is when you spend less time learning how to use the tool and more time actually using it.

I have been seeing a pattern lately where over time a product/person/idea/understanding goes through a complicated phase where you explore lots of things without knowing much, but you are learning lots. Then as you learn about the moving parts that actually matter you create a more complex(adaptive) structure that is actually much simpler (in form) than the original. So the simple structure is actually more complex, but it has evolved from the complicated (and less complex) structure where it began.

Does any of that make sense?

Software engineers love abstractions. A good sense for abstraction is a prerequisite for a good programmer. What is very helpful in mastering software architecture and programming issues, becomes a burden when it comes to product design.

The usual software programmer ( slash product manager) starts out to create a piece of software for a very particular thing. But through his sense for abstraction, he soon sees other things that could be solved with his software too. Because he loves a good piece of abstraction, he changes the product design. The product goes from doing one thing to doing two things. Any programmer seeing the abstraction is happy with the product, any customer he does not, is not happy with the product.

Bottom line. It is hard for us to accept that a product is better doing just one thing instead of two.

The rest of the complexity comes from having three things do what could of been done by one.

Totally agree. Almost every bad feature I’ve seen in our projects has been because of trying to make some feature do too many things.

@James: Actually, it makes perfect sense for code, too.

It even has a name: the Single Responsibility Principle. The best function should do exactly one thing, and do it right. A single class should be responsible for only one thing (i.e. managing an object in a certain way). It should have only one reason to change.

It makes the code easier to follow, understand, change and test.

Polymorphism applied in a sensible fashion makes things less complicated, not more complicated. There’s plenty of situations where one thing doing two things makes a bunch of sense (operator overloading, for instance).

I read a fairly cool article about how The Rolling Stones work on a song from start to finish. When they first come out of the studio with a rough mix in hand, it’s a really “full” sound; all sorts of overdubbing, layers and layers of vocals, etc. It’s usually so full that it just sounds like a bunch of mud. Piece by piece the engineers strip away layers until they’re left with the bare essence of the Stones. They compared it to carving a block of wood, they just keep chipping away at it until it’s as minimal as possible while still retaining the original intent. Until it’s been carved down to it’s most minimal form, it’s just a block of wood, not a sculpture.

So much complexity in software comes from not thinking it through properly to begin with or changing your mind half way though.

Overcomplexity is just intermediate state before you get one beautiful and really simple thing that does everything. So, if you decide to generalize something, don’t let complexity to stop you in the middle.

Two thoughts:

1. Inheritance breaks encapsulation. And vice-versa.

2. “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.” -Antoine De Saint-Exupery

Do you intend to translate Highrise as well?