10 tips for meeting IT project deadlines

Overview: Erratic and poorly estimated timelines, scope creep, unexpected staff illnesses, and supplier failures are just a few of the things that could go wrong with your project. And because time is today the most common metric to measure efficiency, the schedule delays caused by these events can end up costing you a fair amount of money. These tips will help you plan your next project and ensure that it comes in on time, under budget, and at a high quality level.

Erratic and poorly estimated timelines, scope creep, unexpected staff illnesses, and supplier failures are just a few of the things that could (and probably will) go wrong with your project. And because time is today the most common metric to measure efficiency, the schedule delays caused by these events can end up costing you a fair amount of money (in addition to a possible damaged reputation). Here are some tips to help you plan your next project and ensure that it comes in on time, under budget, and at a high quality level.

Analyze the requirements in detail
Understand exactly what the project involves, down to the smallest details. Ask questions to clarify ambiguous areas. Finally, hire professionals to clearly document the business requirements, the functional specification, and the design requirements. Watch out for scope creep; it can single-handedly destroy all the work you've done. If the need arises, take aggressive steps to reduce the scope of the project or to avoid adding unplanned new features that require significant integration time.

Map available resources
Map available resources with requirements to ensure that there are enough personnel on site to complete the job. Identify all relevant infrastructure—hardware, software, human resources, tools, documents—required to execute the project well before the project development starts.
Perform training and knowledge transfer
Include training, if any, as part of the project timeline. Don't treat training as something team members do on their own time, but account for it in the project schedule and budget.

Identify risks
Identify the potential risks and create contingency plans to deal with them. Develop a backup plan to meet the project deadline in case of unexpected process or personnel failures. This "plan B" acts are your support system when things don't go as expected.

Estimate and allocate
Assign roles and responsibilities to team members and ensure that each task has a clear owner. Use project management tools and Gantt charts to record who does what and identify start and end dates for each activity. Failure to assign clear responsibilities for each task can lead to overlapping responsibilities, duplication of efforts, excessive time spent on activities, and inferior product quality.

Modularize work
Break down main activities into sub-activities, until each activity is complete on its own and independent of other activities. Arrange them in logical order and then start executing the smallest activity in the order of occurrence.

Avoid too many meetings
Plan meetings to discuss the status of the project or on an as-needed basis to address immediate problems. Long, unending meetings with no clear agenda and hence no clear outcome only waste time.

Write things down
Document the failures and successes of the project. This is important; it acts as historical information for similar activities in other projects. Use a project dashboard to obtain a visual, high-level overview of the project and to measure the progress of project activities. Take stock of the project at each milestone and update the project dashboard each time.

Beware of follow-the-sun development
If there is a follow-the-sun development model (a continuous engineering environment with development happening 24/7 across the globe), ensure clear communications to avoid misunderstanding between co-located or cross-country-located team members. Coordinate well and regularly so that nothing falls through the cracks.

Escalate issues
Escalate issues to management as they occur and brainstorm on solutions to problems. Trying to remedy problems after they've deteriorated beyond recovery is the last thing you need.

Build powerful Web applications via the Yahoo Developer Network

The community aspect of the Internet has changed the way we work. Developers can quickly get answers to their questions by way of a Google search, or learn new techniques and technologies via countless Web sites, blogs, and so forth. One site I recently discovered is the Yahoo! Developer Network. While it offers lots of API's for utilizing Yahoo! features, it also includes plenty of generic Web development resources.

What is it?

An initial perusal of the site can be a bit overwhelming, but it offers a variety of cool stuff for Web developers. Yahoo! describes the purpose of the site as helping software developers integrate Web sites and applications with Yahoo! using standard technologies such as XML and RSS.

YUI Library

The Yahoo! Developer Network offers tools and sample code for working with Yahoo! applications like Yahoo! Finance, Maps, and Messenger, as well as Flickr and HotJobs. The tools include RSS feeds and API's for utilizing application services, but I want to concentrate on the Yahoo! User Interface (YUI) Library.

