Work Related

Follow The Leader

Sameer Alibhai — Thu, 17 Jul 2008 22:40:22 GMT

In order to succeed as a team, in any sort of team, you have to follow this basic principle, which has been applied and maybe is accepted universally.

The principle is simple.

Appoint a Leader
Leader makes council with the team
Leader makes a decision
Team supports leader in his or her decision

Its that simple. In this way, an organization, a team, a family, or a company can move forward. Every decision that you need to make, is done in this manner. The team will work together for the best solution, but in the end the leader needs to make a decision. Once that leader makes a decision, the team needs to move forward WITH the leader.

This means, the leader doesn’t necessarily dictate, but he or she has gathered input from the team and made a decision. Then they will have to choose a solution and go with it. If the team continues to argue and fight over the decision, progress will be slow. I believe this applies in families too. There has to be a decision maker in the family, for example that is appointed for financial decisions, and then having a discussion or gathering input from the family is great, but in the end one person has to make the decision, and the family needs to be supportive, even if they don’t all agree with it. However, this applies in normal circumstances and there are caveats. There might be some cases where it would be unethical for team members to support a plan if its morally wrong or it goes against everything inside them and they feel it’s a plan headed for disaster.

It pains me that time and time again I see this happen – the leader makes a decision and the team continues to question him at every step of the way – “Why are we doing this”, “Why are we doing this”, and “why are we doing this” instead of understanding that they were appointed for this role (they might be your boss for example) and they are ultimately responsible for the decision, you need to do your job and support them. I have seen some cases where I questioned my manager because I didn't see the wisdom in the decision he made, but in the end it turned out he was right and it was just my foresight wasn't as far as his... So I learned my lesson, be patient, and be a team player.

As a team member, sometimes I have to swallow my feelings and say, “okay I don’t think this is the smartest decision and my idea is actually better, but I will go with you on this”.

From a developers perspective, you can think of this as requirements. Your boss gives you the requirements, you implement it. How you implement is up to you, but you won’t be able to proceed if you start arguing about the requirements. Requirements are requirements, once they are agreed upon, please continue.

So in normal circumstances, if you want to succeed, get a leader, and help him with his decisions, but in the end.. Respect the decision he makes and go with it. (He or she, that is).

The best team isn't necessarily the one with the best players, it's the one that plays together the best.

How to Waste Millions Of Dollars With Outsourcing (or Make Millions)

Sameer Alibhai — Thu, 10 Jul 2008 22:14:17 GMT

To management, the idea of outsourcing sounds very sexy.... The idea of producing the same content (code, or what not) at 1/2 or 1/3^rd the cost is almost a wet dream for management, if I may be so bold. Even though it sounds great in theory, it's actually a very tricky function to master. Here are some things I have learned with my outsourcing experience.

Keep in mind I am not discussing the outsourcing style of passing requirements and getting the end product complete. I am discussing the style of hiring outsiders and working with them on a daily basis.

You have to start by looking at what is the purpose of outsourcing. Is it to save money? Or is it to improve quality? Or is it so that your team can focus on other things? Get this straight first before going any further. My points below are in the context that you are a software company (or at least do some software development) and you are considering outsourcing to save money and cut costs.

From friends, I know that some very popular companies outsource, such as E-Trade Canada, Accenture, and recently the new online T.V. web site Hulu which outsourced its development to China.

Before you start outsourcing, have your process solid - i.e. have regular scrum, know how much code you are generating each week, and so on. It's very important that you have some idea of costs for developing software for your local team. If you have no idea, you won't be able to see if you are really saving money or wasting it.
Know velocities of individual team members so you can measure cost effectiveness of your outsourced work.
Build your estimation skills. Read Joel's article on estimation and his second article on estimation (which is really a promo for his bug tracking software but still worth reading) and Steve McConnell's book on Software Estimation (highly recommended, very easy to understand).
Get smart/able/competent guys. This can make or break your outsourcing project. If you are going to get developers that need baby sitting, then hire a baby sitter on their end to clean up their code, otherwise you are going to waste your valuable resources fixing and re-fixing and re-fixing their code. In this case you might not be actually saving money.
Review their code. Someone on your side is going to have to review their code to make sure that they aren't purposely obfuscating it in order to secure their jobs in the future. I have seen a Flash application that was built in this manner, the team overseas purposely messed up the code in such a way that it would be difficult for others to continue where they left off.
Learn from those who have done it before. If not, you are going to mess up big time, in many ways. Might be worth getting a consultant who has been successful with such projects. Another idea is to find someone who has connections "back home", and go there to see how some of the shops work.
Turnover is really high in India/Bangladesh/ and so on. This is because jobs start at really low salaries (like $200 a month) and go upwards to like $3000 a month (comparable to working in Canada or USA). You will need to find a way to solve this problem. Somehow you will need to get them to commit that guys will not drop like flies. This is so important because there is always an upfront cost to learn an application, and it becomes more as the complexity and lines of code increase.
Consider a cross-cultural learning program, you send some people there for a while, they come over here for a while. A lot of big companies do this. It's almost a must.
For the team overseas, its important to spend your valuable time together in the beginning to ask lots of questions and understand the requirements as much as possible, in case there is a task that you run into questions, then leave it and work on something else.

