I spent a considerable time this past month learning new systems, platforms, and tools to improve my skills in programming. Choosing what to learn is often quite a difficult task of its own because you never know how the 200 hours you spent learning a new technology will impact your skills, creativity, and the very way you think. One important thing I learnt while learning to learn is how to distinguish between tools and raw materials, and more importantly, why.

Tools are what you build the product with. Raw materials are what the product is built of. The fable of The Chicken and the Pig would be quiet appropriate here: No matter what you build, tools are involved but raw materials are committed. I used to spend a lot of time picking the right tools for the right job because that's what you're supposed to do. Yet I saw lots of examples of really crappy tools being used improperly in very successful products. On the other hand, I also saw very good tools being used properly in products that failed miserably. How could there be no correlation between the input and output? Turns out I was only looking at part of the input. What I should have been concentrating on, was the combination of the raw materials and tools:

Success Matrix	Strong Materials	Poor Materials
Strong Tools	Designed to succeed	Awaiting disaster
Poor Tools	Awaiting sweat & blood	Designed to fail

Having a successful product certainly requires a lot more than strong raw materials and tools but having those two right gives you a strong foundation. That buildings and bridges built with poor materials fall is no shocker. What does surprise people every now and then is seeing something built with poor tools succeed. These products require a lot more sweat and blood to succeed but they can succeed indeed. I don't have first-hand knowledge working with the following tech sites but based on the information I've gathered from articles, interviews, and online postings, I would classify them in the success matrix as:

Success Matrix	Strong Materials	Poor Materials
Strong Tools	DropBox	Xmarks
Poor Tools	Orkut	Cuil

The problem with technology (and the primary reason I decided to write this post) is that it is difficult to decide what is a tool and what is a raw material when in the end, it's just a bunch of 1s and 0s. If you're building a shed, wood and nails are raw material, axe and hammer are tools - no ambiguity at all. But for a web project, is the back-end database a tool or a raw material? What about the platform, the programming language, the framework, the client-end scripting library, the graphics engine, or the server host?

Since the difference is hard to spot, the question is if it even matters or not. I'd say it does, for one simple reason - raw materials cannot be changed after you've started building the product whereas tools can be, albeit at a minor cost. You can't switch from wood to cement half-way through a building project but you can certainly upgrade to a nail-gun from a hammer when your arms get tired. Using the ability-to-be-swapped as the primary condition, it can be easy to decide if something is a raw material or a tool in a tech project. Hosting? Usually a tool, unless you build your project solely for AWS. Programming language and framework? Usually a raw material unless the back-end is what's doing the bulk of the hard work and the front-end is simply a pretty proxy. Database engine? Could be a swappable tool if you abstract away all database-specific calls from your code.

Programmers often get into long arguments about which technology is right for the job and why you should use X and never use Y. Fact of the matter is, if something is a raw material for your product, take the time and do the research to make an educated guess. It will always be a guess because you never know what will happen in the future. If something is a tool, just pick something that gets you going quickly because if it doesn't work, you can always switch to something else later.

Add a Comment

For some time now, I've been looking for a good way to build a system to help people with speech/neurological disabilities communicate better and tonight, I found it. After my cousin Keval from Mumbai got in an accident over six years ago, he lost his voice and motor skills. Over the years, he has gained some control over his right hand but it is not enough for him to type on a keyboard or use a mouse. It appeared from some videos that my sister sent me last year that he might be able to use a touchscreen to push digital buttons so I decided to look into developing a software/hardware system customized for him.

I created a rudimentary on-screen keyboard that helped guess what he was trying to type, a "smart" version of the T9 typing-mode on cellphones. I called it KType and it used Google's AutoSuggest feature to "guess" what the next word or phrase would be. That it was a good idea was confirmed when I recently ran across Google Scribe - a simple demo that works on the same principle (and uses the same Google data-source) as KType but offers a different user-interface.

