Coder.Tinkerer.Traveller

I'm currently reading Peopleware - Productive Projects and Teams, by Tom DeMarco and Tim Lister, and I definitely agree with most of their opinions. I was rather enlightened by their main conjecture that the main cause of failure in most technology innovation projects is not technological in nature, but sociological.

Was asked to provide feedback on how my current organization could be a better place to work and how we could create more impact in the work we do, and I found myself drawing upon what I've been reading:

Innovation means being open to tolerate risk and accept mistakes, as this is inevitable in the process of exploration. A culture and work environment needs to be fostered, where failure is tolerated, even encouraged, instead of being judged and appraised.

There should be less top-down management directives telling staff what to do, and more encouragement of staff to push the boundaries of technology and take measured risks to create disruptive innovation - and that means a culture of tolerating risk and failure, and rewarding novel effort instead of just outcomes.

Normalization of rankings and stack gradings across departments is not a good practice in my opinion, as it generates excess and unhealthy competition and self-centred cooperation. Ideally, staff should have an appraisal component related to how often and how much they help other departments and projects.

There should be more effort to engage the local industry and start-up eco-systems in joint projects and collaborations, beyond a simple licensing model.

There should also be a lot more industry-practices sharing and training events, such as agile software engineering practices and cloud computing platforms etc, so that staff can get an actual understanding of how the cutting-edge technologies and methodologies are really used in practice.

Good engineering should be regarded and rewarded as a craft, not a machinated process to just throw staff headcount at.

Spent the weekend at a hackathon organised by UPSingapore with the National Environmental Agency (http://cgs.sg/hackathon/about/). Was quite interested in the environmental themes. However, the data-sets seemed to consist mostly of Excel spreadsheets of locations or past measurements. Only the dengue fever disease statistics and monthly electricity and gas consumption data-sets got me interested.

I was disappointed with the ideas pitches - most were half-baked, even downright speculative, and it seemed to me that most pitch participants had no idea what problem they were trying to solve. What irked me was that most people were looking for someone to 'build me a simple web/mobile app' while they would just be the 'ideas/marketing person'.

Hence I really appreciated the few noteworthy pitches from those who had obviously thought through a problem, or faced the problem themselves. Some had a half-solution looking to be applied to solve an environmental problem, which was quite cool as well. 

One pitch participant, Marcus, a sustainability manager, was part of an email list of people who wanted to give away their second-hand items to others. His problem was the gross inefficiency of the mailing list and forum system, which did not provide a way to check or update the status of items, resulting in an inability to find/track items, missed or overdue giveaways and a deluge of emails to reply to. He was not alone - there were 12,000 people in the mailing list in Singapore!

Sounded like a meaningful and clear problem to solve so my friend, Bruce, and I decided to contribute. Turns out a web application would address this and we spent quite a bit of time figuring out what technology stack would be appropriate. After deciding on one (with me being very vocal of Ruby on Rails) we wanted to get started on coding.

That was when we hit the first major roadblock - technical setup. While I have experience with webapps and Ruby on Rails and could, in principle, progress very fast, I faced a large problem figuring out which libraries/templates to use and how to get them installed on our machines. In particular, setting up a shared code base was difficult as Bruce had to install the entire development toolset. Even the most user-friendly tutorials had too many steps.

In a hackathon, it is very important to quickly get started, but for most of the evening, we had to meddle with installation instead of working on the solution, which was demoralizing. Bruce suggested reducing the scope and contributing directly to the production environment while we used our source control to keep in sync. So, at 10pm on the second night - 60% into the hackathon - we finally got a code development and testing iteration cycle going. We were using the production website as a debugger - thankfully it was not mission-critical.

Things got a lot better on the morning of the last day when I finally managed to fix some nasty bugs caused by incompatible software versions (after some much-needed sleep), thus finishing the first feature of taking a photo and uploading it to the website to view it (with storage on AWS). What a load of effort for a supposedly trivial feature!

We moved on very quickly, adding UI templates to polish the interface and adding edit and categorization capabilities, and even ending with an email notification form and a Facebook share button! The productivity in the final 3 hours was amazing and finally I felt the hacking vibe I was hoping for, and we finished the minimum-viable feature set. We were quite happy with ourselves at simply finishing and deploying a simple web application live. So we looked forward to the demo pitches.

I was again quite disappointed as the majority were practically powerpoint presentations with a couple of Photoshopped screens. Most of the pitches spent at least 50% of the time on background information - had no meaningful contribution, instead of focusing on showing what they built, because I suppose they didn't build anything substantial.

Thankfully, there were some very smooth demo presentations, which was the saving grace of the event, from my perspective. I learnt a lot from them - not just technical problem solving, but also giving a demo in an environment full of incompatible presentation devices.

While I'm technically-inclined and tend to emphasize evaluating technical and innovation merit, I'd say that even creating a simple WordPress blog with user data, or a LaunchRock page with users signing up to support an environmental cause, or a series of Balsamiq mockups would have been very impactful and meaningful. That would have motivated and inspired me to look at other ways to bring more people together, and apply technology and skills towards addressing environmental sustainability problems.

Our demo was not particularly ground-breaking either, but I liked that (i) it worked, (ii) it was live, and (iii) we were solving a tangible problem, for a target audience of 12,000 folks with a very clear need. 

Self-reflection - lessons learnt:

don't get caught up by the pitching hype or over-promise features. Instead, focus on value and be realistic - don't assume that it would be 'simple' or 'easy' because it has been done before

it's not about using tools which I'm individually used to - developing at a hackathon naturally means allowing oneself to learn and try new technologies along with the team. That said, come prepared with a set of tools to quickly build up a prototype

to get ready to change the idea/solution very quickly and reduce the scope drastically in order to build something that works

teamwork and delegation was crucial, in terms of choosing a solution approach that allows all team members to pull their weight as equivalent contributors

remember to have fun and talk to fellow participants

So I broke my Kindle last weekend by putting it in my back-pocket while walking around and subsequently sitting down on it when I was getting something to eat. :(

Screen showed a lot of lines that refused to go away despite many attempts to perform a hard-reset on the device. Realised the device was most probably a goner, so I thought "why not take it apart to see what exactly broke?"

The following series of images depict the disassembly process:

1) A sign that something was wrong - broken image refused to go away after attempts to reset the device

2) After a long and arduous process picking at the sides of the device to edge out the plastic snap-locks

3) Here are the basic parts - battery and internal components squeezed into a tight package

4) After an hour of tinkering and making sure I didn't lose any screws, I finally took apart my Kindle. The last part was removing the E-ink glass screen from its compartment, and voila! Problem identified!

5) Notice the spectacular cracks - I'm guilty of abusing my fav reading device :(

6) Love this Amazon E-ink technology - again I'm amazed at the engineering work that went into the Kindle

7) my Kindle - all taken apart

So I had an option to simply buy a replacement E-ink screen at US$ 39.90 and the Kindle should (theoretically) function like new after re-assembly.

Was a little skeptical that I didn't break anything taking it apart though, so I decided to buy a new Kindle PaperWhite instead (touch-screen, better contrast and attached light).