Hamid, Axosoft CEO claims that Outsourcing is for Dummies. I think this isn't true in all cases, as I have been able to apply outsourcing successfully on some small projects. However, it all depends on the case, and for building complicated software with a (geographically) fragmented team, you may just end up proving his point.

PHP VS. ASP.NET

Sameer Alibhai — Thu, 08 May 2008 21:42:05 GMT

This is a very shallow comparison of my experiences with PHP and ASP.NET

Don’t take this as a religious war or something, the idea is just some basic comparison.

Here is a summary: If you are choosing which technology to use to build an application, use .NET. You will get more bang for the buck. With the same effort you will be able to build a much more rich user interface.

My Disclaimer: Keep in mind there are a lot of great libraries and tools for PHP which I never got to use, I just had a simple PSPad text editor and my handy PHP web site. I really wanted some “Intellisense” style code completion but I could not get it to work with PHP since I couldn’t find a decent IDE (i.e. editor)

However, it all depends on your requirements. For example, if you are selling something that most of your customers will be on a shared linux hosting environment, then why would you use .NET ? A good example is the software Clipshare, which is a clone of Youtube. The sites purchasing this product are mainly shared hosting customers who have PHP but not .NET. And Mono (.NET port on Linux) is not yet stable or popular enough to use.

I did some PHP programming before I started doing .NET fulltime. Before then I couldn’t say much about it, but after working with .NET for a few years now, I have much to say.

.NET does a very good job in handling the whole life cycle. With PHP you have to do it manually. For example, there is no such concept of “Postback” with PHP. This is such a basic thing that you can easily check with .NET to see if the page has been submitted and what button was pressed. For example if your “btnSubmit” was pressed, it will call btnSubmit_Click. With PHP, you have to do this manually. Not to mention how mish mashed your PHP page can be in terms of mixed code and style/HTML elements.

How about caching? I wanted to implement caching with PHP and I had a fun time, I had to check if the cached output file existed, and then if so, then check how old it is, and so on... Yeah okay again maybe there are some nice components already done for this, but I didn’t have to look very hard to do it with .NET, I simply added a CacheDependency on an XML file (or whatever the case was), and BOOM! It regenerated the file whenever necessary.

How about reusable components? With .NET you can create ASCX (Custom Controls) that you can place within a page that expose certain properties and the control itself maintains its state, can have buttons, etc, etc.

How about master pages (i.e. templates) in .NET? Again, super cool reusability! You can create pages with repeatable parts, with headers, footers, all sorts of fun stuff.

I can go on and on... but in general, the more I use .NET, the more impressed I am with it. However, what makes it not-so-practical is how expensive Windows Server hosting is. In summary .NET kicks butt!

Unit test your life!

Sameer Alibhai — Tue, 29 Apr 2008 23:25:53 GMT

If you are not unit testing your code, chances are you are not unit testing in your life.

If you aren’t unit testing, START now! At the very least, do some “manual” unit testing in your code. How can you do this? Well, try running your code on a very basic case. Then try a bit more complicated case. Then another, then another. If you are smart, you are saving these cases using a testing framework like NUnit. If not, well at least you can have some confidence when your manager comes that you tried it comprehensively and that it’s not going to crash on you while you are showing it to him, or even worse, in a demo to the team or to your big boss.

I recently ran into some problems in my life which I managed to solve amazingly well by doing “unit testing”...

First problem, my DVD burner was going awfully slow. I had some complex and messy setup including an external IDE card, two burners, two hard drives, and all I know is that at some point in time something went wrong and it started going really slow. What I don’t know, is how it happened.

Second problem, I was doing some video encoding/rendering, and for some reason it was doing something bizarre and the application VirtualDub kept looping over and over and would never end encoding the file. Again, I don’t know what happened.

