Notes to self

Not gold alone brought us hither

Feb 26, 2012

App users

The chances of success for an application increases when the following set of people are happy:


Administrators want to easily …

  1. Install and uninstall, and does not leave anything behind after uninstall
  2. Configure and customize system settings
  3. Keep things updated without crying
  4. Full control over email support

###Policy deciders

Policy deciders want to …

  1. Control who can access the application
  2. Decide who can perform certain operations
  3. Keep tabs on who has done what


Users want …

  1. Customized views of everything
  2. Instant access to everything
  3. No interruptions while they are working

###Other developers

Other developers want …

  1. The ability to extend and script
  2. A supported API to work with
  3. Components they can reuse

This is taken entirely from the slides from the talk Christian Hammond & David Trowbridge gave about ReviewBoard in 2008. This talk can be viewed on YouTube here but I did not find the slides anywhere else and hence wanted to capture this in writing in a blog post.

Feb 3, 2012

What is your story?

It was late one night in Vienna when I was walking the streets with a colleague – hopping from one pub to the next – trying out different beers in this beautiful European city. We were there attending a technical conference, and there was nothing much to do after dark except make the most of this time exploring the hosting city. As we walked the streets late into the night, we talked about various things ranging from work, to hobby, to technology in general, and so on. It was then that my colleague asked this question: “So, what is your story?”

I was never asked this before, therefore a prepared answer was not available. I remember asking him what that meant. Was this a trick question? After being told that the question meant exactly what it said, i.e. he wanted to know if I had a story to tell about my life – a story that captured the essence of what the journey has been so far, what have been my influences so far, what and who am I motivated by, what events changed the course of my journey, and most importantly, what am I headed towards. That last part is as important as all the other parts put together. That one thing will say a lot about what I care about and why am I doing what I am doing, and what guides my actions.

This is powerful stuff and I have thought about this question a lot since. Now I do not make a major decision in life without invoking this question and thinking about how this decision will shape the answer to that question. It has also influenced my day-to-day actions – sort of helping me answer the question: what do you wake up for?

If I am ever asked this question again, I have an answer this time. Maybe a long answer, but an answer nonetheless. And that colleague of mine is part of the answer.

Jan 21, 2012

Code commit on day one

As a software developer, what do you expect to accomplish on the first day on your job? Certainly not checking in code. But here is an example of a company where you would be expected to do just that.

Ok, so why does this matter? In a small to mid sized team, say up 20 people, new engineers do not join your every other week. So why solve the problem of having a new engineer commit code on day one? The answer is: to make this happen, you will need to take a look at and fix/improve multiple things in your software development process; as a result, your team’s productivity and effectiveness will improve.

Here are a few things that are required to make this possible. This list is not comprehensive, but compelling enough for us to take action.


####Machine ready Give your new employee a computer, along with his login credentials and an email account, within 5 minutes of him reporting at work.

####Software development tools Provide the location of the team’s software tools repository so he can start setting up the development environment, e.g. IDE, source code control, etc.


####Product’s technical documentation Technical documentation is any type of documentation that describes handling, functionality and architecture of a technical product or a product under development or use. For an engineer to be productive on day one, the technical documentation needs to be up to date and readable.

####Compact code base Keep the code base clean and compact. It should be possible to checkout a branch (or clone a repository if you are using a distributed source code control like Git) within minutes. This requires that the versioned files do not include derived artifacts or third party libraries. For example, if your application ships java, don’t check in the java binaries into the source code control – archive it in a separate repository instead, from where the packaging script can retrieve it while creating an installer. Most java projects use Maven these days and the jdk binaries are stored in a Maven repository for such projects. Another example is the product documentation, which is usually authored and stored as xml and the end user documentation is generated from these xml files and transformed into pdfs, html, MS Word or other format. Do not version these derived files in your source code control because it bloats your repository without adding value.

Bottom line: cloning a repository or checking out from a branch should not take more than a few minutes.

####Code quality Code needs to be readable, should follow a consistent style, should contain necessary comments (too little comments or too many comments can both work against readability of code – a fine balance is needed). It should be possible to understand the code (with help of a mentor) on reading it once or twice. If most of the code does not make sense without somebody explaining it in detail, take that as a sign that the code needs to be improved or cleaned up.

Maintain and follow a coding standard (example here) or a code style guide. It is important for the readablity and consistency of your project’s source code. The new engineer needs to adhere to this coding style starting with this first commit.

