It could be bad luck and a series of bad developers, but I think that
this is the root of your problem with the project.
There is no magic formula for managing developers, but if you think
of them as skilled craftspeople who are being paid to do a job you'll
go far.
Developers are not management and will not share in the huge bonuses
that management gives themselves. A developer will get paid the same
if the product is a moderate success or a huge success. 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.
There is nothing wrong with this situation, I'm sure your company has
many workers in other areas who are exactly the same and nobody loses
sleep over it. As a manager, you have to protect the company from
employees who leave before a project is finished.
The way that you do this is with requirements and schedules.
I'm not advocating micro management, but you should have a detailed
spec showing the developer what the final product is supposed to look
like and what functionality it should have. If you give a developer a
1 line spec, then you should not be surprised that the developer's
vision and your vision don't match.
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.
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.
You need to look at the state of the project, break it up into
components, and determine what works and what needs to be redone. And
then let the developer go from there.
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