The Butt Ugly Weblog

I've heard lately people complaining how much stuff they have. It might be a common problem in my age group - you just accumulate things over time, but you never really need to throw them away because you keep moving to a bigger apartment, where the stuff can always be hidden. Looking at the amount of things we have (fairly regular amount of stuff for any six-person family - except, of course, there are only three of us) it really makes me wonder whether I need all of that.

Now, clothes are fairly easy to keep from multiplicating - at least for me - but I've got a ton of stuff which just simply isn't really necessary, yet too useful to throw away. But it seems that there never is time nor the will to start triaging things.

So here's an idea - and I'd like to hear if anyone has experiences with something like this before: a recycling party. You gather a lot of friends (preferably with some inkling of good taste) and let them do the sorting. All things go to four big boxes: "Keep & display", "Keep & hide", "Recycle" and "Throw away". Keep&Display are things which look nice and are worth keeping, Keep&Hide are things which have particular value but aren't used often (or are hideous but precious), the Recycle bin is for those things which are good but not necessary, and the last one is obviously for things which just deserve death.

The party host offers food & drinks, while everyone has fun rummaging through the host's closets and arguing about the things. Finally, the Recycle-bin is taken to a recycling center whereas the garbage is ceremoniously thrown away; and kept items are placed in their proper places.

Might work well as a part of move. Don't know. Let me know if anyone has tried something like this.

I've seen software fail. And inevitably, someone asks the question "why don't they test these things?"

But of course they are tested. Many companies spend incredible amounts of time and effort to test their wares before they ship.

The interesting truth is that testing is not real life. The old war truth says "no plan survives contact with the enemy", and role-players might say "no scenario survives contact with the players". Real life is just so full of variety, inventive people, even physical limits like dirt and grit that no amount of testing can truly represent real life.

Martial artists know that practice will help. But a real situation is always different. Practice too little and you're overconfident. Practice the wrong things and you're too rigid to adapt. Same with software testing.

When software ships, it goes to a battlefield. Many times it survives. But many times it does not.

Well, I finally was able to see the much-talked-about movie, Avatar. Those who follow my Twitter stream know that I've had some challenges with it.

Anyhow - and I fully realize I'm very badly late talking about it - I have to admit I was impressed. They're not paying Richard Taylor enough money, no matter how much they're paying. Such level of detail in the design is just insane and gorgeous at the same time (like good design often is).

I'm not going to talk about the plot - it's fairly straightforward and if you've seen fantasy flicks before, you can pretty much guess what happens. But the feeling of being there is tangible. It crosses the thin line between unbelievable and possible, and doesn't require a lot of suspension of disbelief to work. And that's so incredibly important, both in fiction and real life.

(The only thing that bothers me is the thought that the Na'vi all look like blue Gollums. And once that thought enters your head, it's difficult to dislodge.)

(And I loved the alien vs forklift -reference.)

Here's something else I've been ranting about for a while now: A lot of about Internet of Things is fundamentally flawed, because it assumes that things have something interesting to say to each other. But I still can't figure out what my toaster would like to tell my oven that would be so important that I would pay for it. The internet works because there are people in it; I'm not sure it becomes at all better if there are things in it too.

Perhaps it's because we geeks like to anthropomorphise our precious things - yes, sometimes it feels like the computer has its own will. So we think that wouldn't it be wonderful if all the stuff we owned could talk to each other. It's as if we had a family. :-P

Of course communication is the alpha and omega of all intelligence, so perhaps it's just us trying to build our replacements. But knowing the difficulties we have finding meaningful things to tell one another, do we really believe that quantity wins over quality by enabling everything to be connected to everything else?

Wouldn't it make sense to figure out first what our things might want to say?

Many geeks love boxes. And once you got that magic title, "Architect", in your job description you start loving them even more, 'cos that's what you get to do all day. It's really nice to design scalable architectures and think about how data flows between modules and how to tweak the system and argue and finally commandeer a large army of coders who build your dream. It's fun!

But there's a small problem. Quite often you also need to design an API - an interface through which other people can use the wonderful framework you designed. And here lies a danger: if you design your API after the architecture design is done, your API will reflect the internal design of the system. And that, in turn, means that if you change your architecture, you will have to change your API as well. Which breaks the promise you've given to the people who are accessing your system through the API. Unlike humans, who can figure out if a button has changed place on an HTML page, computers get really iffy when it comes to argument ordering and types. In a word, the API becomes brittle.

So the right thing to do is to design the API first, and then match the architecture accordingly. This way the API is not dependent on changes you do under the hood. This is much harder to do, and much less fun, but it will create you a better system in the end - because no matter how beautiful a thing you've designed, if it's a pain to use, it won't get used.

Love the boxes. But not too much.