Work Related

Archive for the ‘Work Related’ Category

Learn Faster

October 3rd, 2008 by Sameer | 1 Comment | Filed in Uncategorized, Visual SourceSafe, Work Related

Change of atmosphere is actually a much faster way to learn, as I recently found out due to a job change. A lot of time spent in the same environment working with the same people and learning stagnates. If you really want to learn something different, be bold, take a risk, and change jobs. Another factor is type of company – changing company types can increase learning speed by working in a different environment. Technical skills are not the only skills that matter, so keep that in mind. By looking at how different companies work together and achieve goals is a learning experience in itself. I was concerned that moving from a team with many talented developers to moving to a team of one developer (me) my learning would stagnate. However, this is not the case. I feel like I’ve learned so much in the last few days just by being in a different environment. Take risks! Be bold!

Factors to note

- Background of those you are working with
- People who you are working with (non technical)
- Location of new job/environment
- Number of work hours
- SMALL or LARGE COMPANY
- Technology used (is it old, is it new… )

You can find a lot of these things out by asking in the interview. There are implications for each one of the factors above. For example, large companies are more resistant to change. They are usually late followers in adopting new technologies. However, some people feel that in large companies they have job security… So it all depends.

I think Justin of CodeThinked (a nice .NET blog that I subscribe to) sums it up pretty well why he changed jobs.

Keep in mind we humans are fussy beings. We don’t like change (most of us, anyway). You might find a lot of things uncomfortable in your new position.. It will take a while to adjust to the new area, new coworkers, new boss, and so on. But hey, life is about taking risks, right? Can’t be complacent all the time.

Follow The Leader

July 17th, 2008 by Sameer | 1 Comment | Filed in Software Engineering, Work Related

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)

July 10th, 2008 by Sameer | No Comments | Filed in Software Engineering, Work Related

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

May 8th, 2008 by Sameer | 80 Comments | Filed in .NET articles, Work Related

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!

Update Oct 8 2008

I wanted to add some more meat to this article based on the comments below

I mentioned that getting Windows Server hosting is more expensive.. However, lets look at this in perspective. What’s more expensive – server cost, or development cost? Development cost in most cases far outweighs any particular savings of a Windows license. What this means is even if your application takes two or three times as long to write, then you have lost any potential savings from running a "free" linux box.

Also, I would like to hear about how to unit test with PHP.

.NET offers unit testing via many different frameworks, NUnit probably being the most popular right now. I would like to know how can I unit test in PHP? There is also an extension for NUnit available called NUnitAsp that allows me to test my interface. Another notable extension for Nunit is an automatic database rollback. SWEET! More details to come as time goes by.

Unit test your life!

April 29th, 2008 by Sameer | No Comments | Filed in Software Engineering, Work Related

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

March 28th, 2008 by Sameer | 2 Comments | Filed in Software Engineering, Work Related

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

March 19th, 2008 by Sameer | No Comments | Filed in Work Related

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

December 23rd, 2007 by Sameer | 3 Comments | Filed in Work Related

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.

Archive for the ‘Work Related’ Category

Bookmarks

Meta

Author

Pages

Categories

Archives

Archive for the ‘Work Related’ Category

Related Reading:

Related Reading:

Related Reading:

Related Reading:

Related Reading:

Related Reading:

Related Reading:

Related Reading:

Related Reading:

Related Reading:

Bookmarks

Meta

Author

Pages

Categories

Archives