How did I solve these problems?

UNIT TESTING!!

For the first problem of the DVD drive. I removed everything from my PC and set up a very basic system which included 1 HD, 1 Burner, etc.. Then when I found this wasn’t working, a quick check online and I resolved the issue which was incorrect DMA settings. It was trying to send all the data through the CPU (PIO mode) instead of directly to the burners, which was causing a massive slowdown. Once this worked, I quickly put together my system again, and checked each case (HD on same IDE channel as Burner, on separate IDE channel, and so on).

With the encoding problem, again, I was very confused, but by unit testing the situation, I was able to resolve it. How did I do that? I tried encoding on a different machine, reinstalled the software, etc, etc, and it was still having problems.

And finally when I started from scratch, I removed the batch encoding, I removed the DiVX processing, and so on, and then made each test pass. Once the test passed, I added another level of complexity, until finally I figured out that VirtualDub was looping infinitely because I had the “segment AVI file” option enabled. I don’t know why this was the problem, but by unit testing, I was able to resolve it.

Lesson to learn? Unit testing (if you can call it that) can really help you solve such issues. Start from the base case, and slowly work back towards what you need. After each case, write down the results.

Microsoft felt strongly enough about Unit Testing that Visual Studio 2008 has built in unit testing (Wahoo!). As well, it integrates nicely even with NUnit or MbUnit (Don’t ask me how, though).

Five Points To Improve Your Estimation

Sameer Alibhai — Fri, 28 Mar 2008 12:32:19 GMT

Software Estimation is tricky business. You are often confronted with complicated technical (or even non-technical) work and asked “how long will it take?” on the spot. You are given fuzzy requirements (or no requirements) with ambiguous definitions and have to work with a code base that is best described as “chaos”. How can you give an accurate estimate with such a difficult environment?

I recently read an excellent book called “Software Estimation: Demystifying The Black Art"

Here are some amazing points that you can use.

1) We should not be pressured to reduce our estimates. Stick to your estimates – whatever they are. If management wants to reduce them, that’s fine, but stick to whatever you put in the first place. Managers trying to reduce estimates is a very silly thing to do, because by looking at the track record of our software industry, you will find that we consistently underestimate, not overestimate! So if you are pressuring your developers to reduce the estimate, you are asking for trouble. Better thing to do would be to see if the estimate is well founded, based on task level estimates, or is the estimate based on unjustifiable assumptions, etc.

2) Underestimating is MORE expensive than overestimating. So if you cannot estimate accurately, lean towards overestimating. Underestimating has an exponential additional cost, whereas overestimating has a potential of a linear extra cost due to Parkinson’s law. This is because underestimating results in lots of other problems such as having extra meetings to justify why you are behind schedule, having extra meetings to decide which features to cut, added stress on developers trying to meet tight deadlines, code having less quality in order to ‘just finish it’ so that developers can go home, having customers get angry at not-ready releases, having other teams who are waiting for the code to slip their schedules too, etc.. If you overestimate, then Parkinson’s law can kick in and developers will ‘fill in the empty time’, or as they say ‘work expands to fill the available time’

3) Task level estimates are best done by the developer who will be doing the work. A task level estimate is defined as a low level estimate for a particular item of work. For example, for building a workflow engine, a task level estimate is “2 hours to add the save button that will commit the changes to the database”.

4) With small teams (say under 5 people), estimates are most accurate when done bottom-up (i.e. from the developers). What this means is your complicated formulas for estimation are not so helpful in such environments.

5) There are many other ways to estimate such as ‘estimation by analogy’ (i.e. by looking at a similar project that was built), and so on, but I won’t explain those right now. The trick in general is to try to quantify as much as possible and leave subjectivity out of the picture. So if you can find out how similar your project is in terms of number of lines of codes, number of features, etc, you will have a better estimate. As well, don’t be fooled into thinking that more “estimation knobs” will give you a better result than less “estimation knobs”. I define an estimation knob as some sort of criteria you are using to estimate, such as “size of team”, “team programmer skills as a percentile of the industry”, “how many burgers they had for lunch”, etc.. It looks like it would give you a better result but in reality the estimate becomes more and more subjective as you add more “knobs”

As well, developers are more likely to try to meet their estimates if they are the ones who gave it, rather than if its dictated to them from above.

Lastly, estimation is a skill we can learn and improve over time. You will find that over the months, your developers will get better at estimating based on past experience.

In summary, stick to giving your developers clear requirements, lock them down, and then get them to break down the requirements into task items, and then estimate for those task items.

