Questions about hiring .NET developer

[egaskill]

So we have a fairly small internal company application written in PHP,
it interacts with a MySQL DB and all it really does is create new
orders, edit existing orders, and prints reports based on different
variables in data. I don't know why this project has turned into such
a huge ordeal, but every developer we've hired so far to take care of
this project has come up short on the deadlines they themselves have
put forth. The last guy we hired came in and started rewriting the
PHP site in .NET and we have since had to let him go.

Now, we aren't a huge company, we have 35 employees total and maybe 10
of which use the company intranet simultaneously, so it's not really
in need of any crazy layers yet. I've been interviewing new
developers for this, and they all seem to say "Oh this is a really
small project", but I'm just worried (mainly for the sake of my job)
about hiring another guy that says that then wont be able to finish
it. I need to know if there's anyway to get a good estimate of time
on how long it should take to finish the almost complete new .NET
intranet site and how to pick out a guy that isn't going to screw us
over again (is all I have to go by references and qualifications?).

Also, any tips on managing a developer would be appreciated.

 

[Guest]

If I were you, I'd consider spending less time listening to potential hires
telling you all about what they can do, and instead, ask them to show you
real examples of similar projects that they HAVE ALREADY DONE.
-- Cheers, Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[Smithers]

RE:
<< I need to know if there's anyway to get a good estimate of time on how
long it should take to finish the almost complete new .NET intranet site >>

You should not make any assumptions about the state of the new .NET intranet
site. If you think that it is "almost complete" which is what you wrote,
then you are likely setting yourself up to get screwed again. Here's why:
chances are that you have been hiring incompetent developers. If you finally
get someone in there who knows what he/she is doing, then he/she will almost
certainly want to start over from scratch and get it right from the
outset... rather than building on a bad foundation. Furthermore, if you hire
someone who is very good, and he/she tells you that he/she should start
over, then let that happen. Odds are that they will finish much more quickly
than if they were required to "leverage" the crappy prior work, and you'll
have a better product in the end.

Finally, about estimates: creating good estimates requires YOU [the
customer/end user] to do a good job of communicating the requirements
clearly and decidedly. Whenever you change the requirements (which happens
all the time), then any prior estimates automaticaly become invalid. This is
such a typical scenario: You ask me how long I'll take to accomplish X, Y,
and Z. I tell you N hours. Then you later modify Z or add new requirement K.
You then expect N hours to still hold true. Sounds stupid doesn't it?
Happens all the time.

Sorry if all of the above sounds negative or even rediculous... but it's
what I've seen for the past 14+ years as an independent consultant. I've
made a TON of money over that period cleaning up after screw-ups. Here are a
few lessons/rules, heck "Laws" of IS hiring that I believe to be totally
true. You should pay attention.

You get what you pay for. It's actually worse than that: The
cheaper-by-the-hour programmer is BY FAR the most expensive person you could
hire. Get a screw-up in there at $20/hr and watch him fritter away 100 hours
on a project and never quite gets it right (i.e. never *finishes* the job).
Then hire someone truly competent at $80/hr and watch him/her *finish* the
same project in 15 hours. Just with those numbers alone the competent
developer is DONE at $1200 AND sooner than the screw-up who has cost you
$2000 and STILL isn't done! Yes - those numbers are realistic. The costs of
the screw-up go WAY UP beyond his/her immediate costs if their crappy
product gets into production where it will likely perform slowly and suffer
data integrity problems. You then have to add [to the total costs of the
screw-up] the lost productivity of your employees. And, if your data is
truly important, then you will eventually need to hire a competent developer
to come in and redo everything from scratch. But you won't get away for that
initial 15 hours because; rather than starting out at "ground zero", you are
starting out the competent developer somewhere BELOW ground zero. That is,
you would then have to pay your competent developer to [at least] clean up
the problemmatic legacy data in addition to creating the replacement
solution.

Let's review
Option 1 - hire competent developer initially:
Cost 15 hours - DONE (and with a good and reliable solution)

