The sad reality is that most developers in the real world are lousy at what
they do. The reasons run deep but that's another issue. While you improve
your chances of finding a better developer if they have the title "senior"
next to their name (and can back it up), the fact is that even most senior
developers aren't very good (and frequently worse). Finding a developer who
really has the breadth of knowledge and skills to write polished code is a
crapshoot. There aren't many around and chances are you won't even know it
until after you hire them (or in some organizations they may already be
there but are never recognized). I completely agree with your point about
their value however. If you do find one then they're well worth the money
(assuming management truly understands much $ they can save over the course
of a project's life - alas this too is rare however).

[snip]

Sorry, but I disagree. A "professional" developer isn't going to think of it
in terms of being fun or not fun. He's going to think of it in terms of
what's the best way to get to the end. If the starting point is a bunch of
messy code, then the end point may be reached quicker by rewriting from
scratch.

Having inherited some really bad code in the past, I know for a fact that
sometimes rewriting from scratch is the best ("best" being defined as, gets
me to a working product the fastest) solution. Without seeing what's already
there, this is all speculation, but a good developer will know which way is
the best and the hiring company ought to respect that. But they can only do
that if they trust the developer, and it's hard to trust someone who just
walked in the door, so it's a bit of a catch 22 where they are right now.

Even stuff I've written for my own uses, if my requirements change
significantly, sometimes it requires a complete rewrite, or virtually
complete rewrite. I don't think of it in terms of what's more fun, though. I
think of it in terms of what's going to get me to the product I need the
fastest. Fun for me is getting it done so I can move on to the next thing.

What definitely isn't fun is spending weeks on end trying to adapt a mess of
code to do some simple little thing that ends up breaking the whole thing
because there's no adaptability in the code or the logic is just so fouled
up and hard to follow that small changes break things.

You can waste a great deal of time trying to patch this code together with
band-aids, but sometimes it's a lot faster just to write it over from
scratch.

Hi Fugutiveguy,

I thought about letting this go - but ...

RE:
<< A side effect of this is that a developer is not loyal to you or the
company and will leave for more money at the first opportunity. >>

This is very cynical about human nature. While such cynicism is frequenly
warrented, at least give people a chance. If you treat someone with respect
and with fairness (including and beyond $ compensation), then you will
likely gain their loyalty.  If you under pay them as compared to their
market rate (given region, experience, skillset, and market demand), then
you can expect that they would leave sooner rather than later - but that's
your fault for being cheap and not necessarily greed on the part of the
developer.

RE:
<< I saw that one replier advised you, "if the new developer wants to
rewrite the program from scratch, let them".  I hope that raised huge red
flags with you.  This is the classic developer response to any existing
project. It is the most fun for the devleoper, but it is also the most
expensive for the company >>

It's not about FUN; instead it's the path to (1) the fastest project
completion; and (2) a better final product. Granted, it's NOT a knee-jerk
recommendation [to start over]. A new-to-the-project developer should look
at the existing system to see if there is anything that can reasonably be
leveraged - including db schema, code, docs, etc.

One thing your advice gives zero credence to is the *enormous* gap between
the quality of work of a competent developer and a screw-up ("junior
programmer."). There are huge implications for meeting deadlines and
expected due dates if given a poor body of code to build on. Given a
complete "rats nest"of code, it becomes impossible to predict timelines with
reasonable accuracy. Ever heard of "jello code"? - it's code where you touch
it here and it wiggles over there. It's that "wiggling over there" that can
be disastrous for predicting timelines, runtime stability, date integrity,
etc. Junior programmers are likely to introduce race conditions and other
such bad things - and do so ALL over the place. So rather than starting out
with a blank page and getting it right the first time, your advice would
have the OP here believe that it's actually faster to start with a mess that
must be cleaned up (which can be time consuming) before moving the project
forward.

RE:
<< The way that you do this is with requirements and schedules. >>
and
<< You need to schedule deliverables >>>

So what happens when schedule are based on faulty assumptions, incomplete
requirements, or misunderstood data? Placing the responsibility (and
ultimately "blame") on the developer is unreasonable given that developers
get their requirements from end-users (including business management at the
highest levels) who frequently don't clearly understand what they need or
want or what the correct meaning of their own data is. It is common for a
client to learn more about their own data and business processes than they
ever knew prior to the initiation of a major software development effort.
With this increased knowledge comes changes to requirements. And with those
changes, schedules go out the window unless revised. This evolution in
requirements and associated invalidation of prior estimates isn't anybody's
"fault" - but rather an expected course of events that comes out of a
business becoming more knowledgeable about (1) what they are actually doing;
and (2) what technology can do for them.

RE:
<< You need to schedule deliverables.  The schedule should be set up with
the input of the developer.  Break the project up into its components.
Things like database schema, screens, areas of functionality.  That way if
the developer leaves in mid project you don't have half of a project that
doesn't work, you have the basis of a whole project and the next developer
can come in and add to it. >>

Again, that advice is based extensively on the assumption that the existing
work is of acceptable quality and *can be* leveraged, neglecting the reality
that that is is a rare thing to have happen.

Covering oneself in case a developer leaves is a great idea, but there are
effective ways to go about it that don't rely on illusions created by
arbitrary timelines.

This idea of "break the project up into its components" -- with the
implication that they can be thought of as independent sub-projects and
therefore assigned independent schedules and due-dates -- is completely
naive. Major components of a system cannot be designed and built without
impacting other areas. It's a rare and tiny change to one part of a system
that doesn't somehow impact another part of the system. Yes, we should be
able to change db schemas, for example, but then the DAL would need to get
modified - even if the upper-level UI layers aren't broken (which they
shouldn't be if proper layering is going on) the UI would likely need to get
modified in some way to allow acces to new tables, stored procedures, etc...
new screens, modified screens, additional reports, modified reports all come
into play.

Finally, consider this quote in the forward to the book: Database Design for
Mere Mortals (by Hernandez): The forward is by Ken Gets - a well-known
industry expert:

By Ken Gets:
"I knew this was the book for me when I turned to the beginning of chapter 6
and saw this suggestion: Do not adopt the current database structure as the
basis for the new database structure."

Of all the things Mr. Gets could have written about the book, he picked that
one.

Turning to chapter 6 ... "This is a particularly bad idea [in reference to
leveraging prior database structure], because imported errors are the most
difficult to identify." ... "The danger posed by this line of thinking is
that any "hidden" problems within the current database will be transferred
into the new database."

He goes on and on, then... "After all, if the old database didn't have any
problems, you wouldn't be building a new one."

Apparently I'm not the only industry expert who disagrees with your
suggestion that existing work should be leveraged.

The decision about starting over (or not) has everything to do with
economics. Again, it's not a knee-jerk reaction to start over. But it's
typically the most economical way to get a good and reliable system with
trustworthy data.

-S

A "detailed spec" is theoretical nonsense that exists almost nowhere in the
real world. Software development is an iterative process where the *real*
details don't become clear until coding is underway. The volume of
information is also so overwhelming in most cases that properly documenting
it ahead of time is a near impossibility even if you had this information
from the outset. Moreover, screen mock-ups and/or many pages of high-level
documentation does *not* constitute the program's actual design at the
coding level. Nor does it address the thounsands of details that programmers
must ultimately deal with. Most such documentation is also (usually) very
poorly written by both the inexperienced and experienced alike, is extremely
superficial (usually), is in a constant state of flux, and simply becomes
indigestible for most human beings beyond a certain point. I have yet to see
a "detailed spec" after 25 years and more than a dozen companies (from the
very small to the very large)

See previous point.

A re-write should be avoided at all costs but it may become necessary if
your first group of developers botched the job beyond repair. If so then
you're either forced to face this grim prospect of a complete or partial
re-write or otherwise proceed with the existing mess at the cost of unstable
software (and by extension many years of very expensive maintenance)