Yahoo! describes the YUI Library as a set of utilities and controls, written in JavaScript, for building richly interactive Web applications using techniques such as DOM scripting, DHTML, and AJAX. It provides a set of components for adding specific functionality to a Web application. The components are available as open source via a BSD license.

The components are available in one download, which is comprised of one compressed file. You can extract it to install the library; it includes documentation, sample code, and the source code for each component. Let's take a closer look at one of the components to get a feel for what is available.

Calendar

Providing a calendar is a common requirement for Web applications. The calendar component provides a powerful solution to such requirements. It is very flexible, allowing it to be configured to meet just about any scenario. The following resources of the YUI Library are necessary to use the calendar:

• The Yahoo global object is available in the yahoo.js file in the build/yahoo directory of your YUI Library installation. It provides a single global namespace within which all YUI Library code resides. It must be included on every page that utilizes the YUI Library, and it must appear before any of the other YUI components.
• The Event utility (event.js file) includes code to handle events. It is located in the build/event directory of your YUI Library installation.
• The DOM Collection (dom.js file) provides code for working with the HTML DOM. It is located in the build/dom directory. It comprises a family of convenient methods that simplify common DOM-scripting tasks, including element positioning and CSS-style management, while normalizing for cross-browser inconsistencies.
• The actual calendar code is found in the calendar.js file in the build/calendar directory.
• The calendar.css style sheet provides visual formatting of the calendar control. It can be found in the build/calendar/assets directory.

All of these files should be included in your Web page to use the calendar control. With them included, an HTML element is created to contain the calendar. For example, the following div element is used:

Next, the calendar control is created. It accepts a minimum of two parameters. The first parameter is the id of the new element that will be created by the calendar control to hold its DOM. The second parameter is the id of the element that will contain the calendar control (our div element). The next example takes advantage of the optional third parameter that specifies a start month/year for the rendered calendar. A fourth optional parameter can be used to specify a selected date on the calendar control.

Finally, the render method of the calendar object is called to render it on the page. Listing A creates a calendar beginning with January 2007.

This is a basic example, but there are plenty of options for working with the calendar contents as well as formatting its display. Listing B extends the previous code to customize the display characteristics of the calendar including the weekdays, months, and so forth.

Using the Calendar control is better if you can work with the values within it. You can use the following line to display the date selected by the user (mouse click) via the Calendar control's getSelectedDates() method in the previous examples.

what's selected?

These examples provide a preview of the basic functionality of the Calendar control. You should refer to the documentation to dig deeper into what it offers.

Design patterns

Another interesting area of the Yahoo! Developer Network is design patterns. While design patterns have been utilized by application developers for years, they are not as common with Web developers. Design patterns provide solutions to common problems and keep developers from reinventing the wheel every time they are faced with common scenarios. The library site includes numerous Web development patterns with sample code that often utilizes YUI Library components.

New tools at your disposal

The Web is overloaded with sample code and related resources to help with your Web development projects, but some resources are better than others. I found a great resource when I stumbled upon the Yahoo! Developer Network. It provides plenty of helpful information for taking advantage of Yahoo!-related resources in Web applications, as well as a great set of Web components, sample code, and much more.

courtesy @TechRepublic

10 common Web design mistakes to watch out for

When you start designing a Web site, your options are wide open. Yet all that potential can lead to problems that may cause your Web site to fall short of your goals. Whether you're building a commercial Web site, a personal or hobby site, or a professional nonprofit site, you'll want to keep these issues in mind.

1. Failing to provide information that describes your Web site
Every Web site should be very clear and forthcoming about its purpose. Either include a brief descriptive blurb on the home page of your Web site or provide an About Us (or equivalent) page with a prominent and obvious link from the home page that describes your Web site and its value to the people visiting it.
It's even important to explain why some people may not find it useful, providing enough information so that they won't be confused about the Web site's purpose. It's better to send away someone uninterested in what you have to offer with a clear idea of why he or she isn't interested than to trick visitors into wasting time finding this out without your help. After all, a good experience with a Web site that is not useful is more likely to get you customers by word of mouth than a Web site that is obscure and difficult to understand.

