• Enter Slide 1 Title Here

    This is slide 1 description. Go to Edit HTML of your blogger blog. Find these sentences. You can replace these sentences with your own words.

  • Enter Slide 2 Title Here

    This is slide 2 description. Go to Edit HTML of your blogger blog. Find these sentences. You can replace these sentences with your own words.

  • Enter Slide 3 Title Here

    This is slide 3 description. Go to Edit HTML of your blogger blog. Find these sentences. You can replace these sentences with your own words.

Friday, June 29, 2007

Why Software Projects Fail?

Today I read a nice set of ideas on "Why Projects Fail" by Andrew Stellman and Jennifer Greene (ppt or pdf). They have analyzed and categorized the reasons for failures of projects. That led me to write this post.

Ways a project can fail
1. Things the boss does
- Top level may not be communicating well with the rest of the members to pass the knowledge that they got on the requirements or they may not have gained required knowledge. Also some of them may be over confidence on what the team can actually achieve, so they make a guess and resulted in huge issues on development phase.

2. Things the software does
- One major problem is receiving unclear incomplete requirements at the start, but has to continue on what is available. This is a huge problem as it would be too late when it's figured out that the the software does not match the expectations of the end user.

3. Things the team should have done
- Development team also should think wisely and accept the project dead lines. Usually a project comes with an abstract set of requirements, then estimates and deadlines are fixed without even analyzing them thoroughly. As the time passes, developers realize the risks and issues. But many of them keep mouth shut till the end as they feel that it's too late. But the best way to handle such a situation would be to discuss that with your team or the top level immediately rather than waiting for the delivery date.

4. Things that could have been caught
- Testing is one of the areas where most of the development companies do not touch, but that makes an huge impact on the quality of the product. Getting one or two guys from the support team and training them for testing by developers is not a good patch for this. The developer is having only his view on what he build, so training by him/her would not lead to uncovering hidden issues. Also neglecting on issues we see before hand is also a problem. If a design issue or a coding error is found, no one should wait till another catch it.

What can be done?
1. Tell the truth, so that the team and top level has a good understanding on status of project.
2. Have reviews as much as possible, as this will lead to moving the project toward the correct path always.
3. Let everyone express their ideas and issues. Some members may have difficulties on understanding requirements or issues on skills, and let them to come up with those. This will lead to a far better team.
4. Treat the team well and make sure all the necessities are fulfilled to continue with the project.
5. Solve issues early as possible by not trying to point fingers later.

What are your experiences and views? We would like if you share those with us.

Thursday, June 28, 2007

Adsense rounded borders for ads formats

Google Adsense has come up with a new feature for ad borders, that is "Corner style". This features improves the look and feel making an advantage for site developers.



Now publishers can choose between 'slightly rounded' or 'highly rounded' corner (two sample are shown here). If your site has a rounded template this will help a lot.

To apply this change for existing Adsense ads, you only have to add another line to set another value inside the script. Set the value of "google_ui_features" as follows.

google_ui_features = "rc:6";
google_ui_features = "rc:10";

"rc:6" is for 'slightly rounded' while "rc:10" for 'highly rounded'.

Wednesday, June 13, 2007

Jar utility can compress files?

Java archive creator is the Jar tool. Is it just a packaging tool or does it compress and package (like zip utilities)? It can compress and package, also by default compression is on. So all the jar files that others have created so far may be compressed (since they did not turn off that).

You can turn off the compression feature by using the 0 (zero) option of the jar command. The command would look like follows.

jar cvf0 TicTacToe.jar *.class

So what's the big deal? It's always better to compress it!!! Many may think so?

No, that's not the truth. There are reasons why you should turn off the compression. For a situation where a jar file is loaded to a browser, uncompressed jar will be suitable over a compressed jar. Uncompressed JAR files can generally be loaded more faster than compressed files because the need to decompression overhead is eliminated. However there's a trade-off, for an uncompressed jar download time over a network may be longer. So decision must be taken by considering both aspects.