Keep a lookout for these languages

some articles are doing the rounds about the languages to learn, so I decided to add my two cents to the discussion. These are the languages that I have on my radar -

• Python: I've been using Python for my side projects for the last few years. Needless to say that I like it a lot.
• JavaScript: Essential if you are going to do anything related to browser client-side coding. With the popularity of AJAX, JavaScript is quickly becoming a language that you need to know.
• Ruby: Many of the ex-Java coders are moving to Ruby in a big way. The language has gotten another big push with the popularity of Rails. This is on my to-learn list.
• A functional language: Scheme and Haskell are popular choices. Even if you don't actually use it regularly, learning a functional language is great for completely changing the way you think about programming. One of those experiences was when I got hold of a Scheme interpreter and followed along SICP and HTDP. Both Scheme and Haskell are on my to-learn-more list.
• Erlang: This is on my to-learn list. I think concurrent programming is going to increase in importance and I've heard a lot about Erlang.
• Perl: I find it useful as glue in *nix environments, especially if I need to use it's awesome regex capabilities, but don't use it all that often. The syntax is a pain to remember.
• C/C++/Java/C#: Chances are that your organization uses one of these languages, so you need to know it. That's about the only reason I can think of. Java has some useful libraries and frameworks for it, so that's a plus. Not sure about C#.
• Maybe someday: Smalltalk !!

Factory factory factory

Hilarious spoof on over-engineered frameworks. I was literally rolling on the floor laughing, and the best part is that it is all just so true!

What skills do I need to be a good scrummaster?

Based on my experiences, my list would go like this -

Have empathy. This is the most important. Learn continuously. This is the second most important. Apart from these, you need

• Understanding of the organization and its culture
• Understanding of the team and its dynamics
• Understanding of the people on the team
• Facilitation skills
• Conflict resolution skills
• Ability to work with people
• Ability to coordinate with teams
• Ability to work with management
• Ability to solve problems and get things done

What does you list look like?

Steve Irwin Tribute

Why software processes are like exercise

Software processes are like exercise. Everyone knows that its the right thing to do, but most people don't do it.

Why don't more people exercise? Because its too hard and it involves too much change. You see, exercising involves things like 'determination' and 'discipline' and 'goals', and who has time for that? An entire industry has evolved around the fact that people would like to be fit but do not like to exercise. At one extreme is the quick fix solution - wear some gadget and get fit without doing anything. At the other extreme are the hardcore fitness people who spend hours in the gym and scoff at any fitness scheme that tries to water down exercise. In the middle are a whole lot of activities that try to make exercise more fun and meaningful. The idea is not to be the fittest that you can possibly be, but to be as fit as you can be, without feeling like giving up.

Software processes are exactly the same. Processes are the right thing to do, but its far too easy to not see results and give up in frustration. At one end are the silver bullet providers - do X and your project will deliver itself. At the other end are those who live and breathe process, the process gurus, the people who have paparazzi following them all around.. well ok, maybe no paparazzi.

The agile early adopters are high up on the agility scale. The mainstream following behind are low on this scale. The big challenge for the agile community is to transfer the benefits of agility to the mainstream.

One way to do that is to take a bunch of processes that are radically different from what they are used to doing and ask them to follow them all. Some will try it out, get overwhelmed by the change, and give up in frustration. Others will resist the change. Still others will quit and go with what the silver bullet providers have to offer. A few will cross over. Those who didnt make, well, the fault lies with them - they are weak and have no discipline, and no wonder their projects failed.

Another way is to provide a transition path from zero agility to full agility. Pushing companies to go all the way, all at once, just makes them give up completely. This is bad. Companies should adopt agility at the point that they are comfortable. The idea is to maximise benefit, without feeling like giving up. That way, companies know that they can take the next step, and get better results, if they want to, or else they can stay where they are comfortable if they so desire. Just like exercise.

What would this transition path look like? How would you define 50% agility? How would you reconcile this against different agile processes that advocate different things? What should a company be doing if they want to be semi-agile? I don't have answers to these questions yet. What do you think? Is this possible? I would love any comments and feedback.

This post is a part of the selected archive.

5 dangers when adopting agile processes - and what to do about them

The last couple of years have seen agile software development 'cross the chasm' from the early adopters to the mainstream. This is great news for agile, but there are some dangers lurking in the background. Here are five points that companies need to watch for when adopting agile processes

1. Unfamiliarity: When early adopters practice agile, they really understand what agile is all about. Mainstream companies are less likely to understand the principles of the process. They've heard about 'this agile thing' and want the same benefits on their projects.


2. Top-down thinking: Most organizations practice top-down management, where managers make decisions and staff follow them. Agile processes work bottom-up, where the team is empowered to take many decisions, and the team is responsible for changing the process. This can be uncomfortable for many managers.


3. Culture change: Agile processes not only demand a change in they way software is developed, but a change in culture. Agile processes value a culture of openness, cooperation and collaboration. The mantra is "get work done", instead of "cover your ass".


4. Incomplete implementation: Companies that implement agile processes sometimes change the process out of convenience, without an understanding of the process. 'We don't do retrospective meetings because they waste a day of work', or 'Everyone knows what to do, a daily standup is not required' are some forms of process change that are instituted under the guise of 'tailoring the process'. Tailoring the process is good if you know what you are doing, but can lead to disaster if it is done just for convenience.