Option 2 - hire a "junior programmer" (i.e., *guaranteed* to be a screw-up)
Costs:
100 hours (the point at which you stop the bleeding) project still not
done
+
Lost productivity costs (if the crappy project made it into production)
+
Data cleanup effort (at least) on the part of the replacement competent
programmer
+
New project from scratch (if done by a competent developer would be FAR
cheaper than trying to "leverage" a pile of crap left behind by the screw-up
(I mean junior programmer).

Again, this is what goes on ALL the time. Given your post here, I suspect
you already know what I'm talking about.

About your hiring decision (to finally answer your specific question):
There is no magic bullet for you. But you might consider doing a variation
of a scenario I went into in 1999. I was interviewed for a contract position
with a Big Bank. The group in the bank was nervous in a way like you
apparently are. Same scenario. They had recently gotten rid of the 2nd
person hired to extend an existing system in some very specific ways. They
didn't want to get screwed again. So after I went through 4 separate
interviews (from technical to "is this guy a good fit for the team" sorts),
I was offered a TWO WEEK gig. Specifically, they told me that there were two
known bugs in the production system. I had two weeks to (1) find both bugs,
(2) satisfactorily remediate each, and in a way that would pass technical
review (with flying colors) with other developers on staff. IF I was able to
do that, then I was to get a 3-month contract to extend the system per the
new requirements that the prior two developers had choked on.

You could do someting like that. Maybe not as intense, but make 'em perform
before getting too far with them.

-HTH

BTW: Prior to getting my interview with Big Bank, I had one headhunter tell
me I was too *unqualified* to work for Big Bank and that I would need more
years on my resume. Another headhunter got met the interview. After the
2-week gig I nailed the 3-month contract and ultimately waltzed out of Big
Bank nearly 6 years later... serving in the role as "technical lead" for the
last 4+ years of my time there. Lesson for you: What's in a resume can be
meaningless... whether it makes the candidate look overly qualified or
overly green. The upshot: Make 'em perform - actually do something and
evaluate that result.

-S

 

[Larry Smith]

<< I need to know if there's anyway to get a good estimate of time on how

long it should take to finish the almost complete new .NET intranet site
You should not make any assumptions about the state of the new .NET
intranet
site. If you think that it is "almost complete" which is what you wrote,
then you are likely setting yourself up to get screwed again. Here's why:
chances are that you have been hiring incompetent developers. If you
finally
get someone in there who knows what he/she is doing, then he/she will
almost
certainly want to start over from scratch and get it right from the
outset... rather than building on a bad foundation. Furthermore, if you
hire
someone who is very good, and he/she tells you that he/she should start
over, then let that happen. Odds are that they will finish much more
quickly
than if they were required to "leverage" the crappy prior work, and you'll
have a better product in the end.

Finally, about estimates: creating good estimates requires YOU [the
customer/end user] to do a good job of communicating the requirements
clearly and decidedly. Whenever you change the requirements (which happens
all the time), then any prior estimates automaticaly become invalid. This
is
such a typical scenario: You ask me how long I'll take to accomplish X, Y,
and Z. I tell you N hours. Then you later modify Z or add new requirement
K.
You then expect N hours to still hold true. Sounds stupid doesn't it?
Happens all the time.

Sorry if all of the above sounds negative or even rediculous... but it's
what I've seen for the past 14+ years as an independent consultant. I've
made a TON of money over that period cleaning up after screw-ups. Here are
a
few lessons/rules, heck "Laws" of IS hiring that I believe to be totally
true. You should pay attention.

You get what you pay for. It's actually worse than that: The
cheaper-by-the-hour programmer is BY FAR the most expensive person you
could
hire. Get a screw-up in there at $20/hr and watch him fritter away 100
hours
on a project and never quite gets it right (i.e. never *finishes* the
job).
Then hire someone truly competent at $80/hr and watch him/her *finish* the
same project in 15 hours. Just with those numbers alone the competent
developer is DONE at $1200 AND sooner than the screw-up who has cost you
$2000 and STILL isn't done! Yes - those numbers are realistic. The costs
of
the screw-up go WAY UP beyond his/her immediate costs if their crappy
product gets into production where it will likely perform slowly and
suffer
data integrity problems. You then have to add [to the total costs of the
screw-up] the lost productivity of your employees. And, if your data is
truly important, then you will eventually need to hire a competent
developer
to come in and redo everything from scratch. But you won't get away for
that
initial 15 hours because; rather than starting out at "ground zero", you
are
starting out the competent developer somewhere BELOW ground zero. That is,
you would then have to pay your competent developer to [at least] clean up
the problemmatic legacy data in addition to creating the replacement
solution.

Let's review
Option 1 - hire competent developer initially:
Cost 15 hours - DONE (and with a good and reliable solution)

Option 2 - hire a "junior programmer" (i.e., *guaranteed* to be a
screw-up)
Costs:
100 hours (the point at which you stop the bleeding) project still not
done
+
Lost productivity costs (if the crappy project made it into production)
+
Data cleanup effort (at least) on the part of the replacement competent
programmer
+
New project from scratch (if done by a competent developer would be FAR
cheaper than trying to "leverage" a pile of crap left behind by the
screw-up
(I mean junior programmer).

Again, this is what goes on ALL the time. Given your post here, I suspect
you already know what I'm talking about.

About your hiring decision (to finally answer your specific question):
There is no magic bullet for you. But you might consider doing a variation
of a scenario I went into in 1999. I was interviewed for a contract
position
with a Big Bank. The group in the bank was nervous in a way like you
apparently are. Same scenario. They had recently gotten rid of the 2nd
person hired to extend an existing system in some very specific ways. They
didn't want to get screwed again. So after I went through 4 separate
interviews (from technical to "is this guy a good fit for the team"
sorts),
I was offered a TWO WEEK gig. Specifically, they told me that there were
two
known bugs in the production system. I had two weeks to (1) find both
bugs,
(2) satisfactorily remediate each, and in a way that would pass technical
review (with flying colors) with other developers on staff. IF I was able
to
do that, then I was to get a 3-month contract to extend the system per the
new requirements that the prior two developers had choked on.

You could do someting like that. Maybe not as intense, but make 'em
perform
before getting too far with them.

-HTH

BTW: Prior to getting my interview with Big Bank, I had one headhunter
tell
me I was too *unqualified* to work for Big Bank and that I would need more
years on my resume. Another headhunter got met the interview. After the
2-week gig I nailed the 3-month contract and ultimately waltzed out of Big
Bank nearly 6 years later... serving in the role as "technical lead" for
the
last 4+ years of my time there. Lesson for you: What's in a resume can be
meaningless... whether it makes the candidate look overly qualified or
overly green. The upshot: Make 'em perform - actually do something and
evaluate that result.

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).

 

[Smithers]

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).

