the developer contradiction ?

[nospawn]

The more high quality code you make i.e. easier to maintain
extend and be taken over and the more documentation you
write then, the easier for the employer to dump you and get
cheap scamers to replace you and make money from what
you developed ...

Isn't this the developer contradiction?

 

[Dag Sunde]

The more high quality code you make i.e. easier to maintain
extend and be taken over and the more documentation you
write then, the easier for the employer to dump you and get
cheap scamers to replace you and make money from what
you developed ...

Isn't this the developer contradiction?

No, because that would be very short-sigthed...

Software is seldom done when finished, but continuosly
developed and maintained. And there is always new software
to be written.

To fire that kind of developer would be like shooting one
self in the foot. A one time sale, and the customer will never
return when he see quality recline.

all that in addition to, of course, professionalism and
pride in ones work.

 

[alex_us01]

It looks like a challenge, but I thought I would give it a try
(gosh, this is like a chess game). So, here is my 2 cents.

The reality may be that your employer likes you more if you write high
quality code and keeps you on the job. If so, you continue to write
high quality code and be happy. If not, maybe that employer is not good
for you anyway, and you find an employer that is as above.

But suppose that the above is true and a good employer is more likely
to dump you if you write high quality code.
Then, it may still be good for yourself to write high quality code, add
documentation, etc. because of your own sanity. As a programmer, you
may have an easier time if you do that as the code is easier to
develop, add features to, refactor, change, etc. You save yourself the
stress and possible guilt for degrading your ability.
If this is true and your employer, indeed, replaces you with cheap
scamers, then, he will get into trouble because the code will decay
over time and the cost of developing and maintaining will increase
despite the cheapness of the scamers. Let alone effort, time is also
important, which will tend to increase as new requests come.

Your employer will hopefully learn this. By the time, you will be off
the job. But if this is true, you will hopefully find an employer that
already has learned this in the past.

If so, then it is no real problem for you and there is no good reason
for you to change your high quality style to a low one. (You may
additionally learn how to find the job and environment you are more
suited for.)

Continuing the analysis, if no employer can ever learn that from the
experience alone, it may be worth finding ways communicating it. There,
some skills of communication and assertiveness may be required. You
will have the option to acquire such skills instead of changing your
coding style. I'd do that because it is a motivation to improve
yourself while the letter would feel bad.

hope you like my analysis...

alex

 

[Oliver Wong]

The more high quality code you make i.e. easier to maintain
extend and be taken over and the more documentation you
write then, the easier for the employer to dump you and get
cheap scamers to replace you and make money from what
you developed ...

Isn't this the developer contradiction?

The company I work for provides "IT solutions". We are called in, given
code written by someone else, make modifications to it, and give them the
new code.

Invariably, the code we're given is always total crap. Why is this?

Because if the code were good, they wouldn't have to have hired experts
like us to go in and clean up the mess.

Firing your good coders in exchange for cheap scamers is a losing
strategy in the long run because it means you'll eventually have to call in
outside consultants like us, and we're very expensive.

- Oliver

 

[Bruce Lee]

The company I work for provides "IT solutions". We are called in, given
code written by someone else, make modifications to it, and give them the
new code.

Invariably, the code we're given is always total crap. Why is this?

Because if the code were good, they wouldn't have to have hired experts
like us to go in and clean up the mess.

Firing your good coders in exchange for cheap scamers is a losing
strategy in the long run because it means you'll eventually have to call in
outside consultants like us, and we're very expensive.

- Oliver

Firing good coders, hiring crap ones, .. erm hiring good coders to sort crap
code out?

 

[Roedy Green]

Software is seldom done when finished, but continuosly
developed and maintained. And there is always new software
to be written.

If you come back to software you wrote yourself years ago, often you
don't recognise it at all. It is familiar in than it has your name on
it, and some of your quirks, but it rings no bells.

Then you REALLY appreciate the documentation you left to yourself to
explain the basic facts of how everything fits together, the tricky
parts, what each of the classes is for in a line or two, the project
glossary of precisely what you mean by each term. The docs on a class
to tell what it does and does not do, rather than details of how it
works are invaluable. You can pick up the detail easily. It is the
big picture that is hard.