5. Silver bullet syndrome: Agile processes are not a silver bullet. They will not magically deliver your software, cure all ills and create world peace. There are many components to a successful project, and the process is just one of them. You still need a good team to do the work - in fact a good team is even more important in an agile process than in traditional processes. There are many components that determine project success or failure - management support, effectiveness of the process, quality of the team, familiarity with the domain and technology, to name a few. Agile can help with the process, but don't ignore the other components.

Right, so what can you do about it? Here are three ideas to help you get started with agile

• Learn about agile: The best thing to do is to learn about agile. I mean really learn about it, not read a single article in a magazine about how agile is the next big thing. There are lots of great online resources for learning. Check out agile websites, blogs covering agile or agile groups on Yahoo! Groups. You will find lots enthusiastic people just waiting to help out.


• Start small: Start small, refine, repeat. Implementing an agile process is not something that can be done throughout the organization in one shot. Accept that the first few months will be unproductive as everyone comes to grips with agile, its culture and its values. Choose a small project as a prototype, and iteratively refine the process. When you are comfortable, move on to another project, then another.


• Examine the organization culture: A big stumbling block is reconciling the existing organization culture with the values of agile processes. Transitioning to agile involves change, and like all change it is easy to see things not work out at the start, get frustrated and return to known, comfortable ways of doing things. Take some time to learn the values of agile, and how it can be incorporated into the organization.

This post is a part of the selected archive.

Interesting way to sell your company

From TechCrunch:

Online calendering company Kiko.com has decided to call it quits and put the site up for auction on eBay. They are also offering to export or delete user accounts.

You know that the action in the web space is starting to get hot when everyone starts talking about startups that closed down.

Final batch of photos uploaded

I've uploaded the final batch of photos for now. The new France photos here (new photos are at the end, starting from the fireworks), and the fireworks photos here. The fireworks are from Singapore National Day 2003, France Bastille Day 2006, Singapore National Day 2006 and the Singapore Fireworks Festival 2006.

France photographs

I've uploaded the first batch of france photos to Flickr. You can view the set by clicking here. You can also see the newest seven uploads on the flickr bar at the top of this page. There are 26 photos in this first batch of uploads.

Pink Lily

Pink Lily
Originally uploaded by Siddhi.

Taken at the Botanical Garden in Singapore

Cyclists, cyclists everywhere

One of the sights in south france was the huge number of cyclists on the road. We aren't talking about your average cyclist like in Chennai either. These guys (and gals) are on racing cycles and cycling clothes, cycling between cities. I'd keep seeing a bunch of them every couple of kilometers happily riding along. Oh wait, did I mention that the area is quite hilly? And that the temperature was around 36 degrees celcius? Wowie. I was getting hot and sweaty just walking around to find a good spot to take a photo from. The Tour de France was going on, so that might be an explanation for the increase in enthusiasm, but still to go cycling in that heat requires a serious dose of enthusiasm. The highlight was when we were driving to the peak of Mont Ventoux, the tallest peak in the region and there was a steady stream of riders going to the peak and coming down. The route is not easy either, and this route is sometimes used as one of the stages of the Tour de France (not this year though). I can only presume it's for fun and exercise, but it was some sight.

Fun at Paris Charles De Gaulle airport

So I arrive at Paris CDG from Heathrow, disembark from the plane and enter the terminal. There is a sign saying "Baggages", so I follow that and come to an immigration desk. Immigration takes all of 20 seconds before I am in the baggage collection area.

Before me is baggage collection belts 1 and 2. The screen only shows flights from Prague, Bucharest and a couple more east european countries. Hmm. No London anywhere. There are these two people waiting for luggage, so I ask them, but they don't speak english. Where are the others from my flight anyway? I go over to what looks like a help desk and ask the person there. After some broken english, I am told that British Airways is at Baggage Belt 4, at the other end of the terminal. To get there, I need to exit this baggage area and go to the other end.

I leave, walk over to the other end and find Belt 4, but I can't find the enterance to it. The only enterance seems to be through the Immigration desk on the other side of the terminal, and I've already finished Immigration. I go to the Information Help Desk and the person there informs me that I should wait near the baggage exit. When someone comes out, the door will open and I should walk in when the door is open. Interesting!! I do that, and get in. Inside, a customs guy asks me why I am entering from here, and when I tell him (going to the wrong baggage area seems to be a common thing), he says that I should go to the British Airways desk where they will fill up a customs clearance form and I need to give that to the customs.

Back outside, I go to the British Airways desk, show my boarding pass and get the customs clearance form. This is so common that the person at the desk had lots of these forms on the top of the desk. I take the form and get back into the baggage area. The customs guy takes the form and I can finally get my baggage!!

Back from France trip

So I'm back from the France trip and after two weeks without Internet, I have access again... only to find out that my comp at home is not working (video card seems to have died), so it might be a while before I can upload photos. I have to upload photos of both the Germany and France trips, but it might take a while before I can get my comp up and running again.

Electricity plug points again

After thinking some more about my complaint on plug shapes, I realised that having incompatible plug shapes is actually a good thing. Different plug shapes prevent you from accidentally connecting a device meant for one voltage into a plug point which delivers another voltage. This is an example of the design principle 'Make it hard for users to do the wrong thing'.

Complaint of the day

After all these years of electricity why can't countries standardise on the shape of the plug point? I'm not even talking about the voltage, just the shape of the plug! *grumble, grumble*