2. Skipping alt and title attributes
Always make use of the alt and title attributes for every XHTML tag on your Web site that supports them. This information is of critical importance for accessibility when the Web site is visited using browsers that don't support images and when more information than the main content might otherwise be needed.
The most common reason for this need is accessibility for the disabled, such as blind visitors who use screen readers to surf the Web. Just make sure you don't include too much text in the alt or title attribute -- the text should be short, clear, and to the point. You don't want to inundate your visitors with paragraph after paragraph of useless, vague information in numerous pop-up messages. The purpose of alt and title tags is, in general, to enhance accessibility.

3. Changing URLs for archived pages
All too often, Web sites change URLs of pages when they are outdated and move off the main page into archives. This can make it extremely difficult to build up significantly good search engine placement, as links to pages of your Web site become broken. When you first create your site, do so in a manner that allows you to move content into archives without having to change the URL. Popularity on the Web is built on word of mouth, and you won't be getting any of that publicity if your page URLs change every few days.

4. Not dating your content
In general, you must update content if you want return visitors. People come back only if there's something new to see. This content needs to be dated, so that your Web site's visitors know what is new and in what order it appeared. Even in the rare case that Web site content does not change regularly, it will almost certainly change from time to time -- if only because a page needs to be edited now and then to reflect new information.
Help your readers determine what information might be out of date by date stamping all the content on your Web site somehow, even if you only add "last modified on" fine print at the bottom of every content page. This not only helps your Web site's visitors, but it also helps you: The more readers understand that any inconsistencies between what you've said and what they read elsewhere is a result of changing information, the more likely they are to grant your words value and come back to read more.

5. Creating busy, crowded pages
Including too much information in one location can drive visitors away. The common-sense tendency is to be as informative as possible, but you should avoid providing too much of a good thing. When excessive information is provided, readers get tired of reading it after a while and start skimming. When that gets old, they stop reading altogether.
Keep your initial points short and relevant, in bite-size chunks, with links to more in-depth information when necessary. Bulleted lists are an excellent means of breaking up information into sections that are easily digested and will not drive away visitors to your Web site. The same principles apply to lists of links -- too many links in one place becomes little more than line noise and static. Keep your lists of links short and well-organized so that readers can find exactly what they need with little effort. Visitors will find more value in your Web site when you help them find what they want and make it as easily digestible as possible.

6. Going overboard with images
With the exception of banners and other necessary branding, decorative images should be used as little as possible. Use images to illustrate content when it is helpful to the reader, and use images when they themselves are the content you want to provide. Do not strew images over the Web site just to pretty it up or you'll find yourself driving away visitors. Populate your Web site with useful images, not decorative ones, and even those should not be too numerous. Images load slowly, get in the way of the text your readers seek, and are not visible in some browsers or with screen readers. Text, on the other hand, is universal.

7. Implementing link indirection, interception, or redirection
Never prevent other Web sites from linking directly to your content. There are far too many major content providers who violate this rule, such as news Web sites that redirect links to specific articles so that visitors always end up at the home page. This sort of heavy-handed treatment of incoming visitors, forcing them to the home page of the Web site as if they can force visitors to be interested in the rest of the content on the site, just drives people away in frustration. When they have difficulty finding an article, your visitors may give up and go elsewhere for information. Perhaps worse, incoming links improve your search engine placement dramatically -- and by making incoming links fail to work properly, you discourage others from linking to your site. Never discourage other Web sites from linking to yours.

8. Making new content difficult to recognize or find
In #4, we mentioned keeping content fresh and dating it accordingly. Here's another consideration: Any Web site whose content changes regularly should make the changes easily available to visitors. New content today should not end up in the same archive as material from three years ago tomorrow, especially with no way to tell the difference.
New content should stay fresh and new long enough for your readers to get some value from it. This can be aided by categorizing it, if you have a Web site whose content is updated very quickly (like Slashdot). By breaking up new items into categories, you can ensure that readers will still find relatively new material easily within specific areas of interest. Effective search functionality and good Web site organization can also help readers find information they've seen before and want to find again. Help them do that as much as possible.

