Seek feedback and iterate

As I sat there in front of my screen developing the spreadsheet/tool that was to be shared with the more than hundred salespeople in the company I realised I had doubts – would this really work? Was this an improvement to what they already had? Or was it more change for the sake of change?

I honestly felt that it was a genuine improvement, but I didn’t know. And having spent so much time already getting to where I was on its development, the last thing I wanted to hear was that I was on the wrong track, and that my work would come to nought.

Also, I was in a state of flow, and getting feedback was an overhead that would break that. Did I really want that?

I got up from my seat, walked over the coffee machine and made myself a coffee while mulling over this: to get feedback or not to get feedback – that was the question.


Development’s fun – I enjoy it. Solving technical problems and shipping something useful is one of the main reasons I entered the tech/data space. But having moved into a managerial role it’s something I do less and less – development’s now a team sport, one in which I’m no longer the star.

That sense of accomplishment when something you create goes out into the wild and receives accolades is something I really miss.

If this piece of development went live, I would well get back that high.


The steaming cup of coffee in my hand relaxed me and made things a little clearer: I made a mistake of having worked on the development as long as I had without getting feedback. I should have followed the same advice I always give my team: don’t work on something for too long without getting feedback, otherwise you may just find yourself spending days or even weeks on end working on something nobody wants to use.

(Thank goodness I also always drill it into them: “Do what I say; not what I do.”)

The longer I went without feedback, the harder it was psychologically to want to seek it. But I knew I had to do it.

I personally had doubts, and this was my baby here. I gritted my teeth, got up from my seat, and started seeking feedback. Like Sun Wukong (aka Monkey King), I reluctantly travelled to collect the sutras, during which I had to bear the pain of hearing things like “it won’t work” and having my “great” ideas turn bad.

It was emotionally draining, but it had to be done.


Hard as it was, I stopped development that day. The week (and weekend!) of frantic development came up to nothing.

Still, there was something I got out of it — like they say, there are no mistakes, only learning opportunities. And for me, it was a reminder to myself to seek feedback early, and iterate.


It was ironic that it was about this time that I was reading the Lean Startup by Eric Reis, one of the pioneering books on iteration and getting feedback. I leave you with this passage that I always use to remind myself before I go too deep into a development or process rabbit hole (text in bold mine):

From the point of view of individual efficiency, working in large batches makes sense. It also has other benefits: it promotes skill building, makes it easier to hold individual contributors accountable, and, most important, allows experts to work without interruption. At least that’s the theory. Unfortunately, reality seldom works out that way.

Consider our hypothetical example. After passing thirty design drawings to engineering, the designer is free to turn his or her attention to the next project. But remember the problems that came up during the envelope stuffing exercise. What happens when engineering has questions about how the drawings are supposed to work? What if some of the drawings are unclear? What if something goes wrong when engineering attempts to use the drawings?

These problems inevitably turn into interruptions for the designer, and how those interruptions are interfering with the next large batch the designer is supposed to be working on. If the drawings need to be redone, the engineers may become idle while they wait for the rework to be completed. If the designer is not available, the engineers may have to redo the designs themselves. This is why so few products are actually built the way they are designed.

Business vs. IT

I felt like a lawyer. The call was in less than 12 hours, and I was busy preparing my case, consolidating evidence and building my story. To be honest, I wasn’t 100% behind the argument I was preparing to put across, but I didn’t really have much of a choice. I had to believe — how could I convince others if I couldn’t even convince myself?

But at the same time, I really wanted to steer clear on the “us vs. them”. Together with allies “from the other side”, we were working hard on framing it from a collaborative angle. It’d do us all no good if our discussion disintegrated into a blame game.

The situation at hand was a classic business vs. IT situation. Business says “we asked for this”, and IT says “no, you didn’t.” Whatever the case, the project deadlines weren’t going to be hit and nobody wanted to be responsible.

The funny thing is, if you asked me, I’d say no one was responsible (or that we all were). It was one of the first times we were doing anything close to what we were doing, and it was almost expected that hiccups like these were going to occur.

Requirements were defined, and IT made good on those requirements. Business was as clear as they could be on those requirements, but apparently not clear enough.  But how could they be? The project was a little too big and too fuzzy to be executed perfectly from the get-go.

Maybe a more iterative approach might have worked better, with all parties agreeing at the start that for a period of say, two or three weeks, we’d all be in a transition phase, where 70% of the requirements were met and the other 30% part of some type of agile-development, exploratory process, where things didn’t need to work perfectly but problems rectified quickly.