RE:
<< There aren't many around and chances are you won't even know it until
after you hire them >>

Yes - thus the brilliance, in retrospect, of Big Bank when they signed me
for 2 weeks (with no guarantees for anything beyond that), then for 3 months
before going for the longer-term renewals. Such an approach lets an employer
limit exposure while granting the contractor the opportunity to prove
him/herself.

RE:
<< the fact is that even most senior developers aren't very good >>

Spot on with that. I never let anyone call me "senior" even when I lead a
team. The fact is the term "senior" is meaningless (or possibly accurate in
only very limited scopes, and even then for limited duration). "Technical
lead" is more reasonable because it describes a role and responsibilities -
as opposed to some implication higher level of knowledge (which "senior"
packs with it).

But we digress...

-S

 

[AlexS]

I believe it doesn't matter much is the guy title "senior" or "lead". You
can get heavy metal in both cases.

But I second opinion that if you're not sure, try to hire for short period
(even part-time) and see what the guy can deliver. I saw many people who
were pretty good for first 2 weeks and became pretty bad after they started
to assume they will stay on the team

 

[Peter Duniho]

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.

It is relevant, though.

A friend of my father's, long ago, proclaimed the opinion that "80% of
everyone are incompetent". Sadly, while I can't vouch for the exact
percentage, experience has shown the general sentiment behind the claim
to be true.

It's hard to find good help. Whether you're hiring programmers or painters.

That said, I think there are a number of good points in what Smithers
wrote. Paying an expensive, well-qualified professional is often
cheaper in the long run, and I also agree that it would be wise to not
be too attached to any system partially implemented (even if nearly
completed) by someone who eventually needed to be fired.

