Stories by Ed Yourdon

Can XP projects grow?

After a disastrous infatuation with computer-aided software engineering (CASE) tools in the early '90s, most IT organizations realized they had put too much faith in "silver bullet" tools, and decided instead to emphasize a combination of people and processes. At one extreme, we have "heavy" processes combined with "light" (inexperienced) people; at the other, we have "light" processes and "heavy" (experienced) people.

Can XP projects grow?

After a disastrous infatuation with computer-aided software engineering (CASE) tools in the early '90s, most IT organizations realized they had put too much faith in "silver bullet" tools, and decided instead to emphasize a combination of people and processes. At one extreme, we have "heavy" processes combined with "light" (inexperienced) people; at the other, we have "light" processes and "heavy" (experienced) people.

Spelling success

I learned an important lesson in my IT career years ago, when I accompanied a veteran colleague to a project kick-off meeting. Someone else was in charge, but my colleague took advantage of a brief moment of silence at the beginning of the meeting.

Software, the 'E' Way

E-business has changed more than just the way businesses interact with their customers. In some cases, it has also changed the basic principles and assumptions of software engineering processes and methodologies. For example, Barry Boehm first provided us with the insight, in his 1981 textbook, Software Engineering Economics, that if a software engineer made a mistake during a project's systems analysis phase by misstating or overlooking an end-user requirement, it was 10 times cheaper to identify the problem while the project was still in that phase than to allow it to go undetected until design. If that same error remained undetected until the coding phase, it would be 100 times more expensive to fix than if it had been found when it first occurred.

Net legacy nightmares

Despite the exhortations about the Internet's revolutionary nature, IT organisations are learning the old maxim, "The more things change, the more they stay the same". Project managers have already learnt that they ignore such basic
software engineering principles at their peril if they succumb to the pressure of "Internet time" when building a new Web application. Now we're seeing another aspect of "déjà vu all over again": the emergence of Internet legacy systems.

‘Viewing' the project

It's an old joke that IT development projects are on track until a week before the deadline, at which point the customer discovers that the project is really six months behind schedule.

Finding bottlenecks: Opinion

At a recent corporate IT meeting, I heard an interesting observation from a group of managers looking for ways to reduce their projects' time to market.

Finding Bottlenecks

At a recent corporate IT meeting, I heard an interesting observation from a group of managers looking for ways to reduce their projects' time to market. They said the biggest bottleneck in their development process wasn't the usual activities of analysis, design, coding or testing. Instead, it involved delays in approving contracts for relationships with vendors, subcontractors and strategic partners.

The Value of Triage

Most project managers understand the need to prioritize the list of requirements that end users provide at the beginning of a development project. After all, with today's compressed schedules and personnel shortages, it's unrealistic to promise users that all their requirements will be implemented by the deadline.

People and Projects

Whether it's a new e-business project, a start-up venture or just a "plain-vanilla" systems-development undertaking, every project today seems to be a death march: The system must be built in half the time that was scheduled or with half the staff or budget. Such projects were an anomaly through the mid-'90s, but then, the pressure of Y2k projects and the explosion of e-business turned everything into a death march.

Y2K Success Lessons

There will be several Y2K post-mortems in the coming months. Some will assess the costs of Y2K projects and the damages associated with Y2K failures. Others will investigate the puzzling success of less-prepared countries and unprepared small businesses. But the most useful form of post-mortem for IT managers will focus on the reasons for success, especially in the organizations that took Y2K seriously, spent an enormous amount of time and energy on remediation and testing and subsequently discovered that it had all paid off.

Guest column: Data corruption: The silent Y2K killer

Whenever we think about Y2K failures, we tend to focus on the "visible" problems -- for example, the embedded systems failure that causes a refinery to explode is "fix on failure." Meanwhile, there's another Y2K failure that's far more insidious, one that will require attention and resources throughout next year: the data-corruption problem.

Column: The Moral Dimension of Y2K

It's now late December, and you're on your way out the door, ready to enjoy the holidays before 1999 begins. But it may be your last holiday for quite a while. For most of us in the year 2000 world, 1999 will be the year of living dangerously.