the developer contradiction ?

Discussion in 'Java' started by nospawn, Sep 29, 2005.

  1. nospawn

    nospawn Guest

    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?
    nospawn, Sep 29, 2005
    #1
    1. Advertising

  2. nospawn

    Dag Sunde Guest

    "nospawn" <> wrote in message
    news:...
    > 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.

    --
    Dag.
    Dag Sunde, Sep 29, 2005
    #2
    1. Advertising

  3. nospawn

    alex_us01 Guest

    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
    alex_us01, Sep 29, 2005
    #3
  4. nospawn

    Oliver Wong Guest

    "nospawn" <> wrote in message
    news:...
    > 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
    Oliver Wong, Sep 29, 2005
    #4
  5. nospawn

    Bruce Lee Guest

    "Oliver Wong" <> wrote in message
    news:feZ_e.243$z26.79@edtnps84...
    > "nospawn" <> wrote in message
    > news:...
    > > 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
    >
    >



    Firing good coders, hiring crap ones, .. erm hiring good coders to sort crap
    code out?
    Bruce Lee, Sep 30, 2005
    #5
  6. nospawn

    Roedy Green Guest

    On Thu, 29 Sep 2005 21:31:04 GMT, "Dag Sunde" <> wrote
    or quoted :

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

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Again taking new Java programming contracts.
    Roedy Green, Sep 30, 2005
    #6
  7. "Oliver Wong" <> wrote in message
    news:feZ_e.243$z26.79@edtnps84...
    > "nospawn" <> wrote in message
    > news:...
    >> 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.


    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.
    Mike Schilling, Oct 1, 2005
    #7
  8. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Sat, 01 Oct 2005 01:31:08 +0000, Mike Schilling wrote:

    > 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 <>
    http://kt.squeakydolphin.com (not much there yet)
    Jabber IM:
    Phone: (314) 255-2199
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)

    iD8DBQFDPfJhi2ZgbrTULjoRAhpvAKC/WW7532voAWC1nc2MAI+HaBO/SgCggJhR
    sa1ChfTEoTFccIMoLCPBIgk=
    =P/I0
    -----END PGP SIGNATURE-----
    Kenneth P. Turvey, Oct 1, 2005
    #8
  9. nospawn

    Ray Brown Guest

    nospawn wrote:

    > 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.
    Ray Brown, Oct 1, 2005
    #9
  10. nospawn

    Oliver Wong Guest

    "Mike Schilling" <> wrote in message
    news:wFl%e.1915$...
    >
    > "Oliver Wong" <> wrote in message
    >> 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.


    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, Oct 3, 2005
    #10
  11. nospawn

    Oliver Wong Guest

    "Kenneth P. Turvey" <> wrote in message
    news:p...
    >
    > 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
    Oliver Wong, Oct 3, 2005
    #11
  12. In article <>,
    "Kenneth P. Turvey" <> wrote:

    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > On Sat, 01 Oct 2005 01:31:08 +0000, Mike Schilling wrote:
    >
    > > 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 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

    --
    Scott Ellsworth

    Java and database consulting for the life sciences
    Scott Ellsworth, Oct 3, 2005
    #12
  13. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Mon, 03 Oct 2005 19:37:16 +0000, Oliver Wong wrote:

    > 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 <>
    http://kt.squeakydolphin.com (not much there yet)
    Jabber IM:
    Phone: (314) 255-2199
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)

    iD8DBQFDQdkai2ZgbrTULjoRAnzZAJoCNJ69+KaVLB5t9GAYDffF1Lnc0gCfYC+q
    iVvr3ROosF3IIRdU/Nb5wTc=
    =yPH+
    -----END PGP SIGNATURE-----
    Kenneth P. Turvey, Oct 4, 2005
    #13
  14. "Oliver Wong" <> wrote in message
    news:GIf0f.199943$wr.76896@clgrps12...
    >
    > "Mike Schilling" <> wrote in message
    > news:wFl%e.1915$...


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


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

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


    Fair enough.
    Mike Schilling, Oct 4, 2005
    #14
  15. "Oliver Wong" <> wrote
    > 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
    Giovanni Azua, Oct 4, 2005
    #15
  16. nospawn

    Oliver Wong Guest

    "Kenneth P. Turvey" <> wrote in message
    news:p...
    >
    > 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, Oct 4, 2005
    #16
  17. nospawn

    Oliver Wong Guest

    "Giovanni Azua" <> wrote in message
    news:...
    >
    > "Oliver Wong" <> wrote
    >> 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


    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
    Oliver Wong, Oct 4, 2005
    #17
  18. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    On Tue, 04 Oct 2005 12:52:13 +0000, Oliver Wong wrote:

    > 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 <>
    http://kt.squeakydolphin.com (not much there yet)
    Jabber IM:
    Phone: (314) 255-2199
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.1 (GNU/Linux)

    iD8DBQFDQpjyi2ZgbrTULjoRAiIzAJ96O6JGuSRhjz2Km6VW2B1U+cVWzACePRjw
    RzQ3HAGHSaRqFAOsEMb4Y+0=
    =7r+3
    -----END PGP SIGNATURE-----
    Kenneth P. Turvey, Oct 4, 2005
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Oliver Wong
    Replies:
    9
    Views:
    396
    Roedy Green
    Feb 10, 2006
  2. ES Kim

    contradiction in TC++PL?

    ES Kim, Oct 19, 2004, in forum: C++
    Replies:
    44
    Views:
    1,224
    Ioannis Vranos
    Oct 20, 2004
  3. Fuzzyman
    Replies:
    8
    Views:
    290
    Terry Reedy
    Feb 3, 2005
  4. Scott M.

    Precompile Contradiction?

    Scott M., Nov 22, 2007, in forum: ASP .Net
    Replies:
    3
    Views:
    358
    Steven Cheng[MSFT]
    Nov 23, 2007
  5. Gavin Sinclair

    Regular expression contradiction

    Gavin Sinclair, Jul 11, 2003, in forum: Ruby
    Replies:
    1
    Views:
    144
    Daniel Carrera
    Jul 11, 2003
Loading...

Share This Page