####Unit test coverage Almost all of the code needs to be covered by XUnit tests. Without a healthy suite of XUnit based unit tests, checking in any new code (even by a senior member of the team) adds risk and every checkin needs to pass the test: “Is this change worth the risk?” To avoid this situation, a good unit test suite is a must. A few rules about unit tests (see more on Test Driven Development here):

  1. The entire unit test suite is run as a part of the build every time
  2. The unit tests do not have any external dependency to ensure that the unit tests can stand on their own.
  3. Checkins not allowed if there is even one unit test failure
  4. Every code change that is checked-in accompanies supporting unit test(s).

In absence of the above, the risk of allowing a new engineer to add or change code is simply too high, let alone allowing him to checkin code on day one.

####System test coverage Automated system tests are the next level of checks after unit tests. A healthy automated test suite is required to ensure that changes in source code do not generate hours or days of testing to ensure regression has not happened due to the change. Also, if anything is broken, it should be detected as soon as possible. The automated system test suite needs to run at the end of the build and packaging tasks every time. System test failure should be treated seriously and issues found in this phase should be fixed within hours. The team should be in the habit of seeing the system tests pass every time. This can be many times a day or at least once a day as part of the nightly build.

####Time to compile and run unit tests The team should have a collective goal to keep the time it takes to build the entire system, down to the smallest duration possible. If it takes the build (which includes code compilation and xunit test run) more than two minutes, take that as a sign to investigate what is taking so long. For example, if you have multiple unit tests which have tests that put the main thread to sleep because it is waiting for a result – that is a bad test. Either it needs to be reimplemented in a way where waiting is not required, or it is a system test that has been implemented as a unit test.

The bottom line: compiling your entire project and running the unit tests should complete in a matter of minutes.

###Conclusion Even if you don’t have new engineers joining your team every week, meet the requirement that it will be possible for a new member of your team to contribute on day one and checkin a fix or a small feature. This will force you to review every aspect of your development process and improve it. Your entire team will benefit from spend more time improving the product than fixing defects. Your business will do better because it will be possible for the team to quickly turn in new features without impacting the quality of the product.

Jan 1, 2012


Here are my highlights for the year 2011. Just want to put this on record while I am still reflecting on the year that was. After this, I will once again turn around and look straight ahead.

  • I’ve been using MacBook for over a year and found my fondness for it grow. Even with continued use, the fascination has not worn off a bit. More I use my MacBook, more I like it. The model I own was discontinued this year, and is no longer available. Newer, faster, thinner MacBook Air has replaced this older plastic MacBook, but I continue to like mine better.
  • The natural next step was to figure out how to program a Mac. I did something close, if not exactly the same: developed two apps for iOS, where Seema conceived the app and did the artwork. That was fun. As a side effect of developing and publishing these apps on the App Store, I had to create a website for the app which exposed to me a whole new world of web development. These apps have been downloaded more than a 1000 times, which is not a big number by most measures, but it feels good to have touched a thousand peoples’ lives in some way. Got to do more of this.
  • Dabbled a little bit in Java 7 when it was released. Filed a bug in the compiler and saw it fixed in the next update. I thought that was cool.
  • On the health and fitness front – my running milage peaked around mid year and then dropped off completely. At this point, I am probably in the worst shape of my last 10 years (yes, it was even worse before that, but I digress). I need to put this aspect of my life back on track.
  • I continued to blog through 2011 and towards the end of the year, merged my two blogs into this one. The reason why people blog is now obvious to me. I agree that it has some sort of a healing property. Every blog post results in a great feeling even when you know there is not much of a readership out there. Journaling is known to have many benefits.
  • For the first time in 15 years, I am now without a DSLR camera because I sold it off along with all the lenses. Its time to buy new but am not decided on a particular model. Interesting improvements are underway in the world of DSLRs (for e.g. mirror-less cameras which makes the camera body much thinner than the current models). I will keep watching their moves until I am ready to buy a camera that will stay with me for a long time.
  • Finally, this year I am back on Twitter and am finding it more useful than Facebook or Google+. Even though I continue to use these two ‘social networks’, the one that I use regularly is twitter, even for my personal communication with the distributed family.

That was about 2011.

Jan 1, 2012

Business as usual

As a year ends, and yet another begins, the following is a good reminder:

The thing is, we still live in a world that’s filled with opportunity. In fact, we have more than an opportunity – we have an obligation. An obligation to spend our time doing great things. To find ideas that matter and to share them. To push ourselves and the people around us to demonstrate gratitude, insight, and inspiration. To take risks and to make the world better by being amazing.

– Seth Godin in a blog post