Spilling a few beans

I think enough time has passed, don't you? I've been hinting to what I'm up to these days, but I've been rather careful about spilling the beans, I guess because, well, it's a brand new adventure and every storyteller should get their story together well before writing it down. I'm keen to talk about this stuff, though, because it is wickedly cool and I'm keen to not only do it, but to talk about it and involve more people in it as well.

As you probably saw from my last post I'm currently in India, and yes, my new employer is an Indian company, but I work from home (in gorgeous Kiama, Australia, 1.5 hours south of Sydney) and travel to India every so often (4-5 times a year as a rough guide). We work over the Internet, including video conferencing and remote controlling and the like, and as such is a new interesting challenge for me to be somewhat isolated from the smiles and sideways nods and the tacit knowledge floating down the hallways of our headquarters in Mumbai. I've got plenty of ideas of how to deal with that, so we'll see how it goes.

My company is Free Systems Technology Labs, a nifty medium-sized IT development company with main offices in Mumbai (from where I'm writing this) and most R&D and development in Bangalore (where I've been the last week), which is a daughter-company of another company mostly known for more hardware orientated stuff, like computer building, server hosting and various gadgets, but they only have a number of software outlets as well. I'll be working with anything from planning to execution, and mostly in the domain of Topic Maps. Yes, the very thing I've been talking about for the last 9 years is now going to be my main concern as opposed to secondary or third (or some periods not at all) at the whims of other jobs, and I can't even begin to tell you how excited the prospect of that is to me; I believe in the ideals and practice of Topic Maps so strongly, and it's going to be good for my soul to pour it into something as cool as what we're going to do. (More on that later) The guys here also happen to share many of my own ideals (open-source, development methods, goals, community and societal building, and so much more), and they've been spoiling me. I'll miss the tea, that's for sure.

I became part of this through a weird mix of happenstance, but mostly because the people involved here have been, put simply, a fantastic bunch, in terms of technical brilliance, sincerity and honesty, and in convincing me that I should join (they obviously think I'm good for something :). I've been with the company now almost three months where the first two months are more like a warm-up, but it's been a very good ride so far.

But I need to talk about something that's been on my mind ever since they got in touch with me last year, and that's prejudice. The world is full of it, and I entered this adventure with a slight degree of scepticism. No, not the bad kind, but a certain carefulness, because, you know, they're Indians, and Indians got their mouth full of rice, and you're not getting any! (A joke I got from an Indian friend, so that makes it alright, yeah? :) Not only did they have to convince me, but also my wife. "Honey, how about I drop my great-paying safe cushy job in one of the richest countries in the world, and rather work for strangers from a strange land full of poverty and strong smells and interesting hairdoos, and do it over internet?" Yeah, she was keen, as you can imagine.

You can't work for Indians! They are supposed to work for us!

Sure. But they kept talking with me, flew me to Belgium (they own half of a company there) and were not only completely honest with me but simply blew me away with their knowledge, seriousness, and most importantly their friendliness and openness. Me and the wife thought long and hard about it (probably longer and harder than my company wanted me to :), and here we are.

Everything I knew about India was either heavily adjusted, or simply wrong, but I've seriously enjoyed being corrected. I've embraced everything that's been thrown at me, including very hot food, weird drinks, amazingly crazy traffic and the sweltering heat, the chaos, the smells, the meetings and the way they interact, the attitudes and the values. I think the tagline "Incredible India" is truer than they think.

Ok, that's enough for a first intro, now I have to get to bed. I'm flying home tomorrow and I'm looking forward to seeing the wife and kids again (Lilje just won an award for her art at school, so I'm mighty proud as well), and we'll be spending the weekend together, and on sunday celebrate Norways national day in Sydney.

And then, a little bit later, I'll tell you about the wickedly cool stuff we're going to do with Topic Maps.

Designed by stupidity, built by ignorance, approved by incompetence

Note: I wrote this piece back in 2006, and just scrubbed it up. Enjoy.

"Stupidity" from Wordnet:

- a poor ability to understand or to profit from experience
- a stupid mistake

Design is the process of taking a set of constraints, and make something out of it. These constraints can be a number of things, from trivial wishes to strict rules. Sometimes it's about a color, other times about functionality, and then again about its basic concept, maybe a marketing angle or perhaps changing some stuck process. It could be anything.

However, a lot of the time you're left with that compelling feeling of "Qua?" while reading through your constraints; he wants me to do what!? They think we should put in that!? She likes what color!? marketing wants to sell this to whom!?

One definition of something stupid is when you can't see what is obvious to others. Sometimes this can have as much to do with your definition of a problem as a personal viewpoint, but quite often this "stupidity" certainly points to things we overlook or just plainly can't see but what we certainly should address.

Good design is about seeing things from as many angles as possible, and find the best possible compromise between them.

"Ignorance" from Wikipedia:

Ignorance is a lack of knowledge, or a willful lack of desire to improve the efficiency, merit, effectiveness or usefulness of one's actions. Ignorance is also a "state of being ignorant" or unaware (not knowing).

Building systems (applications, processes, buildings, societies, anything) is a complicated thing, relying as much on the goodness of the designers as the intelligence and skill of the builders.

Some people willfully ignore things. Maybe they feel they know enough, or maybe there are fears involved. Whatever the case, you see it all the time; people walking on a red light, smoking where not allowed, slightly speeding while driving, daydreaming while in meetings, outsourcing for the sake of instant capital gains, eating unhealthy food, not practicing what you preach, ignoring global warming signs, keep investing in oil consumerates, draw red buttons for safe functionality, never test your assertions and so on. The list is endless. People ignore things because of the normally low frequencies of events.

When builders ignore the time effects on setting concrete and make a too thin layer for your foundation, a layer without skeleton, and a few years down the track the building may simply collapse. If you don't fully understand the difference between alcohol and methanol it just might be the difference between life and death. If you ignore warning signs, whole cities might be flooded, or buildings blown up, or kids will use guns on other kids.

Good design is to preempt what warning signals has taught us.

"Incompetence" from Wikipedia:

Incompetence is the condition of a person who is unable to properly perform his assigned duty. Incompetence is the essential ingredient of the Peter Principle, which states that in a hierarchical organization, every employee tends to evolve through promotions towards a position in which he is incompetent.

Approving systems tends to happen after it has been built as opposed to something that happens in parallel. That being a flawed strategy from the beginning I guess is hard to overlook, but let's focus more on the common way we approve the systems we design and build.

First, approval is mostly a binary thing, no matter how much history teaches us otherwise. If it still is running and does what it says on the tin, that's considered a success, even if you don't fully understand why it was written on the tin, nor what the tin was supposed to contain or should contain.

Then there's approving things because your job is to approve things instead of guiding things or cancelling crap things. If you and your team spent months on a project you're not going to be self-reflective enough to call yourself out in public.

Good design is to allow for failure.

To shift things around

In order for us to shift things around when they are going pear-shaped (hang on, what's wrong with pear-shaped? I love pears, and I love pear-shaped women, what gives?) we must focus a bit harder on design from the middle principle. I'm a bit tired of both top-down (we know upfront all there is to know) and bottom-up (we know only know so little) approaches. Could we please start somewhere in the middle, and work ourselves out from there? Thanks.