And of course, don't forget that if it's hard to find someone qualified
to write the code, it is doubly difficult to find someone who can
produce an accurate estimate of what it will cost to do so. You're
dealing with two completely independent competencies here, and there's
no guarantee that someone competent at one is competent at the other
(though, I admit it's hard for someone to be competent at estimating if
they aren't competent at design and coding ).

Pete

 

[Larry Smith]

The sad reality is that most developers in the real world are lousy at

It is relevant, though.

A friend of my father's, long ago, proclaimed the opinion that "80% of
everyone are incompetent". Sadly, while I can't vouch for the exact
percentage, experience has shown the general sentiment behind the claim to
be true.

Maybe I know your dad then because I've expressed the same exact sentiment
many times (seen using that figure). I'm not sure what the actual figure
really is but IMO the world's majority depends on the minority to actually
make things run. It reminds of a situation back in the early 90s when I was
developing (contracting) for a large government run power utility. With tens
of thousands of employees, the average fulltime salary at this utility
actually exceeded 50K - and we're talking 17 years ago. This was
unsustainable as well as ridiculous so the gov't eventually forced mass
layoffs and early retirement packages onto an angry workforce. After
thousands left however, the lights still came on every night which begged
the question, what were all those people actually doing.

It's hard to find good help. Whether you're hiring programmers or
painters.

That said, I think there are a number of good points in what Smithers
wrote. Paying an expensive, well-qualified professional is often cheaper
in the long run, and I also agree that it would be wise to not be too
attached to any system partially implemented (even if nearly completed) by
someone who eventually needed to be fired.

And of course, don't forget that if it's hard to find someone qualified to
write the code, it is doubly difficult to find someone who can produce an
accurate estimate of what it will cost to do so. You're dealing with two
completely independent competencies here, and there's no guarantee that
someone competent at one is competent at the other (though, I admit it's
hard for someone to be competent at estimating if they aren't competent at
design and coding ).

I basically agree with what you're saying. The whole business of writing
software is a very complicated one. Estimating the cost is also extremely
unreliable for various reasons not the least of which is that you can't get
a grip on the application itself until you're actually writing it. So how
can anyone provide a reasonable estimate ahead of time. In most cases you
can't and those who think otherwise are usually naive. The best you can
usually do is try to figure out the worse-case scenario and base it on that.
By far the most important thing a company should do however (which seems to
be the theme of this thread now) is to find skilled developers from the
outset. This is very difficult but it's absolutely critical for the
long-term success of any project. Otherwise your company will bleed large
sums of money for years and possibly die from hemmorhaging.

 

[Larry Smith]

The sad reality is that most developers in the real world are lousy at

RE:
<< There aren't many around and chances are you won't even know it until
after you hire them >>

Yes - thus the brilliance, in retrospect, of Big Bank when they signed me
for 2 weeks (with no guarantees for anything beyond that), then for 3
months before going for the longer-term renewals. Such an approach lets an
employer limit exposure while granting the contractor the opportunity to
prove him/herself.

RE:
<< the fact is that even most senior developers aren't very good >>

Spot on with that. I never let anyone call me "senior" even when I lead a
team. The fact is the term "senior" is meaningless (or possibly accurate
in only very limited scopes, and even then for limited duration).
"Technical lead" is more reasonable because it describes a role and
responsibilities - as opposed to some implication higher level of
knowledge (which "senior" packs with it).

Yes, in fact, I'm even burned out from an entire career dealing with the
(often gross) incompetency of others. Most "senior" developers probably
think the same thing but it's usually part of the same mentality that
compels most drivers to think that every other driver is an idiot. The irony
is usually enough to choke on.

 

[Smithers]

Yes, in fact, I'm even burned out from an entire career dealing with the
(often gross) incompetency of others. Most "senior" developers probably
think the same thing but it's usually part of the same mentality that
compels most drivers to think that every other driver is an idiot. The
irony is usually enough to choke on.

RE:
<< most drivers to think that every other driver is an idiot >>

Except that according to [the great] George Carlin:
"have you ever noticed that everyone who is driving slower than you is an
idiot
while
everyone driving faster than you is a maniac....?

It's a wonder that we get anywhere with all those idiots and maniacs driving
around."

-S

 

[Larry Smith]

Yes, in fact, I'm even burned out from an entire career dealing with the

(often gross) incompetency of others. Most "senior" developers probably
think the same thing but it's usually part of the same mentality that
compels most drivers to think that every other driver is an idiot. The
irony is usually enough to choke on.

RE:
<< most drivers to think that every other driver is an idiot >>

Except that according to [the great] George Carlin:
"have you ever noticed that everyone who is driving slower than you is an
idiot
while
everyone driving faster than you is a maniac....?

It's a wonder that we get anywhere with all those idiots and maniacs
driving around."

In particular because we're so busy muttering the seven words you can't say
on television.

 

[fugitiveguy]

Also, any tips on managing a developer would be appreciated.

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.

 

[pedrito]

On Fri, 24 Aug 2007 18:16:30 -0000, (e-mail address removed) wrote:
[snip]
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.

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.

 

[ajk]

On Fri, 24 Aug 2007 18:16:30 -0000, (e-mail address removed) wrote:
[snip]
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.

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.

actually fun *is* a factor - the reason for me saying that is that
IMHO there are different types of programmers out there - the ones who
love programming because it is great fun (above average programmers)
and the ones who do it just to earn a living because they heard it
pays good money to be a developer. In order to keep a developer
motivated it is important with a fun factor.

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.

it depends a bit on code size but overall it is a bad idea to rewrite
code from scratch. the reason for this is that a project that has
probably been run over many years and as such has been tested that
many years. when you rewrite something from scratch you are basically
throwing all that effort away creating untested code again - in
addition it is *very* difficult to assure that all the functionality
is retained in the new "version". in my experience it is better to
change little by little by refactoring small parts at a time, not by
doing "File/New Project".

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.

an employer / customer don't give much about how programs look inside,
they don't care if code is elegant or very object oriented, what they
care about is new features. if you tell a customer that you need to
wait an extra couple of months just because you wanna do it from
scratch since the code is so messy he probably will not be very
pleased.

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.

i hear you, but that is life as a programmer, we don't often choose
what are supposed to program. we often get a lump of shitty code and
gotta do something about it.

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.

gut feeling yes, but in practice no. a customer doesn't pay extra for
this, he pays for new features. rewriting emulating the same
functionality is never possible - or maybe in some open source
projects where money and time don't matter.

/ajk

 

[Smithers]

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

 

[Freddy Potargent]

Maybe my story at my current employer shows a few points Smithers and
others are making.

I'm now a little over 2 years at my current firm. We develop fully
automated machines for sorting and packing hard fruits (eg apples). A
lot of PLC control of course but also Windows software running on a
stock PC for the machine vision, control of camera's and the image
processing.

When I started there was already a PC application (written in C# during
the year before I started) with a rudimentary UI, using a single camera
and very basic features. This was written by a programmer who had no
experience in Windows programming, multithreading, ... not even OO and
modern software design. He's more a PLC guy then anything else (not to
downgrade him, he's very good at what he does but the machine vision
stuff on PC is outside his area of expertise).