9. Displaying thumbnails that are too small to be helpful
When providing image galleries with large numbers of images, linking to them from lists of thumbnails is a common tactic. Thumbnail images are intended to give the viewer an idea of what the main image looks like, so it's important to avoid making them too small.
It's also important to produce scaled-down and/or cropped versions of your main images, rather than to use XHTML and CSS to resize the images. When images are resized using markup, the larger image size is still being sent to the client system -- to the visitor's browser. When loading a page full of thumbnails that are actually full-size images resized by markup and stylesheets, a browser uses a lot of processor and memory resources. This can lead to browser crashes and other problems or, at the very least, cause extremely slow load times. Slow load times cause Web site visitors to go elsewhere. Browser crashes are even more effective at driving visitors away.

10. Forgoing Web page titles
Many Web designers don't set the title of their Web pages. This is obviously a mistake, if only because search engines identify your Web site by page titles in the results they display, and saving a Web page in your browser's bookmarks uses the page title for the bookmark name by default.
A less obvious mistake is the tendency of Web designers to use the same title for every page of the site. It would be far more advantageous to provide a title for every page that identifies not only the Web site, but the specific page. Of course, the title should still be short and succinct. A Web page title that is too long is almost as bad as no Web page title at all.

These considerations for Web design are important, but they're often overlooked or mishandled. A couple of minor failures can be overcome by successes in other areas, but it never pays to shoot yourself in the foot just because you have another foot to use. Enhance your Web site's chances of success by keeping these design principles in mind.

Happy Web Development....


courtesy @TechRepublic

Write a resume that will land you a programming job..PART 3

Watch your formatting

While technical pros’ resumes do not need to be pretty, formatting can make a huge difference in a resume’s readability. If you cannot put three pages of text in front of me in a readable form, do I really want you touching the UI or writing code that someone else might have to maintain?

I recommend that you stick to a larger font size (e.g., 10 - 12 pt.) in a font that reads well onscreen and in print (e.g., Verdana, Arial, Tahoma, Calibri, Helvetica). If you want a slightly fancier font, use it only for section headers. Also, do not mix Serif and Sans Serif fonts — that is just ugly. Do not use “Comic Sans” anywhere, especially in hot pink or baby blue (and yes, unfortunately, this needs to be stated). Keep your margins and space between paragraphs large enough to provide the reader some “breathing room.”

Employment history

I give applicants some slack on employment history. For instance, five year stints are fairly rare in IT, and I give anyone a lot of leeway if their history includes anything that occurred during the dot com boom/bust.

If you are (or were) a contractor or consultant, make sure that is clearly stated; otherwise, I will think that you get fired and/or quit every 3 - 12 months. If you were not a contractor or a consultant, and it looks like you have a hard time staying at a job, I am going to be very cautious. If I see an increasing progression of job titles, “mercenary” pops into my head. Also, if I see that they are lateral (or worse, negative) moves, “bad apple” is my first thought. Of course, sometimes you get hit with a string of employers that go under or get acquired — it happens to the best of us. If that is the case, find a way to convey that information so I don’t think you are unemployable.

Spelling and grammar

It is critical that the spelling and grammar in your resume is flawless. I have seen applicants misspell the name of their state and the name of their school. If grammar and spelling are not your forte, ask someone to look over your resume for you. While I understand that many IT pros are not native English language speakers (or are English language speakers who paid little attention to those subjects in school), you should still ask someone for help. In fact, knowing when to ask for help is a hallmark of the best developers. If I interview you and realize from your speech that you had the sense and humility to ask someone for help on your resume, I am going to be truly impressed. (For examples of what not to do, check out this list of real-life resume blunders.)

Stay out of EEO (Equal Employment Opportunity) territory

