[OT] Programming practice question

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.

But you’d save time in the long run if you stepped back, reviewed your
code, and reorganized it in a cleaner fashion first. But you don’t
have time to do that now, due to tomorrow’s deadline.

What do you do?

Personally I would get to the deadline writing one more days worth of
untidy
code - because lets face it, if it’s that bad, that it can not be
rectified in one day,
another day is not going to make any difference.

I would then do a code review after the said milestone and isolate the
main
areas that are of ‘issue’ and then concentrate on refactoring the code
so as to
improve it. As is the nature with refactoring, things should cascade
until you
reach a point where you either have to stop - in which case the code
should
be even slightly better, or because the job is complete in which case
the code
is better. If this is done in parallel [ie. with a view of the planned
future
development of the code] then you should not loose too much time and
would be in line for a better engineered product. Although having said
that,
it’s also important that you apply the correct refactorings.

Another point to consider is this: does the system have to be maintained
or
is the code being developed for a one off tool to solve a one off
problem? If
it is, then I do not [personally] feel that a beautifully engineered
code base
and solution is necessary - yes it is good practice, but really when
push comes
to shove - you are up against a deadline and deadlines are hard to keep
at
the best of times without adding to the work. |f it isn’t then it is
definatly
important to make sure that things are maintainable.

But, this is all my initial thoughts on the question,

Regards,

Chris

···

On Tuesday, August 13, 2002, at 12:03 pm, Philip Mak wrote:

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.

But you’d save time in the long run if you stepped back, reviewed your
code, and reorganized it in a cleaner fashion first. But you don’t
have time to do that now, due to tomorrow’s deadline.

What do you do?

(Writing this without looking at any previously offered answers…)

It depends on the metric. What happens if I don’t finish tomorrow?
Do I get fired? Does my company lose revenue? Does a customer back
out? Or maybe something less severe; I get a “ding” on my status
report, or my boss/manager gives me a scowl.

That sort of thing usually drives my decision in a situation like
this.

···

— Philip Mak pmak@animeglobe.com wrote:

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.

But you’d save time in the long run if you stepped back, reviewed
your
code, and reorganized it in a cleaner fashion first. But you don’t
have time to do that now, due to tomorrow’s deadline.

What do you do?

=====

Use your computer to help find a cure for cancer: http://members.ud.com/projects/cancer/

Yahoo IM: michael_s_campbell


Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com

“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