True, we could have spent more time thinking through and defining better requirements. But even if we spent an additional year we might not have uncovered requirements buried deep under others, the discovery of which were dependent on the implementation of the others. Would the need for a parachute have come to pass if planes hadn’t yet been invented? Would these later requirements have come to pass if the earlier ones hadn’t been implemented?

Whatever the case, this was an interesting situation to be in.

On Nerdiness, Programming, and Cooking

The extent of my nerdiness was only realized this after reading the following excerpt from the book “Decisive” by Chip Heath (I find it a really good book, by the way):

In our quest to convince you of the merits of a process, we realize we’ve been facing an uphill battle: It would be hard to find a less inspiring word in the English language than “process.” It’s like trying to get people giddy about an algorithm.

…and vehemently disagreeing with it. Because I’m inspired by process (and systems; and the like), and get giddy playing with algorithms!

Programming and Cooking

I can hardly fathom  a more exciting afternoon than one in which after hours of programming, scripting, and coding that seem to be going nowhere, with the swish of a “compile and run” magic is revealed: the completed program; website; or basic scripting routine, coming together and working like a charm.

For non-programmers who are looking and longing for a similar experience, I say look no further than your kitchen. In cooking, a similar joy can be found. Many times I’ve found myself in the kitchen preparing dishes that look nothing like what they started with.

One of my favourite “how can this be that?!” revelations can be found in one of my favourite Chinese dishes called hor fun

Especially if it’s the first time you’re trying to cook it, almost all the way through to the last couple of steps where you pour in the cornstarch solution and the egg, you’d be questioning if it’s really going to be turn out like you think it should turn out to be (before that, the dish just resembles a really sad attempt at kway teow soup).

I find it a great analog to programming. Where you start off with various ingredients that don’t appear to mix together too well, and where you’re trudging through tough periods based on nothing but faith and the hope that it’s going to work out in the end.

It’s no wonder that many computer and programming books come with titles like “Recipes” and “Cookbook”.

Creating on the iPad

Creating on the iPad… it’s just not the same as creating on the computer.

When on the iPad, I’m far more a consumer. Typing is laboured, and sharing isn’t as easy. If I see an image on Facebook or Linked In, and I want to share that with my Google+ followers, it’s not straightforward at all.

Consumption, though, is far easier. I read a lot on the iPad (it’s essentially replaced my weekly visits to the library); viewing images are a joy (whoever invented pinch-to-zoom should be knighted); and browsing through music on the Spotify app is quite the adventure.

The funny thing is that all this consumption without sharing irks me. Every time I experience something I like, I want to share that with somebody. Everybody. But because of the difficulty, I park it in my mind. I bookmark it. Tell myself, “I’ll share that later,” knowing full well it probably isn’t going to happen.

A look through my iBooks app shows pages upon pages of highlighted material and notes, all of which during the time of highlighting and noting was something I was just dying to share, but which I haven’t.

That’s why I’m bitching about it here, typing this on my MacBook Pro, with my iPad’s Spotify app providing beautiful background music.

How the iPad has changed my reading habits, and how it hasn’t

For my birthday this year, my wife gave me an iPad Air (thank you!) Unbeknownst to me, this was to radically change my reading habits.

I am–perhaps was, now with the iPad–huge fan of libraries and bookstores: the smell of age-worn books, newspapers and old people; the sounds of teenagers and their gossipy tongues; and the pitter-patter thumping of little feet on carpeted wooden floors. Oh, and I suppose, the books themselves.

Ever since I got the iPad though, and downloaded both the iBooks and Kindle apps, I haven’t experienced the pull the libraries and bookstores used to have on me. Almost all my reading has been done on the iPad these past couple of weeks I’ve had it, and the only reason I got to bookstores is to get ideas on what book I should digitally procure next.

But one thing that I’ve noticed is that reading books on the iPad provides a slightly different experience. For some reason, it doesn’t gel with reading for pure fun or enjoyment.

 

I’ve had great success in moving most of my reading toward the iPad for non-fiction, business- and psychology-type books, but less so for the more fictional, narrative, or biographical- and travel-type books. On the former, what I’ve especially liked is the fact that I could highlight and add notes at will, adding a whole different dimension to my reading.

For some reason, when I’m on the iPad my mind races toward what I hope to get out of the book, as opposed to enjoying the book for what it is.

Metro Design

WordPress 3.8 has just been released, and it brings with it some rather significant aesthetic changes to the admin interface. While giving it a test drive, I realised how closely it resembled that of Windows Phone/8 (in terms of colours, fonts, and distinctive “flatness”).