It is kind of like having some incredibly caring friend looking out
for you trying to make your stay pleasant.

You know the code won't do anything crazy, so you don't even have to
check. You can get in, make your modification and get out, only having
to a minimal amount of work refreshing yourself.

When you work for yourself that is the only kind of code you can
afford to write.

 

[Mike Schilling]

The company I work for provides "IT solutions". We are called in, given
code written by someone else, make modifications to it, and give them the
new code.

Invariably, the code we're given is always total crap. Why is this?

Because if the code were good, they wouldn't have to have hired experts
like us to go in and clean up the mess.

Firing your good coders in exchange for cheap scamers is a losing
strategy in the long run because it means you'll eventually have to call
in outside consultants like us, and we're very expensive.

I'd guess (please tell me if I'm wrong) that the crap code was in most cases
originally written by contractors hired just for that project, not by
employees who'd have to live with it. In hiring programmers, I've observed
huge difference in the ability to write clean, well-documented,
well-encapsulated, maintainable code between people who've been in
situations where they were maintaining their own code for extended periods
and people who've never had to do that.

 

[Kenneth P. Turvey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'd guess (please tell me if I'm wrong) that the crap code was in most
cases originally written by contractors hired just for that project,
not by employees who'd have to live with it.

I would guess this is probably true, but not for the reasons you would
think. Contractors are usually held to higher performance expectations
which many managers tend to interpret as simple throughput without
regard to quality. I suspect if the manager is good (and able to tell
the difference), contractors are probably as good at producing quality
code as their permanent employee competitors.

In hiring programmers, I've observed
huge difference in the ability to write clean, well-documented,
well-encapsulated, maintainable code between people who've been in
situations where they were maintaining their own code for extended
periods and people who've never had to do that.

If this is used as a measure for performance of a contractor, you could
probably expect roughly the same results as with an employee. I think
the difference is that managers simply don't use code quality as a
metric. They don't know how to measure it and it is more trouble than
measuring throughput.

I know that has been my experience. My last manager measured things
like the percentage of time sheets that were submitted on time and the
percentage of staff meetings attended (everyone put in forty hours a
week and attended all necessary meetings), but never had an metrics on
code quality. He simply didn't understand what was important. That
attitude went up the management chain at least a couple of levels.

Thinking about it they actually rewarded the production of quickly
produced poor quality code in many ways. Strange place.

- --
Kenneth P. Turvey <[email protected]>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: (e-mail address removed)
Phone: (314) 255-2199
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDPfJhi2ZgbrTULjoRAhpvAKC/WW7532voAWC1nc2MAI+HaBO/SgCggJhR
sa1ChfTEoTFccIMoLCPBIgk=
=P/I0
-----END PGP SIGNATURE-----

 

[Ray Brown]

The more high quality code you make i.e. easier to maintain
extend and be taken over and the more documentation you
write then, the easier for the employer to dump you and get
cheap scamers to replace you and make money from what
you developed ...

Isn't this the developer contradiction?

To write working and maintainable applications with good
documentation is our goal. Once we have delivered we
are soon forgotten. If we are very good we are never
remembered and the application continues to work until
requirements change. We move on to other paths.
That is our way.

 

[Oliver Wong]

I'd guess (please tell me if I'm wrong) that the crap code was in most
cases originally written by contractors hired just for that project, not
by employees who'd have to live with it.

We don't ask, with disgusted faces, "Who the hell wrote this?" It simply
wouldn't be professional. (In other words: I don't know).

In hiring programmers, I've observed huge difference in the ability to
write clean, well-documented, well-encapsulated, maintainable code between
people who've been in situations where they were maintaining their own
code for extended periods and people who've never had to do that.

Makes sense, and it's something that I've done myself in my own personal
projects. When I'm writing a big project which I know will take me months if
not years to complete, I make sure the code is clear and well documented;
after all, I'm the poor sucker who's gonna have to look at it again tomorrow
morning.

But if it's just 2 pages of code that'll just be run once (e.g. to
programmatically generate a 2500 byte regular expression which I then just
hardcode in my *REAL* project), then I won't bother making it pretty. I
doubt I'll ever have to look at it again.

- Oliver

 

[Oliver Wong]