That version was able to scan an apple and calculate the minimal data
required for the PLC to continue. It took however about 20s for the scan
and another 30s for the calculations. There were attempts to use
multithreading to speed up the process, analyze images while scanning
the next product, but there was a lot of trouble with it.

Basically, the code had serious trouble with dead-locks and races, lots
of program logic was intermixed with the UI code (sluggish UI response
for starters but the program logic was not stable, ie changed when the
UI was changed). The application even slowed down when they introduced
multithreading simply because they had no idea what they were doing with
the locks. There were different threads in the code but they were mostly
waiting for results of a previous one so it was essentially still a
single threaded execution. Some (consistent) deadlocks were solved by
timeouts and recovery, ... Also quite some problems with memory usage,
some serious leaks where a lot of data was being held on that wasn't
used anymore.

Of course requirements were changing because the machine was still in
development and we didn't know exactly how we would solve some
functionality (mechanical<->software interaction). Schedules were always
shifting.

When I started I was, as the new guy, not allowed to start from scratch
(explicitly told so in my first week). My first assignment was to solve
some specific bugs (wrong results) and after that was finished to look
into speeding up everything. After the first assignment and when I was a
bit familiar with the code base I discussed with my boss the problems I
saw with the code and made suggestions how to solve them. This
essentially boiled down to restructing the whole code base, rewriting
80-90% of the code.

Not allowed to do this rewrite I was still able to slowly refactor the
code bit by bit while implementing changing and new requirements.
Refactoring not because it was fun but because it was necessary!

Right now we have a mean and lean application, it runs fast (handles 4
camera's simultaneous, capturing 250 images per camera per second and
does a lot more processing in less then 1.5 sec). The code is very
clearly split in IO-bound and CPU-bound threads (no need to make more
CPU-bound threads then you have cores) and a fully configurable UI
seperate from the program logic. The software is ready for out-the-box
expansion, ie add more PC's to handle more camera's simultaneous.