I sat with Keval for many hours during my recent trip to India to try and figure out what kind of system would work for him. Last month, I met a friend's brother who has a neurological disorder that prevents him from speaking and makes motor control very difficult. I know I shouldn't extrapolate too much from just two people's requirements but I know that if I am able to make something that works for both, it will most certainly work for a hundred others, as there are many people who have problems speaking and using general-purpose electronic devices to communicate. With all of this in mind, I started to build a list of requirements for the hardware and software platforms that I will use for the next generation of KType.

The hardware I need to use will:

1. Be cheap and affordable: After all, health-care is expensive as it is. No need to make software that only runs on $10,000 machines. Maximum hardware cost: $1000, prefer to be: under $500, sweet-spot: sub $300.
2. Be available throughout the world: If not immediately, then within a year or two at most. No NASA rocket parts, only commodity hardware.
3. Have a touchscreen: It can be used as the primary input or as the configuration panel.
4. Have good audio out: Will be required for text-to-speech.
5. Be connected: Wireless required, Bluetooth highly desired.
6. Integrate with other devices: I may need the ability to integrate with joysticks, hardware push buttons, HDMI monitors, and other I/O devices.
7. Run on battery and for many hours: So the user can be mobile.
8. Easy to reset: 9 out of 10 errors should be fixable by turning the device off and on again.
9. Relatively easy to program: This is very important for me because I don't have five years to code patiently. I want to give a working KType device to Keval yesterday.

The software I need to use will:

1. Be free from licensing issues: I want everyone to use KType without any restrictions.
2. Work on multiple hardware devices: I want to write once, deploy anywhere. I am not building a high-performance, finely-optimized video game. I just want to make code that works and is stable, even if it's not "perfect".
3. Allow users to update to latest version: I don't want to manually upgrade all the devices. Ever.
4. Perform low-level hardware-functions is necessary: If I want to create a wireless network between my selected hardware device and a webcam, the end-user shouldn't have to deal with complex configuration. I want the ability to create an ad-hoc wireless network dynamically in code.
5. Exist today in usable form: I'm not going to wait for Apple, Google, Microsoft, or Adobe to release their latest and greatest SDK before I can start coding. I need to get started right away.
6. Be fast: While initially I'll do simple things like easy-to-use on-screen keyboard, I have plans to do some very CPU-intensive processing in the future. So I can't really develop in QBasic.
7. Have an extensive set of libraries: I don't want to reinvent the wheel. I want to use the most advanced wheel freely available today.
8. Not be a fad (i.e. be around for a while): I plan on working on KType for the foreseeable future. I can't start to code it in Erlang and find that the flavor of the day is Clojure or Ruby. Last thing I want to do is a complete rewrite. So the software platform I decide to use, better be around for a long time.

Having mulled these requirements over and over in my mind for the past few months, I was starting to get disappointed that I couldn't find a viable software/hardware solution. While the Apple iPad definitely met most of my hardware requirements, programming for it in Obj-C hardly fulfilled my software requirements. Finally tonight, I came across AirPlay - a software development system that will let me write code in C/C++ and run it on a variety of hardware devices, including the iPhone, iPad, and Android devices. Though AirPlay may not meet every single software requirement immediately, with the iPad expected to get some competition in the coming months from the likes of Samsung Galaxy Tab and Archos Tablets, I think making a cross-platform software that would work on any of these devices will be the best solution for me and my users.

I started to play around with AirPlay tonight and I'm definitely excited. My iPad is setup and ready to be programmed. Can't wait!

Add a Comment

I got my iPad 3G today! Time to start fiddling.

Add a Comment

It's been over a week since I started my new schedule and I'm pretty satisfied with it so far. I've gone running with our two puppies almost everyday, worked on my projects like I intended to, fulfilled all of my commitments, and got a taste of being in the zone. My stress-level has gone down drastically and I've been feeling extremely creative all the time. I know this because yesterday, after a hiatus of almost 3-4 years, I felt excited to dabble in computer graphics once again.