My experiences with pair programming

Sameer Alibhai — Wed, 19 Mar 2008 12:16:06 GMT

My initial thoughts on pair programming (definition).

Normally at our shop, we don't do pair programming. Each developer is assigned his or her own tasks and they are responsible for completing them. If they require assistance of explanation from another developer who is more familiar with that system they need to go and request that assistance on their own. I believe the vast majority of offices work in this manner.

However, yesterday we decided to try pair programming. We have a complicated CRM application where it takes months to learn the application, and the situation is that another fellow who works on the reporting side of things and I worked together to solve a few bugs in the system.

As we worked together (with a slightly decreased speed than the two of us seperately working) we managed to eliminate two instances of duplicate SQL code in our application and instead used a view that already existed which I was not aware of. As well, I am very confident you that this resulted in a much higher quality of the application, even if it took longer. You are far less likely to end up with bugs when you use pair programming.

I am still skeptical if it really was slower or not, because when you work on your own, you can get stuck on a particular problem and waste half a day, whereas when the other person knows it, you can immediately solve the problem and move on. As well, you are less likely to waste time checking the news, weather, etc, because the other person is sitting and working with you. Also, keep in mind that "task switching is expensive". When you are working on a piece of code and you are "in the zone" and then you have to stop to assist someone else, this lowers your productivity, whereas when both of you are concentrating on one issue, you don't have this issue.

Pair programming can also be used to train or "rough in" new employees, and as well it results in increased code awareness (i.e. both of you are trained on the same piece of code, incase one of you quits or is sick, the other person also has a good idea of the code).

While the jury might still be out on this principle, and maybe its still too "extreme" for most managers to allow it, give it a shot when you have a chance and see how it goes.

Timing is EVERYTHING

Sameer Alibhai — Sun, 23 Dec 2007 13:18:31 GMT

Being a person who believes in continual improvement, and being proactive instead of reactive, I suggested to one of my employers that I worked for that we should implement ELMAH (Exception Logging For .NET) to handle our uncaught exceptions. They weren't too interested when I made the suggestion and so I did not push it. I had found this gem of code here because I spend a bit of time each day doing research and improving my skills. (see point 2)

However, we had this continuing problem where customers would have a problem with the .NET site, maybe they had a crash and we had no way to diagnose the crash other than to remote into their machine and try to reproduce the error. What made it worse is that they had debug mode off, and we could not even see the exact crash details. Often we would have to take a risk and modify their file to put debug on (I say take a risk because if you make enough modifications, the application will restart and kick everybody off the system) and this was a live site with real customers.

So once the problem was large enough that it was passed on to the development manager. When he queried the team for possible solutions to that particular crash, I jumped at the opportunity to suggest ELMAH. The sale was immediately closed, and within a week we had ELMAH up and running on some of our customers.

Lesson? Wait for the right time to make your suggestions. it can be very effective. Otherwise your advice may be falling on deaf ears.

Also.. this had the same result again when the timing was right we were able to successfully convince our development manager to make the switch from SourceSafe to Subversion. We had discussed it many times but we had to wait for just the right time and when this time came (since they already knew about it and liked it, but were just waiting for a good time), getting approval from management was easy as pie.

Understanding Your 10 Days Vacation

Sameer Alibhai — Mon, 12 Nov 2007 12:54:34 GMT

This article is based on Canadian vacation laws.

It seems that most people don't understand that by law we get 4% vacation. So where does this number of 2 weeks come from?

Well If you calculate 50 weeks * 4%, you will end up with 2 weeks, what that means is in 1 year, you get 2 weeks paid vacation and 50 weeks of work. So if your employer prorates your vacation for the first year, meaning that after 3 months they give you 3/12 of 10 days (i.e. 2.5 days or 25% of your total) but you need to take off 2 weeks and they refuse to give it to you, you shouldn't worry about because either it means at the end of the year thats all you took (2.5 days paid), and by law they will pay you for the other 7.5 days or 3.75% of your total salary at the end of the year (or whenever they reconcile their accounts which could be a few months later)

The other case is that you will still get 7.5 days vacation after those 2.5 paid days, so in that case you didn't lose anything and you ended up getting about 2 weeks extra unpaid vacation.

So make a decision, and enjoy your vacation!

Social Engineering And Monkeys

Sameer Alibhai — Thu, 16 Aug 2007 18:45:59 GMT

Here's how I heard it. This is an example of social/psychological experimentation and there is something we can learn from it.