Nearly nothing of the original code is left over and we recently looked
into the changes that happened over the last 2 years (I luckily kept
detailed version control logs although VC was also not deemed
necessary). We agree now that we lost about 6 months (working days, so
that's about 8.5 calendar months of the 2 years!) by slowly refactoring
instead of starting from scratch with a clean structure.

No real problem with the current development because the software was
not on the critical path but it's a lot of lost time in which other
things could have been done. Functionality we now start working on as an
upgrade for instance could have been in the first version.

My experience: electrical engineering and CS degrees, research in
software methodologies, math hobbyist and functional programming fan (do
most of my SW prototyping in Haskell). So a more or less heavy CV but
still needed to prove I can get things done.

In retrospect: overall it's been a fun 2 years but also with the
necessary frustation, seeing what was wrong and how it could be solved
cleanly but not allowed to do so. Having to code around problems,
knowing it will eventually need to be recoded anyway, is indeed no fun
but was sometimes necessary for quick testing and proof of concept.
Occassionally heavy discussions but it all turned out fine.
Important is that we kept talking about progress, impact on software and
schedule of certain decisions/changes, ...

Looking forward to the coming years with new developments and we now all
have a better understanding how to tackle software projects like the
ones we do.

Sorry for the long post, hope somebody gets something useful from it!

-- Freddy




Smithers schreef:
[...snip...]

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.
[...snip...]

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.

 

[Larry Smith]

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.

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)

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.

See previous point.

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

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)

 

[fugitiveguy]

A "detailed spec" is theoretical nonsense that exists almost nowhere

I apologize if I gave you the wrong impression in my previous post. I
used the expression "final product" and that may have given you the
impression that I meant that the spec was set in stone before the
project started. That was not my intention. My intention was to say
that a specification should show the devleoper what work was expected
of them. The specification should evolve, just as the project
evolves.

I stand by my statement that a specification is necessary to show the
developer what is expected of them, and that the weaker the
specification the more likely the developer is to diverge from what
the company expects from the product. The more the developer diverges
the less likely the product is to be successful, and the more
difficult it will be to get the product back on track.

 

[Larry Smith]

The way that you do this is with requirements and schedules.

I apologize if I gave you the wrong impression in my previous post. I
used the expression "final product" and that may have given you the
impression that I meant that the spec was set in stone before the
project started. That was not my intention. My intention was to say
that a specification should show the devleoper what work was expected
of them. The specification should evolve, just as the project
evolves.

What will most of these specs actually show. Do they describe the actual
design in sufficient detail that you can simply translate it into code. Do
they help you design and organize your classes. Do they explain the locking
and multithreading issues you need to work out. Do they address the real
work that you as a programmer have to deal with on a day-to-day basis. It's
a rhetotical question with an obvious answer. Here's the way things work in
the real wold:

Inexperienced manager at start of project (talking to programmer): "Figure
out how long it will take to complete all your tasks and get back to me so I
can complete the project schedule"
Nervous programmer knowing virtually nothing about the details at this stage
but now pressured to answer: "Um, ok."

6 months later (and countless other conversations just like this) ...

Inexperienced manager after deeply pondering an issue for 10 seconds: "Well,
if we do it this way instead, how long will it take to complete and then
update the DB."
Nervous programmer knowing virtually nothing about the details at this stage
but now pressured to answer: "Um, I don't know, maybe 3 days"

This is how schedules work and projects "evolve" in just just about every
software house on the planet..

I stand by my statement that a specification is necessary to show the
developer what is expected of them, and that the weaker the
specification the more likely the developer is to diverge from what
the company expects from the product. The more the developer diverges
the less likely the product is to be successful, and the more
difficult it will be to get the product back on track.

The "company" (senior management) usually knows very little themselves. They
have a high-level vision of what they want but the devil is in the details.
Those details are almost never (properly) worked out ahead of time even
after being "documented" by other managers and architects (who frequently
have little or no programming experience). The documentation that does exist
is typically so superficial and poorly written that it borders on being
worthless. The real details only emerge once programmers start the actual
work and decisions are then made on-the-fly. IOW, being derailed in the way
you're suggesting can't happen when you were never on track to begin with.

 

[egaskill]

Wow...it really looks like I struck a nerve with this topic haha...

Thanks for all the input everyone, it has been very helpful.

~Dex