use Perl

• I'd like to add ... (Score:1)

  by phaylon (6115)

  Programming rule #1 for businessmen: Getting-It-Done is great, but you can't wait forever to do it right. ;)

  --
  Ordinary morality is for ordinary people. -- Aleister Crowley
• Do you really want programmers making the call? (Score:2)

  by samtregar (2699)

  My first reaction to this is roughly "how would I know?" I'm not a business dude. I have no idea if the code I'm writing today will make money for my company. I consider it out of my hands. When I want to know if I should do something quick and dirty or slow and right I ask my manager. I try to lay out the options as clearly and honestly as I can and then I wait for the decision.

  In answer to your straw man who "imperiously announces that he'll refactor the entire system to keep this from happening ag
  • Re:Do you really want programmers making the call? (Score:2)

    by Ovid (2709)

    I think you and I are mostly on the same page. I never said that programmers should make this call. I see a lot of programmers railing against managemers who say "we need this done now" when, in fact, it really does need to be done now. When programmers get a better knowledge of the business side, they can better understand the business decisions (and that goes for the business folks knowing the tech side) and make more reasonable recommendations.

    It reminds me of when I used to manage coffee carts whil
    • Re:Do you really want programmers making the call? (Score:2)

      by samtregar (2699)

      Sure, I've been there, getting the wrong answers from the boss. Some business people just aren't good at making informed decisions even when you've patiently explained all the tradeoffs and benefits. I think we, as programmers, need to be sure we're holding up our end of the bargain - delivering all the data the business-people need to make good decisions. When they make bad ones anyway then it may be time to find a new job. Until then it's our job to follow orders, and to make the best use of the tim
      • Re:Do you really want programmers making the call? (Score:2)

        by Ovid (2709)

        True, but I see too many new programmers agonize and complain over "perfect" code, failing to realize that perfect is the enemy of the good. Of course, "perfect" is also highly subjective and changes over time. Companies are rarely hiring us for pure research. They're hiring us to get things done and either make or save money. I really do feel that one of the worst mistakes programmers make is forgetting that they're working for a business and not turning in homework.
• Balance (Score:2)

  by Juerd (1796)

  Of course, the paycheck (or in my case, having clients pay my invoices) is incredibly important.
  
  However, the world is not black and white, and there's much gray in between. The gradient isn't linear either, and in fact, many shades of gray turn out to have a very different hue.
  
  While the customer (boss or client) is the one you're serving directly, you're also serving other people. People who do not pay you, or will ever know that you worked on that particular part of code. They are all the people that are i
  • Re:Balance (Score:2)

    by Ovid (2709)

    It's our moral obligation to deliver quality even if our customers specifically state that they do not need it. If they refuse to pay for it, then it is our responsibility to say "no".

    Really? Define "quality" in such an unambiguous way that everyone will agree on it.

    When I'm asked about this in interviews, the thing I make clear is that if I'm told to make a button pink and have it purr like a kitten when clicked, I'll do it (even though I might ask 'em why). However, if I'm told to do something illeg
    • Re:Balance (Score:2)

      by Juerd (1796)

      Defining quality is impossible because a definition cannot have the required balance, as that differs per institution, per situation.
      
      As for your second paragraph, that's more or less what I do too. (Although most of the time, it is my *job* to avoid pink buttons.)
    • Re:Balance (Score:1)

      by Aristotle (5147)

      See The Crooked Timber Of Software Development [hacknot.info] and the awesome response Tye wrote at PerlMonks [perlmonks.org] when I posted that link.
      • Re:Balance (Score:1)

        by btilly (5037)

        I'd love to read that link. Your recommends are usually good.

        Unfortunately I can't because the site has an internal error.

        Furthermore the internal error shows me that they present a full stack backtrace on internal errors. Which you shouldn't do in production because it allows people to debug their attacks against your site.

        If they're recommending shortchanging program quality for business considerations, the current state of the site suggests that they may wish to re-prioritize...
        • Re:Balance (Score:1)

          by Aristotle (5147)

          It’s still available from the Google cache [google.com], thankfully. I also have a local copy in my aggregator, should that too fail.
• Agree wholeheartedly, but there's one tricky bit.. (Score:1)

  by Alias (5735)

  In principle I agree completely.
  
  I rarely code for clients to the same standard I code for CPAN.
  
  Or at least, I CODE for them as well if they are paying for me to be their "expert", but I often let some of the more finely detailed testing slip, and often let the API documentation slip.
  
  On CPAN, documentation is MUCH more important than for clients. Lots of comments for maintainers are still useful, but spending as much time on writing the POD as you spend writing the code (as you might for CPAN) just isn't wor
• Making other people money. (Score:1)

  by pjf (2464)

  If you're not making or saving your employer money, you probably shouldn't be employed.

  I agree entirely your statement should be obvious. I also agree that in many organisations it's not the programmer's role to know the best way for them to generate value; that's what managers are for.

  However if one wants that pay-cheque to be bigger, it's worth finding out what's really important to your business. It's rare for developers to work in a vacuum, and knowing where the real priorities lay is often eas