David Chandler's Journal of Java Web and Mobile Development

  • David M. Chandler

    Web app developer since 1994 and Google Cloud Platform Instructor now residing in Colorado. Besides tech, I enjoy landscape photography and share my work at ColoradoPhoto.gallery.

  • Subscribe

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 223 other followers

  • Sleepless Nights…

    October 2005
    S M T W T F S
  • Blog Stats

    • 1,029,897 hits

When Wishes Come into Conflict with Reality

Posted by David Chandler on October 19, 2005

“We don’t have time to do it the right way!” a software development manager recently told me, “because we have to deal with the reality of a looming deadline.” (Never mind that doing it the right way would allow us to do it only ONCE, thus conserving time down the road. And never mind that doing it the right way will result in higher quality, which always saves time).

I expect to hear this old fallacy from some project managers and client representatives, but not from a development manager. What is the fallacy? As far as the actual software completion date is concerned, deadlines are WISHES, not reality. The actual completion date cannot be known with absolute certainty in advance. That is REALITY. I once had the pleasure of working with an IT Director J.P. Besong, who articulated the fundamental truth of software projects that still seems to elude most software project managers:

When wishes come into conflict with reality, reality wins.


2 Responses to “When Wishes Come into Conflict with Reality”

  1. talltodd said

    Yes I’ve heard this before as well. However, the “right” way is the best way given the paramaters that need to be meet (i.e. time, cost, quality, people). But there is almost always more than one right way. And if one “right” way is better but has an effect on a particular paramater then the value of “breaking with reality” needs to be greater that “sticking with it.”

  2. Yes, the “right way” must take many factors into consideration. By the “right way,” I was referring to good programming practices such as those embodied in The Pragmatic Programmer, which transcend particular languages and technologies. I don’t think there is ever an excuse for ignoring principles such as DRY (Don’t Repeat Yourself). The cut and paste anti-pattern always leads to poor quality and more work, even in the short term. Unless you get it perfect the first time and never touch the code again. But that’s certainly not reality in the company I work for.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: