"Philip Mak" <pmak / animeglobe.com> wrote in message
news:20020813110352.GL5036 / trapezoid.interserver.net...
> Suppose you're programming some system. You have to reach a milestone
> tomorrow.
>
> Your code is kind of messy right now. You can reach the milestone on
> time if you write more messy code.

Depending on the development infrastructure and the nature of the deadline
you evaluate what you think is best. Then write up that recommendation with
pro/con to management and/or other involved parties. This makes it possible
to make an overall informed decision that prioritizes resources. You
wouldn't say that you code is crappy, but that given the circumstances there
is an increased risc of introducing bugs or endangering future milestones
doing so and so.

As a mean of reaching a deadline it may be beneficial to cut features if the
deadline cannot be made comfortably otherwise. Just pushing features is
pushing bugs into the system and the end result is less useful features and
a lot of stress on QA that could have been spent better. In this light it is
better to make sure that what you do have is working and make the deadline
instead of considering the feature list of the deadline as carved in stone.
This also has the benefit that you actually have something working at the
deadline which prevent long running projects that keeps getting delayed.
Some of the features that were missing may turn out not to be that important
after all. This is a kind of cost averaging features (like dollar averaging
investments in uncertain stock markets).

The above need not apply to management - it can also be in relation to a
trusted customer: This is the situation - we can do this with increased bug
risc, we can delay, or we can prioritize features and schedule a next
release. Often a specific deadline isn't exactly important, or some features
aren't really that important. Everybody is more happy with working code and
the customer may even be happy about getting more involved and have a
feeling of participation. It shouldn't be a pillow for continously sliding
schedules, and the re-prioritized release should deliver what is agreed.

In these priorities it is important to focus on the bug risc and risc of
future failed deadlines, not the beauty of the code. It is dangerous to
delay projects due to some perceived problem with the code because it
doesn't use that visitor pattern that really would make the code easier to
generalize if it should be necessary some day. The problem is that it will
never be good enough. This is where some talented people fail to be good
software engineers.

Mikkel