Journyx Project Management Blog

Top programmers are not easy to find. It takes time to cull through dozens, if not hundreds, of resumes to find the magic combination you want, and it takes hours to perform interviews. After all of that, you still need to jump through hoops to make sure that your best candidates accept your offer rather than someone else’s.

Yet all too often, these hard-to-find (and hard-to-hire) employees are neglected once they come on board. While proper compensation is, of course, a large part of employee retention, the top programmers need more than a great pay check. Here are 10 reasons why your star programmer might be looking to leave, and what you can do to convince them to stick around.

#1: Poor pay
No one works purely out of a charitable nature. So when your best people feel like their pay is severely out of line with market standards, they may start to view other pastures as being much greener than yours. Your worst enemy in retaining the stars is the thought, “I am the worst paid senior developer in this town.”

I see a lot of companies that look at what the market is like only when they hire someone. Meanwhile, your best people are often aware of what is happening in the market consistently. If you have not re-evaluated your pay packages in a while, you need to. While the package may have been competitive when you hired someone three years ago, your best employees may be able to get a substantial raise by making a lateral move (if not taking a higher level position) to another employer.

#2: An uncertain future
The best people often have no intention of leaving until something out of the ordinary prompts them to stick their toes in the job market waters. At one company where I worked, the trigger for a mass exodus was the sale of the building our employer was renting to a major company that obviously was not going to keep leasing to us. A lot of people panicked and wondered whether the loss of the office space would prompt a move of the operation to another city. Instead of sitting around waiting for the other shoe to drop, they left. At another company where I worked, a large layoff spooked those who survived, and they left as soon as they could.

There is little you can do to prevent these outside influences from occurring, but you can do a lot to reassure your people when they do happen. Your best programmers are not dumb; they know when you are trying to puff them up with hot air instead of being forthright. When these events happen, give your people the straight truth and show them what you and the company are doing to prevent the need for your stars to lose their jobs. It’s a tough path to walk, but too many managers cave in to the temptation to cover up the problems — and those cover-ups tend to drive people out even faster.

Read the rest at TechRepublic.

The original deadline for our software project had come and gone, and every week the new finish date was sliding farther into the future. The Vice President of Development decided that he needed to call a project summit meeting, bring the finish date in sooner, and nail down a schedule once and for all. He called all the important managers (but none of the programmers) into a room. They shut the door and vowed not to emerge until they had shortened the schedule.

One of the managers laid a rock on the table, solemnly turned it over, and said they should “leave no stone unturned” in their effort to shave time off the schedule. They re-examined each task in the project list, shortened many of them, made some tasks concurrent, and eliminated a few others. They emerged several hours later with a tightened schedule, and an earlier end date.

All the managers were happy. They had accomplished their goal of shortening the schedule.

In hindsight, it is not surprising what happened: The managers’ effort was a waste of time. The new schedule had no effect on the pace of development at all. The project was finished at the about the same time it would have been, except that five or six highly paid resources wasted a half-day looking at a rock in a room.

Read more at Developer.com.

The senior White House IT official, Karen Evans, said she believes software as a service (SaaS) can improve government IT projects and systems.

Evans made her remarks during a talk at the Saas/GOV 2008 conference. From InfoWorld:

“Our track record is clear — we are not very good at delivering our own software in the time frame set,” Evans said at the conference. “We’re also not very good at managing large projects.”

Some agencies haven’t embraced the service approach, often because they want hands-on control of software development, Evans said. But government agencies can’t afford to keep developing their own software without sharing with other agencies, she said.

“We can’t continue to maintain all of the things we have,” she added. “We have to start shutting down some of our legacy systems. We really have to move to a … service-oriented market.”

Read more at IT Project Failures.

In this article, I will try to tell you a way you can tackle one aspect of a project—software estimation. I will tell you how I estimate projects and the geometry involved, and if unfettered by poorly judged external forces this way leads me to a successful delivery. But, the most important thing is that these are general guidelines and there is simply no substitute for individuals and teams that can succeed in their own way. Individuals and individual teams must be permitted to use their own judgment, for there is no more desirable outcome than a delivered and well received product. (Until software becomes an assembly-line process and by then, God willing, I’ll be horizontal.)

Geometry

Geometry applied in the context of software development project estimation refers to the size, shape, and relationships among all of the elements of a software project, including those practices whose direct result are tangibles and those time slots that are essentially intangible but necessary in some way. Many estimators get some of the tangible parts of estimation correct, but it is all of the intangible aspects that are often overlooked and result in delays, disappointments, and undelivered software.

Tangible elements (often called deliverables) can include project plans, requirements, detailed designs, the software, and time spent testing, debugging, documenting, and launching software. Many people know about these elements and some include these elements in estimations. Sadly, some do not include all of these elements. Intangibles such as water cooler time, illness, bad requirements, wrong requirements, changed requirements, unforeseen hard bugs in your code or the tool provider’s code, learning, white board time, unit tests, arguments, meetings, distractions, failed or replaced hardware, absenteeism, car accidents, sustainable productivity levels—getting in and staying in “the zone”—reading FoxNews.com, checking out research.microsoft.com and more, are all too often overlooked, dismissed, or denied. But, these are the elements as likely to happen as coding that chew away at the schedule, willingly or not, and is what is most often overlooked in a project schedule. To account for the tangibles, methodologies like RUP were invented. To account for intangibles, methodologies like XP and Scrum were invented. But, again there is no substitute for having people who have demonstrated an ability to deliver.

Tip: Software projects that succeed often have a single-minded determination and focus on the number one deliverable, the software.

Read the entire article at Developer.com.