For all their faults, Microsoft’s Metro interface is, to me at least, a pretty decent design philosophy. And if it wasn’t for the fact of having felt like a second-class citizen in terms of mobile app development while holding on to an Android device (it’s almost always iOS first), and not quite wanting to push myself further down the ranks, I’d have gotten a Windows Phone purely on the UI (user interface) itself.

It’s my guess that if there’s going to be a Web 3.0 interface, my feeling is that it’s going to be Metro (if it hasn’t happened already).

Big Data and Personality

Andrew McAfee posted about a very intriguing study on personality, gender and age in their relation to language. In essence, what the study did was to look at the correlation of people’s Facebook statuses and their personality, gender, and age.

You’ll know why I say it’s intriguing when you take a look at some of the findings. Especially interesting are the word maps.

Here’s one showing the words used by people who were extraverted/introverted, and their emotional stability (i.e. personality). Neurotic people are sad, angry, and existential. Emotionally stable people are… hmm… outdoorsy/active? As McAfee mentioned in his post it’s an interesting correlation between the sorts of activity and emotional stability, but one which cause-and-effect is difficult to determine. Does physical activity lead to a more emotionally stable personality, or do emotionally stable people just tend towards physical activity?

Image of Facebook status updates by personality

I’m pretty much a 60/40 introvert (60% introvert, 40% extravert) so I’m always intrigued with studies on introversion, so I just couldn’t ignore the huge “anime” (and its related terms, like “Pokemon”) popping up in the introversion word map.  — I do wonder how much of an impact cultural influence (i.e. a person’s country of origin/residence) plays a part. And did you notice the number of emoticons in that map? Me too 🙂

And here’s the word map for males vs. females. I love this one. Seems like the biggest thing on female’s minds is shopping and relationships, while for males it’s all about sex and games. As McAfee mention’s on his blog, this doesn’t “does not reflect well at all on my gender”.

Image of Facebook status updates by gender

And here’s one for age. My guess why daughter’s are more talked for the 30s to 65s about is because women are the ones talking about them (men just talk about sex and sports). In the gender map, relationships dominate what women talk about (apart from chocolate and shopping), and through my experience in TV watching, women don’t really talk about sons because sons pretty much take care of themselves. Daughters, on the other hand, are always worth worrying about.

Image of Facebook status updates by age

I could imagine fiction writers using these to build character dialogues; or academics building ever more insightful anthropological maps; or marketers with targeted campaigns. It’s a really imaginative use of big data, and one that I think is brilliant.

Who says Big Data’s failed?

The dismal failure of ‘Big Data’?

I just read an article on ZDnet on the dismal failure of ‘Big Data’ that was so bad I don’t even know where to start. The author states that economics is a “big data” profession (why–what makes a profession “big data” or not?), and then goes on to say that because big data hasn’t been able to solve all the world’s economic ills, it has failed.

Surely, a Big Data profession such as the study of economics over the past 150 plus years would by now be refined and almost scientific in its precision, especially since these days we have as much compute power as an economist might need, not to mention even more data to analyze. But it’s not even close.

This much data (enough to be called “big data”) wasn’t available until the recent past, so why drag 150 years of history into it? It isn’t like we’ve been working with big data related to economics for the past 150 years. The technologies, skills and mindsets related to handling this much data are still very young.

What is more, I don’t really get what he means by the failure of big data. “Big data”, by definition,  simply means data that the data cannot be (or is difficult) to handle using legacy techniques involving just a single computer. By saying that big data has failed, it implies that it can succeed. But how? What’s the thing that differentiates the success and failure of “big data”?

If success means solving all the world’s economic problems then by golly, it has failed. But that’s like saying that if a pair of running shoes promises to help you run with less pain but doesn’t help you win the Olympics has failed. Certainly, there are limits to what big data can do, but saying that it has failed doesn’t make sense.

Possible successes — if you will call it that: Web analytics (where data is so easily grown because of the ease of data collection and the number of people and actions that can be measured) and politics (which was, actually, driven quite a bit by web analytics).