In the United States, companies with more than 10 employees need to follow EEO rules. These rules state that an employer cannot discriminate against or show preference for an employee based on certain group membership items or personal lifestyle issues, such as gender, age, ethnicity, nation of origin, religion, sexual orientation, and so on. So, do me a favor and try to not expose any EEO-related information to me on the resume. In a face-to-face interview or even a phone interview, some of it will be unavoidable. But I will never solicit that information. Not only do I want to keep my employer and myself out of trouble, but I personally feel that EEO is important. I can understand that many names (or even college attended) are strongly correlated with ethnicity, religion, or nation (or at least general geographic region) of origin, and college graduation or attendance dates give some age clues. Minimize this as much as possible. Please do not tell me about your church, your family situation, your home life, your parents, and so on. It is not that I am not interested — I would probably love to learn these things about you if we hire you — but I do not need or want to know them before that you come on board.

Outside interests, hobbies, achievements, and activities

I like to see these, but only if they are relevant. I really do not need to know about how big of a fan you are of the New York Knicks; but if you wrote a piece of software that can do something nifty with the team’s statistics for fun, I would love to know about it. People who contribute to open source projects get a huge gold star in my book, but only if I feel like they would be comfortable working on proprietary software with proprietary tools, and not bringing anything GPL’ed into my codebase. That is a small caveat there. “Contributed to project XYZ in the areas of ABC and DEF” is enough to whet my appetite. Show me some outside learning too — don’t let me think that you get home at 6;00 and shut off your brain. If this work is not interesting enough for you to read about or experiment with on your own time, why would I think that you will be engaged or even interested in the job we would hire you for?

Gracefully show your inner geek

Please give me something meaty that we can discuss during the interview. So, where it is relevant, try to show me how much of a nerd you are.

For instance, try to mention the hovercraft you made from an inner tube and a lawn mower engine. Make note of the iterative, evolutionary game theory system you coded in Lisp that proves that Nash’s equilibrium is dead wrong. Tell me something about your three chess championship victories. I do not want to know that you memorized UHF or that you have a pocket protectors collection that have logos of now defunct minicomputer vendors.

I know most of this falls under the previous section, but it is relevant. I love to work with programmers who love technology and logic and using their brains. People like that are simply better programmers. Why would I want to hire someone who is intellectually lazy for an intellectually challenging job?

Obscure or nonmainstream technologies

I am not hiring Lisp, Prolog, Erlang, APL, Scheme, Clipper, PowerBuilder, Delphi, Pascal, Perl, Ruby, Python (forgive me for including those four in this list), Fortran, Ada, Algol, PL/1, OCaml, F#, Spec#, Smalltalk, Logo, StarLogo, Haskell, ML, D, Cobra, B, or even COBOL (which is fairly mainstream) developers. If you show these on your resume, I will want to interview you just for the sake of slipping in a few questions about these items. I am serious. As part of my secret geekiness, I am really into obscure and almost obscure languages and technologies. I know that a lot of those items take better-than-industry-average intellect and experience to do; they also provide a set of experiences that gives their practitioners a great angle on problems. While you will never directly use those skills in my shop, you will be using those ways of thinking, and it will give us something to talk about on your first day.

(Aside: A coworker was shocked to learn that I played Half Life. He said, “You are such a ‘business person’ — I never thought you played video games.” I guess I’m camouflaging my secret geekiness too well!)

Good luck

I’ve given away crown jewels here. In my perspective, these tips will help any programmer write a perfect resume and get them an interview.

What do you think gets applicants an interview? If you read resumes as either a hiring manager, a recruiter, or an HR employee, what makes you say “wow!” or “ugh!” when you see it on paper?

source @TechRepublic

Write a resume that will land you a programming job..PART 2

Show me that you are different

Even if my project is a run-of-the-mill Web-based, data driven application (which it is not), I still want to see that you are more than someone with 10 years of experience writing run-of-the-mill Web-based, data driven applications. For example, compare these two items:

BORING!
East Coast Power - Programmer 1999 - 2005

* Wrote VB applications to control machinery. The hardware interface was handled in a COM library that was written by another team. Application was robust and reliable.
* Wrote Web-based tool to track system faults.
* Created Web service to allow partners to consume portions of the database.

WOW!
East Coast Power - Programmer 1999 - 2005