Quality in software development projects doesn’t happen on its own. It also doesn’t occur after a small group of heroes rides in on white horses and waves its shiny swords to vanquish the problems. Quality happens only when careful planning is done, when the entire project team maintains a quality-conscious approach every step of the way, and when problems don’t escape from the phase in which they were introduced. A quality product is a team effort. It’s planned and predictable. It’s without heroes, and it’s faster and cheaper than a low-quality effort.

How can this be? Let’s look at some sample projects. The first is a normal, low-quality, late project. We’ll call it project “Hurry Up” (HU for short).

Project HU got a bit of a late start due to the ongoing maintenance issues of its predecessor project “Just Ship It” (JSI). JSI was handled by a project manager (PM) who felt it was more important to ship on time than to ship a high-quality product. So he did. This PM was rewarded for his ability to “pull it together,” “get it out the door” and “meet the schedule.” The JSI PM was given a bonus for meeting his schedule and is now vacationing in Tahiti while the team deals with the fallout of the numerous bugs and unhappy customers.

Lesson #1: Don’t reward for shipping on schedule. Anyone can ship garbage. Base rewards on quality metrics.

During the last month of the project, the JSI developers worked 80-hour weeks. One heroic fellow was recognized for working 120 hours in one week, stopping only for brief rests. He heroically repaired multiple interfaces between applications. Those interfaces had not been properly specified (there were no design documents), no integration testing was done (no time to do it), and the QA team fought quality issues throughout system test.

Read more at CIO.com.

Productivity and software quality are topics of perennial interest to IT professionals. Measuring quality is a fairly straightforward process after all, defects are easily countable. But productivity is not so easily quantified. As a result, productivity metrics vary.

Productivity is often expressed via ratio-based metrics like lines of code per staff month or hours per function point. While useful, these measures have one significant limitation: they don’t account for the time frame in which the software is developed. Essentially, they measure cost efficiency rather than the time to market. Unfortunately, it serves little purpose to excel at technical productivity (e.g., saving money) if you miss a marketing window.

So, how do we define productivity, and where do we get the information? Quantitative Software Management, Inc. uses its SLIM software tools and consultative approach to capture the management numbers that enable organizations to effectively estimate, track, and benchmark their software development and maintenance projects. The company maintains a database of some 7,000 completed projects. The data in this article is taken from the QSM Software Almanac: Application Development Series. Organizations submitted data from 536 IT projects sampled from 31 companies in 16 countries, including 16 industries and nine sub-sectors, ranging from Aerospace to Financial IT.

Read more at: Project Times

In a recent blog, Nicholas Carr writes that “large companies appear to be jumping en masse onto the software-as-a-service bandwagon, according to a new survey of CIOs by management consultants McKinsey & Company. The survey found that 61 percent of North American companies with sales over $1 billion plan to adopt one or more SaaS applications over the next year, a dramatic increase from the 38 percent who were planning to install SaaS apps in 2005.”

This conclusion should not surprise anyone who’s been watching the sales increases at Salesforce.com or the growing traction of newer SaaS players. What’s significant is not that SaaS is growing, but that SaaS is gaining acceptance within businesses that rejected SaaS only a few years ago. Indeed, I remember a meeting at a particular company back in 2003 when I was told that “We will never use an application we don’t own.” In 2006 that company implemented three SaaS-based applications. So, I guess you should never say “never.”

In addition to the data points from the study Carr cites, other industry analysts are coming to the same conclusion

Read more at: The Intelligent Enterprise

In the traditional waterfall model of software development, the first phase of requirements analysis is also the most important one. This is the phase which involves gathering information about the customer’s needs and defining, in the clearest possible terms, the problem that the product is expected to solve.

This analysis includes understanding the customer’s business context and constraints, the functions the product must perform, the performance levels it must adhere to, and the external systems it must be compatible with. Techniques used to obtain this understanding include customer interviews, use cases, and “shopping lists” of software features. The results of the analysis are typically captured in a formal requirements specification, which serves as input to the next step.

Well, at least that’s the way it’s supposed to work theoretically. In reality, there are a number of problems with this theoretical model, and these can cause delays and knock-on errors in the rest of the process. This article discusses some of the more common problems that project managers experience during this phase, and suggests possible solutions.

Dodge the bullet at:
http://journyx.com/rss/redir/trepublic-fiveerrors.html

The compiler removes them completely. The computer ignores them. Some developers think we should do away with them entirely. But in the grand scheme of software development, I personally think they have a very important part to play. What are they? Comments, of course. Now, that’s not to say that all comments are created equal, or that you should just sprinkle your code with comments without thinking about what you’re doing. But in my experience, good developers recognize that comments are a useful tool, and employ them to make code more clear and maintainable. With some practice, you can do the same.

Read more at: Developer.com

While agile software development may seem straightforward at first, the transition period can be particularly challenging. In this transition, many companies face unique challenges and make mistakes. Most of the available literature concentrates on what steps to apply for a successful transition, yet little has been said on what to avoid. In this article, I explore the 10 most common mistakes in the transition from legacy development methodologies to agile. Like land mines, these mistakes are easy to make and are things that every software-development manager should try to avoid to achieve the greatest return on this important investment.

Mistake 1: Go All In

Months of discussion and e-mail threads are finally gone and it’s been decided that agile is the right thing for your organization. Be bold. Do not start with a pilot project; that’s for people who have all the time in the world. You run multiple projects and you have no time—pick a big and risky project or force this new methodology to all projects simultaneously. If you find yourself looking for a good disaster candidate, try to find the one with a new technology and/or a tight deadline. Because you won’t have time to learn from mistakes, something pilot projects are specifically conducted for, you’ll multiply them in all teams putting your agile initiative in life support.

Read more at: Dr. Dobb’s Portal