I made a 3D city out of Jenga Towers (warning: 7mb) by programming in Structure Synth and rendered it using SunFlow. To see how I did it, read this and to do it yourself, read this. While playing around with 3D graphics seems like a waste of time unless one intends to make it a career, I know from past experience that once I feel creative enough to make some artwork, the energy and enthusiasm starts to flow into my code and projects.

In other news, we cancelled our cable TV and home phone line. We mostly watch shows and movies on-demand via Netflix Instant ($9/month) so there's no point in paying $100/month for less choice and worse programming. I've been watching Doctor Who episodes while Juliet loves to watch chick-flicks and romantic comedies.

My plans for our big desert/canyon trip in October are coming together. I planned the entire 1700-mile route last week and will make the reservations for the camping sites later today. I'm so excited!

Add a Comment

I took a long walk by myself today. I had been waiting for this walk all my life and it was everything I ever thought it would be. Most people plan for success, many plan for happiness, and the rest plan for difficult-to-achieve goals. I took a long walk to plan for balance and self-actualization. Now that I'm not working full-time, there are too many things I can make myself busy with. Most of the things I want to do are computer-related and if my past-experience is any indication, they will bring me temporary excitement, momentary fame, and years of bug-fixes, feature-requests, and unpaid tech-support emails. In short, every new project I pick up comes with life-long baggage and even though I love these little things, they prevent me from doing the big things I really want.

I began my walk with the goal of simplifying my life while still enabling me to do everything I want guilt-free. This includes lots of computer things, family-time, exercise, kayaking, self-improvement, and social commitments. After an hour of pondering, I came up with a weekly schedule that will be nearly identical every day:

My daily chores would fit between 6am-7am and 7pm-11pm. All my interesting projects would be during 8am-6pm. Once a month, I will reevaluate my open projects and make changes to my schedule as needed. As of right now, I have prior commitments for Monday and Wednesday, at least till the end of this year. This leaves five days where I can do anything I want during the day. These five days were the most difficult to allocate. While I'd love to spend all of my time working on cool web apps like most of my projects or ZetaBee, I came to a realization that this is a never-ending, never-finished list. These projects have brought me immense joy and experience but have also taken up a lot of my free time in the past.

Additionally, these projects also conflict with my nature adventures. I want to go kayaking all day or hike a long swampy trail without feeling guilty that I'm not working on x-y-z. Then there is a big issue of getting in The Zone, "a phrase used by software developers to mean the ultimate level of mental focus." Working on six different projects in the same week basically means you don't get in the zone for any of them - too much distraction and shallow focus. I want the ability to get in the zone so I can do something with absolute concentration and utmost dedication.

My solution is to split the projects into (a) ONE-BIG-PROJECT and (b) everything else. The one-big-project is what I'll work on during Thursday-Sunday so I can get in the zone. Everything else goes to my "Too-Much Tuesdays" bucket. Every Tuesday, I will get to pick what I want to do that day. If I need to work extra on a project because of prior commitments, I can do that. If I want to go kayaking, hiking, or just have a Star-Trek movie marathon, I can do that. If I want to take a day-trip with Juliet, I can do that.

My goal is to stick to my weekly schedule without fail and push anything that would prevent me from staying on track to the Tuesday bucket. This will free me from guilt, distractions, and unnecessary busy-work so that I can work on my one-big-project for days on end. For the foreseeable future, my one-big-project will be KType. KType will be a mix of software & hardware to help people with disabilities communicate better. I'm certain that I will be writing a lot more about it in the coming days.

To make sure I stick to my schedule, I'm now tracking my time using Toggl.com. If it works well for me, I will write about my experience and methodology. Personally, I've never been too obsessive about following a routine and as long as I stick to my general schedule, I'll be more than happy. The goal here is to not stick to schedules but to create new, useful tools that help others. The weekly schedule, time tracking tool, and all these plans are just to make sure I don't go off-track, broke, or lazy.

Add a Comment