* Wrote VB applications to control nuclear reactor. Real-time control and monitoring of systems handling 10,000 unique data inputs per second.
* Wrote advanced algorithms in C# to detect imminent system failure, which were used within a Web-based application.
* Created Web service in C# to allow partners to access data in a secure, reliable, and responsive manner; typical data set was 1,000,000 rows and concurrency challenges needed to be overcome at the database and application layers.

See the difference? Control machinery does not help me much – you could have been working on the elevator system for all I know. Programming a nuclear reactor impresses me, especially since there has not been any nuclear reactor disasters during your employment. Writing advanced algorithms in C# touches my engineer’s heart; whereas writing a mere Web-based tool is ho hum. And, while writing a Web service is fairly simple, particularly in ASP.Net, it’s not so easy to write one that is “secure, reliable, and responsive” with that size of a data set. It’s also not easy to deal with concurrency issues at two different levels.

I am not saying that it needs to be wordy or full of minute details, but if you are doing work beyond what a summer intern could do, I need to know about it. Every developer has written a Web-based, data driven application. Show me more.

Make sure that your experience highlights your skills

I don’t expect your employment history to include a list of all your skills. But if you are looking for work as a .Net developer, show me that you have done some .Net work. If you do not list that experience, I am going to assume that you have little or no experience with it — even if it is on your skill list. If you have large amounts of experience outside of the workforce, find a way to show that on your resume.

Keep your resume between two to four pages long

I have struggled through seven-page resumes filled with jargon and boring details that made me want to cry. An overly long resume doesn’t necessarily make me rule out a candidate, but why make it hard on me?

On the other hand, a resume that tries to stick to the one page rule is not going to cut it for a technical person unless they are new to the field. In my experience, two to four pages is just right. Also, please use some whitespace, so I do not feel like I am drowning.
continued...

Write a resume that will land you a programming job..PART 1

I usually read 5 - 20 resumes each week. Both my boss and I are extremely busy, so it’s important that a programmer’s resume grab our attention quickly by providing the right mix of necessary information with something that makes that person stand out from the pack.

I’ve been involved with our hiring process for more than six months, so I feel fairly confident that I can distill what it takes for a programming resume to get me to say, “Let’s arrange an interview.” Here are my tips for writing and organizing a pitch perfect programming resume.

Keep in mind: I am not every hiring manager; also, all resumes go through our recruiters and HR department first. Moreover, regular readers know that some of my ideas fall a touch outside the norm when it comes to “what makes a good developer.”

Put your skills front and center

Reading the in-depth details of how you used mainstream skill XYZ to accomplish typical task ABC is not at the top of my agenda. I want to see your skills up front, so I don’t need to go trolling through your resume to see if you meet my minimum needs.

Skip the summary and maybe even the objective

Those summaries are a waste of my time. It is going to say something like “seasoned IT pro with great communication skills” or “proven veteran with 10 years of programming experience.” How do I know this? Because they all say this. Skip it, please.

The objective is a slightly different story; it is useful only if it informs the interviewer about something that the skills and experience does not. The objective’s relevance to me is largely a function of whether you wish to keep doing what you have been doing. If I see you have been programming — particularly at the data access layer and the business object layer — and there is no objective, I am going to assume that you are looking for more of the same with a different employer or location. If you want to do more of that work and put an objective, you are wasting space. If you are looking for a change of pace — like getting more into the presentation layer or heading towards a management track — it’s important to state that in your resume. Otherwise, we may discover during the interview that you are not interested in what we have to offer.

List your education last

Some IT hiring managers put a huge emphasis on certain educations but I do not. I always want you to list your school and your major, but I will only ask you about your education if there is something unusual or intriguing.

For instance, a candidate with a Computer Science degree from MIT or with a PhD in Organic Chemistry will draw my eye because these degrees show a level of high intelligence. On the flipside, an AA in basket weaving or a lack of a degree will not count against you.

In most cases, I am not even curious about your education until I have already made up my mind. This includes certifications — MCSEs and CCNAs do not impress me that much at this point. They matter to some folks, and they do not hurt you in my opinion, but I will only take that certification into account if all else is equal.

continued...