Posts

by on

A typical bad day at work for a programmer is to getting stuck. A stuck programmer is easy to spot, s/he is the one who has not moved away from the computer for a long time and if at all moves away is still visibly occupied with thoughts about how to find a solution.

Some of the solutions which I observed are

Discuss the problem with someone else

This is one of the best solutions which always worked for me. Even at times when someone listens to the problem does not help me fix it, just explaining it to someone helped me visualize and articulate better which in turn brought me closer to the solution. This is where pair programming wins hands down.

Read the Manual

While this may sound obvious, I have observed this to be one of the key issues to someone getting stuck. The entire IT population is trying riding on the keywords like convention over configurations, intuitive code, fluent interfaces; that combined with the hello world kind of exposure to tools gives programmers a more than enough confidence to carry on the everyday work. So when getting stuck the immediate response is to try what is obvious or what looks intuitive.

Take your eyes and mind of the problem

Any person’s action at work will first be governed by the conscience and instincts take over later. It is very similar to how we start driving or play instruments, we will be at ease once we are in a productive rhythm. The advantage of this mode where the instincts control our work is that it is very efficient but at the same time it moves us into a very narrow view of the work. When stuck we are stuck just in this narrow view and might not think out of this view (is it sounding like thinking out of the box?). This is similar to sleeping, it is so easy to get back to sleep when the alarm rings in the early morning no matter how difficult it was to fall asleep; if the concentration levels at work has been high and we got stuck then a way out is to come wide awake out of the concentration. Few times I have been stuck at programming from 6PM till bedtime just to wake in the morning and solve that in 15 minutes.

Almost every one of us at the work place have signed up for some sort of deadline, if we get stuck it adds to the stress. We have to use the phrase from “The Hitchhiker’s Guide to the Galaxy“. DONT PANIC

Image: Master isolated images / FreeDigitalPhotos.net

by on

This is a follow up of my previous post Nice Guys, do you finish first?

I got to know the term seeders and leachers from the Torrents. The term leeching is very common in the computing world,  but is it relevant in any other context?

Yes it is relevant in other contexts as well, I keep observing these in my workplaces. Some of the workplaces I have seen has very rigid written performance expectations and assessment criteria. The performance evaluation is nothing but a way of identifying the leechers and removing them from the system. The key problem in this setting is that the cause and effect might be very spread apart and it is easy to find ways to comply with every word from the expectations set and still be a leecher. Lots of tools and methods at the workplace evolve at a very rapid pace which makes it hard to keep the expectations at a written form and convey to people.

Who is a seeder? Is someone who comes to work delivers the job as per requirement and goes home a seeder?

A seeder is someone who not only does her job but also makes sure the peers need not rework or struggle in the coming days as result of her job. If a team contains lots of seeders then there is effective communication, on time delivery and a good balance of work and life. The team can pretty much handle themselves without a need for a supervisor. On the other hand if the team contains lots of leechers, then there is a need for a supervisor to keep a check on the delivery and try to remove the leechers out of the team.

Any example of a leecher? What happens if we dont remove them from the system?

Let us take the example from the documentary Nice guys finish first, the social setting of a group birds is such that each bird removes of the ticks from the other birds. Each bird is groomed by someone else to be healthy. In this setting it is very easy for a bird to get groomed and get away without returning the favour. The bird which exploits the social setting is a leecher. If we dont remove the leecers from the system then the overall advancement of the system is very limited and will encourage selfish behaviour.

Unfortunately it is not so easy to find leeching in self organized teams, the reason is that leeching might be involuntary through unconscious incompetence. The individuals might not realize that they are over grazing the resources and soon going to add pressure on their team mates. Timely facilitated retrospectives, reflections and corrective actions without penalties will help improve the well being of the self organized teams.

Image: africa / FreeDigitalPhotos.net

by on

Recently our team wanted to add some more features into an existing app built on Rails 2.3 about 2.5 years ago (July 2009). We ended up in a situation that in order to proceed adding new features we have to upgrade to Rails 3.1. The primary reason being that we were using outdated technology and there is a difficulty in maintaining our legacy (2.5 yr old) app by getting support and documentation. The migration also was not smooth, we spent time looking at screencasts, tutorials, documentation and forums to move ahead and after a good deal of effort the migration happened. At one point during the migration there was also second thoughts to rewrite the app from scratch as the migration was labour intensive.

This event made me feel that we might be heading towards disposable software. Keeping the life cycle of the rapid development tools in mind should we design cost effective disposable software? By taking the example of How to Create a Blog from Scratch Using Ruby on Rails in simple steps, I believe that we might be heading towards a solution of disposable software. A large application could be built using many pieces of disposable software if we take care of data integrity during upgrades or replacements and effective communication between applications.

The questions that arise are; How long is long enough to dispose the software? Software development costs are ever increasing, will this model fit enterprises? Will this mindset make software accessible to the masses at a cheap cost?

My take on the questions.

Q. How long is long enough to dispose the software?

A. We could take around 2-3 years for a software to be useful for us before we reach out for an upgrade.

Q. Software development costs are ever increasing, will this model fit enterprises?

A. My experience with enterprises is very limited, as far as I know the huge cost in procurement of an earlier version has been a mental block for organizations to go for a timely upgrade. If we make software development faster and cheaper then there is a high chance of regular upgrades.

Q. Will this mindset make software accessible to the masses at a cheap cost?

A. Right now many services are beginning to become available for super cheap cost empowered by the cloud, it could be possible in the near future that people can get made to order software at a cheaper price.