The architecture of happiness

The software architecture uses a notion “dependencies”. Say, if you want your application to play the music, it should require the module sound.

If that module is not available or misbehaves, two outcomes are possible:

  • the app completely crashes, or
  • the app continues working (of course, it won’t play music).

The first option is usually bad (unless the app is a music player 🙂 ). It means that components of your app are coupled too tight. So if one component fails, it drowns other ones and eventually the whole app.

The second architecture is preferable. For instance, you don’t hear the sound of disappearing lines whilst playing Tetris. That’s not good, but you keep playing the game!
Moreover, the broken sound component could be replace with another one. Or or with another ‘notifier’, like flashing background.

The geek-guy says that it’s almost impossible to keep all the components loose coupled.
Well, the more less, the merrier. The looser components are, the more flexible and fail-safe the app is.

This principle is also spread on how you design your own life:

  • the more things or people or say ‘components’ your happiness requires, the harder is to meet all these conditions;
  • if your happiness requires irreplaceable components, you’ll be really fucked up when at least one of ’em breaks.
    Karma is bitch ©, sometimes it happens.

So think what you want.
Think how you want it be done.
Design and develop your happiness.
And enjoy it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s