DevExpress Newsletter 21: Message from the CTO

With 20 newsletters under our belt, we decided to try out something new for issue 21: having the Message from the CTO as a video you can watch instead. It also helped that the topic or theme I was discussing easily lent itself to a visual metaphor and our videographer, Jeff, had a field day in so translating it. (Click on the image to be directed to our video site, tv.devexpress.com.)

I've had a couple of requests for the text of the Message as well — sometimes it's hard to watch at work, or just frowned upon — so here it is:

Thinking in black and white can be bad

I've done this myself in the past. I'll hit a problem, decide on a solution, and suddenly that solution is the correct one forevermore. My solution has entered the black-and-white zone, the programmer's binary view of reality, zero or one, right or wrong.

Unfortunately, reality is more like the Twilight Zone. There's shades of grey everywhere. Heck, even on the web there are 254 levels of grey between black and white.

You'd think I'd know this from my own interest: algorithms and data structures. Take for example that most ubiquitous of structures: the map or the associative array. It stores a bunch of name-value pairs in such a way that finding any of them by name takes place in constant time. That's right: despite the number of items in the collection a search for any one of them will be the same. An identical result goes for adding a new name-value pair to the collection or removing an existing one.

It's an extremely strong concept, which is why the underlying structure, a hash table, is used all over the place. Seems pretty black and white, no?

Unfortunately, what I just said is not quite the whole truth. The problem with hash tables is that their efficiency is actually quoted as an *amortized* value: over very many insertions, deletions, and searches, the average time per operation is constant. However, in certain situations, namely when the hash table has to be grown to lower its load factor, the time to complete an insertion will be proportional to the total number of items in the table. The application will suffer a hiccough.

In other words, the run-time efficiency of a hash table (and hence a map or an associative array) is not black and white. It's a light grey. You may decide that the greyness is light enough that you don't care, or you may decide that you'd prefer using something else that has an even lighter grey, but either way you cannot view it in black and white.

Every time we write code, we're encountering scenarios for which we have to make a decision on how to proceed. These decisions are made based on the reality we see, on the experience we have, on the understanding we perceive. They aren't black and white but are some shade of grey, perhaps darker, perhaps lighter. If we could spend more time on the research, we could perhaps lighten or darken the grey.

In other words, we should views our decisions (and other people's decisions) as being better or worse, rather than absolute right or wrong. Cross with me into the Twilight Zone.

I was talking to a friend recently about this topic, and he said it is, in a way, the core of an agile development methodology. Things are never black and white there: you try something out, if it works, great, if it doesn't, equally great, since you can try something else out. Of course you then get to polish your initial design and implementation and lighten or darken the grey.

Free DevExpress Products - Get Your Copy Today