My last manager measured things
like the percentage of time sheets that were submitted on time and the
percentage of staff meetings attended (everyone put in forty hours a
week and attended all necessary meetings), but never had an metrics on
code quality. He simply didn't understand what was important. That
attitude went up the management chain at least a couple of levels.

Thinking about it they actually rewarded the production of quickly
produced poor quality code in many ways. Strange place.

Alternatively, perhaps your manager acknowledge that code quality was a
factor, but could not measure it in any simple way. Assuming that he wasn't
a programmer himself, he couldn't look at the code and decide whether it
were high quality or not. He didn't want to simply hire a programmer to read
all your code and rate it on quality. He doesn't want to assign one of the
existing programmers to rate the code, as that programmer will probably be
biased and consider his/her own code to be the best, etc. There isn't any
known way of automatically measuring code quality that can be taken
seriously (ratio of comments to code? Number of statements in a method? Are
the variable names 5 characters or longer?)

In other words, it's simply infeasible to measure code quality in a fair
enough way that we can actually reward or punish programmers depending on
the quality of their code, and do it cheaply.

- Oliver

 

[Scott Ellsworth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



I would guess this is probably true, but not for the reasons you would
think. Contractors are usually held to higher performance expectations
which many managers tend to interpret as simple throughput without
regard to quality. I suspect if the manager is good (and able to tell
the difference), contractors are probably as good at producing quality
code as their permanent employee competitors.

In some cases, contractors are better than existing employees for
certain tasks. They may bring specific skills, or a better training
system to the party, for example. For this to happen, you have to have
good contractors.

Alodar, for example, gives its employees a week of offsite training a
year, and we are expected to also take on internal development projects
to learn new technologies. Very few of our clients provide this level
of training to their employees, which means that we may bring knowledge
of three or four object relational mapping systems to a task, or three
or four web application systems, while their own people have only used
the one that the company has standardized on.

The flip side, of course, is that the employees know their own system
better than we do. That is a appropriate - we are each providing
something to the task. When implementation time comes, we each have a
role, if we are doing our jobs right.

In addition, if we do our jobs right, we transfer that knowledge to the
employees before the job is done. We trust that we will learn enough
new on Alodar's nickel before the job ends to justify future work at the
client - once they know what we know about Hibernate, for example, we
have learned about Subversion, or Java 1.5 migration issues.

Since we would prefer to have multi-year contracts, we do try to write
code we are willing to see again. Further, since we may be hired back
to maintain an app we wrote years ago, we have a strong incentive to
make it transparent.

I have had to repair code written by people like you describe. It is
not fun. Potentially lucrative, but I would rather work on making the
good into the great, rather than the awful into the acceptable.

Scott

 

[Kenneth P. Turvey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In other words, it's simply infeasible to measure code quality in
a fair enough way that we can actually reward or punish programmers
depending on the quality of their code, and do it cheaply.

I simply don't buy that. Measuring code quality can be done as well as
any of the other measures used to measure the productivity of an
employee. It can be done much better than many that are used to
assess the quality of employees in industry today. Some measures are
actually quite simple.

Many of the programs that I worked on at that job had multi-page main
functions that called few or no other functions (in C). A simple
measure to avoid this problem would be to measure the average length of
a function excluding any switch statements. One could automate this
measure and the programmers having their code assessed could
collectively adjust and weight it as needed.

Now, I admit, if your programmers are going to game the system instead
of working to improve it, it won't work. But, then again, if your
programmers are going to do this maybe you should find some new ones.

I guess your measure of cheap and mine aren't the same. The reality is
that poor code costs money. We can argue about how much, but the number
is high. If you can get programmers to assess their own code you are
really going to be ahead of the game.

- --
Kenneth P. Turvey <[email protected]>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: (e-mail address removed)
Phone: (314) 255-2199
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDQdkai2ZgbrTULjoRAnzZAJoCNJ69+KaVLB5t9GAYDffF1Lnc0gCfYC+q
iVvr3ROosF3IIRdU/Nb5wTc=
=yPH+
-----END PGP SIGNATURE-----

 

[Mike Schilling]

We don't ask, with disgusted faces, "Who the hell wrote this?" It
simply wouldn't be professional.

"We'd like to understand the history of this project." is reasonable, I
think.

(In other words: I don't know).

Fair enough.

 

[Giovanni Azua]

Alternatively, perhaps your manager acknowledge that code quality was a
factor, but could not measure it in any simple way. Assuming that he
wasn't a programmer himself, he couldn't look at the code and decide
whether it were high quality or not. He didn't want to simply hire a
programmer to read all your code and rate it on quality.

There are ways to do this automatically i.e. code metrics ... RFC (Response
For
a Call) determines a measure of overall complexity, Cyclomatic complexity

http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html

You indeed do not need to hire a very high-rate programmer to check
someone else's code.

Regards,
Giovanni

 

[Oliver Wong]

Now, I admit, if your programmers are going to game the system instead
of working to improve it, it won't work. But, then again, if your
programmers are going to do this maybe you should find some new ones.

This is basically the core of the problem. Assuming your boss is
non-technical, he can't nescessarily detect when programmers are gaming the
system, and then replace them. Programmers who were previously writing good
code may be tempted, when confronted with a choice between getting a good
score on the metrics and writing good code, choose to eschew the latter for
the former, because it'd simply be too difficult to explain to the boss why
the code is good even though the metrics software says it's bad.

I simply think the code metrics packages out there aren't mature enough
to be used for evaluating employees.

- Oliver

 

[Oliver Wong]

There are ways to do this automatically i.e. code metrics ... RFC
(Response For
a Call) determines a measure of overall complexity, Cyclomatic complexity

http://www.sei.cmu.edu/str/descriptions/cyclomatic_body.html

Yes, I hinted at code metrics in my post, right before the point you chose
to cut off the quote. Here it is again:

<quote>
There isn't any
known way of automatically measuring code quality that can be taken
seriously (ratio of comments to code? Number of statements in a method? Are
the variable names 5 characters or longer?)
</quote>

Note the "taken seriously" part. I believe that the code metrics
packages out there simply aren't mature enough to be used for evaluating
employee performance (as I mentioned in another branch of this thread).

You indeed do not need to hire a very high-rate programmer to check
someone else's code.

Actually, I argue that you do. The software metrics measure something;
It might be lines of code, "cyclomatic complexity", number of interclass
dependencies, etc. But whatever it is, it isn't quality.

- Oliver

 

[Kenneth P. Turvey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is basically the core of the problem. Assuming your boss is
non-technical, he can't necessarily detect when programmers are
gaming the system, and then replace them.

You've got a point. This comes down to how one selects managers for
technical positions. I don't have an answer for that. If your manager
can't tell the difference between programmers who are gaming the system
and those that aren't, or doesn't expend the effort to try and measure
code quality in any reasonable way, you probably need a different
manager.

This doesn't really solve the problem though. It is a cop out. How
does one go about selecting a technical manager? Does this manager need
to have experience in the technology being used to manage a project or
team?

I honestly don't know the answer to this question. I've known people
who could manage any task given to them and I've know people who had all
the right skills that couldn't manage their way out of a paper bag.
Being familiar with the technologies used is certainly helpful for a
manager, but I have reason to believe that it isn't a necessity.

Programmers who were previously writing good
code may be tempted, when confronted with a choice between getting a
good score on the metrics and writing good code, choose to eschew the
latter for the former, because it'd simply be too difficult to explain
to the boss why the code is good even though the metrics software says
it's bad.

There needs to be some provision for handling this. I don't think many
good programmers will do this unless they are completely demoralized
already and convinced that the manager is a bean counter only interested
in the output of a metrics program they have no control over. As long
as they have input and a level of control, I don't think it will be a
problem.

I simply think the code metrics packages out there aren't mature
enough to be used for evaluating employees.

It would have to be used as a fuzzy input, just like nearly all the
inputs used for evaluating employees.

- --
Kenneth P. Turvey <[email protected]>
http://kt.squeakydolphin.com (not much there yet)
Jabber IM: (e-mail address removed)
Phone: (314) 255-2199
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDQpjyi2ZgbrTULjoRAiIzAJ96O6JGuSRhjz2Km6VW2B1U+cVWzACePRjw
RzQ3HAGHSaRqFAOsEMb4Y+0=
=7r+3
-----END PGP SIGNATURE-----