BONUS possible success: sports, specifically baseball (not big data per se, but it’s an interesting read and it’s about data, so there.

Some thoughts on the thinking behind building things

I’m going to write a bit about my thinking process whenever I build things, whether it’s websites, VBA applications, or financial models. I’m not too sure if this is going to be a “oh that’s so obvious why is he telling me this?” piece, but if there’s one thing I’ve learned, one person’s normal behaviour may be another person’s exceptional one.

And I know you’re exceptional. So let’s get on with it.

My thinking process whenever I’m making things people use (i.e. goes into production) goes like this:

First, I ask myself (or the project champion/sponsor/requester): is this a one-off, or will there be many iterations?

If it’s a one-off, I can do away with making things beautiful and/or flexible. For one-off builds (again, whether it’s a webpage or financial model), most things can be hardcoded (e.g. unchanging interest rates, cell references and the like) and documentation doesn’t need to be too detailed (trust me on this though: documentation should still be done. People have a habit of waiting till the day after you forget what you did to ask you how you did it.)

If there are going to be many iterations, then I ask myself, what’s likely to change?

I once built a financial model containing over 30 options from which business users could pick and choose to determine what affected the final number. The model didn’t start of with all the options straight off the bat, and was in fact supposed to be a one-off. But after hardcoding and then manually changing what users needed multiple times within the same day (even though they “were quite certain” on what they wanted early on), I realised the flexibility of options, despite the longer initial development, was worth doing. I built the options on a very granular level so users could say, “I want option #1, #5, and #29” and have the affected numbers come up immediately.

Focusing on what’s more likely to change, and ignoring those that won’t, will allow you to save plenty of time. In that same model, I didn’t bother with ensuring formulas didn’t get broken when headings changed, because I knew they weren’t going to. (But I have certainly done this before; in some applications I’ve written, the source data had headings manually typed in, and almost every other week some variation of what was basically the same thing would get put in. I used regular expressions to ensure anything that looked like a header was treated as a header.)

Who and what is this report for?

Depending on the needs of the request, you could very well end up spending hours on something that should take only minutes. I have encountered many times someone coming to me for numbers in which I thought details were needed (or would be useful). I’d spend far too long extracting and formatting really granular data, when all the person needed was a “ballpark” figure.

And when you’re sending that consultant who is requesting for your company’s sales figures the information he needs, make sure you’re not giving him more than he needs. Does he really need to see the invoice numbers? Or customer IDs? Or costs?

Designing for maintenance

A few years back while taking the train I saw an engineering student’s lectures notes on “designing for maintenance”. I’m not from an engineering background, but because I happened to be mulling about on what software to use for a website I was developing, the concept of designing for maintenance struck me like Eric Clapton’s fingers on a guitar string.

Beautiful. Smooth. And oh-so-right.

The two main pieces of software that I had been considering were pretty distinct. One had a very developer-friendly, Linux feel. The other had a very polished, user-friendly Apple feel. The former catered to my nerd needs, while the latter catered my aesthetic aspirations (an aside: the very word ³aesthetic² is surprisingly pleasing to the eye and ear).

Though at first I was kept in a 50/50 bind between the two, after getting exposed to this idea of “designing for maintenance”, I realised that I really needed to go for the more polished and user-friendly one. Though I was helping to develop the website, I wasn’t going to be running it or doing the day-to-day maintenance of the site.

I think that maintenance of software (including spreadsheets) is something that’s missed by far too many people. If you know you’re not always going to be around to maintain the software, make sure it’s easy-to-understand and that everything’s well documented (even if it’s in an e-mail). Keep in mind that it isn’t all about you, but rather about the end-user, too.

Well, that’s about what I have for now. Would love to hear your thoughts on this. If you have any.

Business vs. IT

I was reminded today in a book I’m reading on visual analytics that the purpose of any analytical project is ultimately to make better decisions. Coming from a mixed business and IT background, I have had my fair share of IT vs. Business conundrums.

With my IT hat on, I’m always thinking about efficiency, optimisation, ease-of-use, and resource management. What questions are being answered, what problems are being solved, or what the ROI (to a certain extent) isn’t always on the forefront of projects (though almost always who’s the requester is).

With my business hat on, I’m always thinking about what business questions to solve, what information needs I have, and just plain old “getting the answer”, which IT isn’t always the most willing to help retrieve. I don’t care about how long IT takes (so long as its done yesterday) and how much effort they need to put in or how optimised the process is, I just want my questions answered so I can make better decisions. Isn’t that what technology-driven analytics is supposed to do

But, coming from a mix of business and IT backgrounds, I know the problems both sides face. IT needs more emphasis on understanding business needs, while business needs to understand IT constraints.

My current role has me more as a “business” person, and I don’t know if that’s a blessing or a curse. A blessing in that I’m given a lot more face time in business and finance discussions, allowing me an almost voyeuristic view of how the business makes its money. A curse in that IT treats me as any other “business” user who’s request trigger-happy and who doesn’t understand the IT side of things (and therefore who should be ignored most of the time).

It’s tough convincing IT to talk about the things that could potentially give pretty decent ROI when they don’t trust you.

“I’m one of you,” I tell them.

“Yeah, you sure are, buddy,” they reply, smiling, handing me a ticket number.