Researchers in a lab were carrying out an experiment. There was a cage with monkeys, and there was bananas at the top of a ladder on a platform. Every time a monkey tried to climb up the ladder, every monkey in the cage would get shocked (how cruel). Eventually, if anyone tried to climb up the ladder, all the monkeys would get mad and tackle the monkey down to the floor and beat him up. Eventually, what they did is they removed 1 of the monkeys, and put a new monkey in the cage.

Obviously, he had no idea what was going on and when he tried to climb up the ladder, the monkeys got mad and beat him up. And then the researchers continued doing this until not a single monkey was there from the initial experiment (they were all green monkeys).

Now, if anyone tried to climb up the ladder, they would all beat him up, yet none of them had a clue why they were doing it......

Sometimes at my job I am reminded of this. We are doing things which make no sense, and if anyone asks why.... the answer is, well, "because that's how we always did it."

Bananas anyone?

Are You a Sharp Developer?? (Part 2)

Sameer Alibhai — Mon, 13 Aug 2007 01:18:17 GMT

This is the second post in the series "What Makes a Sharp Developer"
The next article in this series will discuss keeping up with the bleeding edge - Visual Studio 2008 (Orcas), Silverlight, .NET 3.5, LINQ, .. and more

This post will focus on: balanced lifestyle, staying away from drugs, and keeping a healthy balance between learning and working. Overall this article discusses how you can become a more valuable resource to your team and to your employers.

Lead a Balanced Lifestyle

Many of us in the development or business field unfortunately tend to overwork ourselves. We work late nights at the office surviving on Java alone (caffeine, that is, not Sun Microsystems Java^R). We take our work home in the evenings, or we might be doing stuff on the weekend that is work related so that we have a head start during the week. I feel this tendency to overwork ourselves is part of our human nature. We have to protect ourselves against this and yearn to keep a balance. Although there is some overlap, I like to divide my time into three categories - Work time, Time for God, and Time for my family (don't forget Time for Myself). The difficult part is keeping the three in balance and perspective.

If we start doing fifty or sixty hour weeks consistently, our quality of work will definitely go down. It is unfortunate that some companies do not understand this, and push their developers to work longer and harder despite the fact that inevitably their performance will suffer. As well if your family life suffers, that will not be good for you at work. Your wife (or husband) might end up putting extra hot sauce in your sandwich because you didn't spend time with her for the last six weeks and your stomach isn't going to like that.

Stay away from the drugs

One of the keys to success is to stay away from drugs. That includes alcohol, nicotine, and.... that includes caffeine, man (Bummer!). Actually caffeine is one of my favourite drugs :(. But keep it in moderation. If you overdo it, or if you become dependent on caffeine to survive, you are going to be at a weakness to those who can survive without their daily injection. Also it hides your tiredness, especially if you start to use it regularly even when you aren't working, you might not realize just how tired you are. If you notice you are coming home with bad headaches, or are feeling dizzy or other strange things are happening, THOSE ARE NOT A GOOD SIGNS.

A balance between working and learning

This one is a tricky one. It depends a lot on your work environment and how tight your deadlines are. I am suggesting that you make sure that no matter what, each day you learn something new. Do not spend so much time on your task so that you are completing it as fast as possible without taking the time to investigate or find better solutions. Don't assume that just because you did this four times before, that the fifth time you should do the same thing. It could be possible that you did it a silly way four times and you are just going to make it the fifth now! There have been so many cases where I have been repeating my same noobness (i.e. lack of expertise) by declaring my SQL parameters as an ArrayList for example, whereas I could do it without the additional memory overhead and then conversion into an array by declaring my SQLParameters directly into an array with the exact size I need! Sometimes employees think that they are not doing their company a favour if they "waste" time reading stuff like this.

Infact, I beg to differ!! On the contrary, you will be a MUCH more valuable employee if you insist on taking the time to learn things. An employee who consistently learns is the last one to get fired, whereas the old dog who can't learn new tricks is going to be the first one to have to sleep outside (so to speak). Please, this is so important. If your boss doesn't give you time for this, either get a new job, or work late so that you can spend an hour a day on this. As well, this will give you a bit of job security incase you end up being the one who is laid off, because you have been keeping up with the improvements and constantly sharpening your skills, you will be more in touch with the technology than the ones sitting on their old skills.

As a PS, I would also recommend looking at current job postings to see what technologies are in demand, and as well try to see if you can figure out trends (i.e. which direction the market is heading and what technologies are up and coming.)