Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Loyalty, Personal gain or Professional Integrity

by hakkr (Chaplain)
on Oct 04, 2002 at 10:38 UTC ( #202711=perlmeditation: print w/ replies, xml ) Need Help??

Have you ever let personal gain or a personal opinion influence technical decisions. For instance has your preference for the mighty Perl ever swayed your technical decisions on the rare occasions when another solution is superior.

I ask because *shields up* I am looking to learn a bit of Java *shields down* and have just recommended a project with the recommendation to use Java where Perl would have sufficed.

Betraying Perl like this to broaden my skill set is a terrible burden. I do however suspect some peoples loyalties are so strong that the technical merits of a solution are not considered for technical decisions and commercial or personal factors are considered.

I also suspect the personal beliefs that form the basis of open source or microsoft advocacy are causing many a bad decison to be made in the world of IT. I'd be interested to here of some other real life examples of corruption either for or against Perl based projects

Comment on Loyalty, Personal gain or Professional Integrity
Re: Loyalty, Personal gain or Professional Integrity
by Steve_p (Priest) on Oct 04, 2002 at 11:48 UTC

    You should not see this as a betrayal. A programming language is not a person, so it cannot be betrayed. As long as your project will not be harmed by doing the work in Java, I don't see anything wrong with recommending it.

    There are a lot of people out there who practically become married to technologies that it becomes there own downfall. Look at the mainframe or VB programmers out there. Where I live, employers typically receive 200 to 300 resumes for positions for the mainframe and VB. Considering how competetative the job market is right now, I think its a good thing to broaden your skills. Who knows, maybe you'll find something in Java that helps you to improve your Perl skills.

Re: Loyalty, Personal gain or Professional Integrity
by davis (Vicar) on Oct 04, 2002 at 11:55 UTC
    Yes. All the time. With bells on.

    Virtually every decision I make is based on my personal experience - I don't know how e.g. Java would solve a problem, so I can't recommend it. It's as much about individual knowledge as personal beliefs. For example, I happen to know that awk makes a very good job of splitting and printing fields separated by whitespace; I know how it works, and I'm comfortable using it. Other people, unlike me, may not have learnt awk before moving on to Perl, and therefore might advocate a Perl solution. Which one works better depends on the situation.

    In my job, I've got almost free reign over the language I choose to write (current project here) in. I almost always choose Perl out of personal preference.

    The key is being able to accept that the hammer you're wielding now might not fit the nail in question, and the only way to make sensible decisions about that is knowing enough to compare hammers. Learning Java will allow you to judge the relative merits of Java and Perl, and decide which is the better tool for the job.

    Whether you've done wrong by recommending Java is probably up to your employer. Either way, your ability to do your job depends on how well informed you are, so I'd argue that learning another language (where time is not paramount) can only make you a better programmer.

    Thanks, you've made me think.
    davis
    Is this going out live?
    No, Homer, very few cartoons are broadcast live - it's a terrible strain on the animator's wrist

      I think you missed the original point here - the question wasn't "have you ever made a decision biased by your personal preference", but "have you ever knowingly chosen a bad solution, based on your personal preference".

      My answer to that is "yes". I've recommended open source solutions, even though the MS ones would have been easier to implement. I guess my excuse is that I think the OS ones would have been easier to maintain and more secure, in the long run. But I have a sneaking suspicion that that's just an excuse, and wasn't 100% true at the time.

      -- Dan

(elbie): Loyalty, Personal gain or Professional Integrity
by elbie (Deacon) on Oct 04, 2002 at 12:52 UTC

    We've done that on our team a few times, and for exactly the reason you've chosen Java over Perl in your example.

    As a team decision, it was quite easily (and rightly) justified as an extra tool we could add to our skillset thereby being something extra that we could provide for our customers.

    Now we never choose to explore a new technology on a time critical project. It would not look good if a project is dragging on some really basic bit of functionality because no one can figure out the correct syntax or something. But given that you can add the experience you gain on this project to something you can give back to the company, it's not a bad decision, as long as it's not a bad choice for that particular job.

    The deciscion to stay with one technology or another, knowing that it's not necessarily the best fit is a whole other ball of wax that I won't get into.

    elbieelbieelbie

Re: Loyalty, Personal gain or Professional Integrity
by Phemur (Beadle) on Oct 04, 2002 at 13:10 UTC
    I use Perl for almost all of my scripting needs, even in cases where a simple .bat or .sh file would suffice. These scripts usually only benefit me or my co-workers during development, and customers never see these scripts.

    When it comes to deciding on a technology that our customers will use, that should be left to what's best for the project. We've proposed one technology because we were interested in learning it (Java), but in the end we went with another (C++) because most of us have 10+ years experience in it, and performance is a critical requirement of the project. As tempting as it was, we should *never* have considered it. Developer skill development should not be considered when choosing technology for a customer.

    The choice of technology should not be based on personal opinions, but on the needs of the project. However, developer experience with said technology should always be considered.

    Phemur

Re: Loyalty, Personal gain or Professional Integrity
by tbone1 (Monsignor) on Oct 04, 2002 at 13:10 UTC
    I have done this in the past, but after getting knocked on my kiester for such a decision, I'm a lot less likely to do it now.

    What I learned from that kiester-knocking is that programming languages are tools. If you had to hang a picture, you should use a hammer on the nail, because it's the right tool for the job. Afterall, would you take your car to an auto mechanic who had only a rubber mallet? (Come to think of it, I think my mechanic in Chicago was like this ...)

    At the same time, I can appreciate different programming languages just as I appreciate different human languages. Just because I appreciate the regularity of German (outside of a few verb conjugations) doesn't mean I don't like English or Welsh. At the same time, that doesn't blind me to Welsh's orthography or how English's overloading of the word "fly" can cause problems.

    --
    tbone1
    As God is my witness, I thought turkeys could fly.

      re: The regularity of the German language

      Perhaps, given your knowledge of that language, you could enlighten me as to how, with some regularity, one can know what gender a particular noun is. In my meager studies of the language, it generally appeared that gender was assigned somewhat willie-nillie....

      Please correct me if I am wrong.

Re: Loyalty, Personal gain or Professional Integrity
by valdez (Monsignor) on Oct 04, 2002 at 13:58 UTC

    In my humble opinion, you can't be objective if you sell your services.

    If someone calls you, then he trusts in you (for your past results or by chance). But you can't know everything and therefore your choices won't be objective.
    I thinks it is not a matter of Perl or Java, there will be always something that fits better for your next project or is, at last, worth to try. It can be a language or a technique.

    Finally, we must admit that we accept a project even if we don't have all the necessary skills: we learn also by trial and error. gods thanks for giving us this wonderful Monastery.

    So, what I offer is always the best of what I know. And yes, I would like to have more arrows for my bow, even if the solution is something different from Perl.

    Ciao, Valerio

Re: Loyalty, Personal gain or Professional Integrity
by dws (Chancellor) on Oct 04, 2002 at 17:49 UTC
    I ... have just recommended a project with the recommendation to use Java where Perl would have sufficed. Betraying Perl like this to broaden my skill set is a terrible burden.

    Technical decisions don't exist in a vacuum, and they rarely serve a single goal. When evaluating two technologies that are good enough (all other things being equal), there's no sin in selecting the one that enhances your (or the group's) skill base.

    In any project, there are multiple goals being pursued. One goal is "ship the project". Another goal is "leave us set up for the next project". (This latter goal is one reason why projects bother to record so many intermediate artifacts.) Individuals who don't pursue a secondary goal of getting into shape for the next project soon find themselves moved into a technological backwater.

    Things go awry when people don't balance the primary goal of shipping the current project with the secondary goal of setting up for the next one. On one extreme, you can stick with tools you're familiar with, arguing that they're "best", and avoid picking up new tools that are good enough. This way leads to stagnation. On the other extreme, if you always pursue new tools, you may never ship.

Re: Loyalty, Personal gain or Professional Integrity
by krisahoch (Deacon) on Oct 04, 2002 at 17:54 UTC

    I was going to post a message in the same vien as elbi earlier this morning, however I ran out of time.

    What you are doing is making a good descision that can only help yourself, your company, and your customers in the long run. Why? Well, as you gain knowledge and experiance, you become more valuable as a '<whatever you are/do in your company>' to your company. You can tackle more complex problems with greater ease. (This can be a great assest to your company)

    Having said that I must also add that you may be doing it for the wrong reasons. Personal gain on company time may or may not be ethical. That brings this to a philosophical debate. Does the ends justify the means? Personally, I don't know, and I'd rather not try to figure it out.

    Down from my soap box, I will answer the question in its context. I have never let personal gain influence technical descisions. Opinion is another matter altogther. It is my opinion that BASH scripting for a certain project suffices, but Perl scripting for it is much better. Where a collegue of my has the opposite opinion. That is the beauty of opinions.

    HTDCTMBAR (hope this doesn't confuse the matter beyond all recognition)

    Kristofer

Re: Loyalty, Personal gain or Professional Integrity
by Marza (Vicar) on Oct 04, 2002 at 17:59 UTC

    Wow Deja Vu. I basically had this conversation with someone else(a college graduate).

    There is nothing wrong with commiting "betrayal" in the computing world since the computing world can betray you as it keeps changing all the time.

    Skill and knowledge enhancment is personal gain and you are foolish to think it is a bad thing. You like having a job right?

    Well many moons ago I used to be a master of the old Tandem Mainframe. I can make this claim as the company I worked for back then beta tested many of Tandem's core software. Well I thought nothing would ever change and refused to learn anything else as Tandem would never disappear!

    We all know what happened with PCs, Unix and the Net

    When the downsizing of the 1980s happened in the US, I found myself without a job and had mastery of something nobody wanted. It took 2 months to get a job as a junior system admin. Luckily I found a manager who saw that I would amount to something and threw everything at me. These days I am a Wan Engineer.

    So I guess what I am trying to tell you, learn as much as possible. It is fine to love Perl but don't worship it. Someday *gasp* it could get replaced.

    Knowing many things makes you much more marketable in the job world.

Re: Loyalty, Personal gain or Professional Integrity
by seattlejohn (Deacon) on Oct 04, 2002 at 18:09 UTC
    In my mind, the question is not about "betraying Perl", it's about (potentially) betraying a customer. Now, I can't tell from your post whether you're talking about an internal project or one for an outside client -- and I would argue the standards are different for those two cases.

    Clearly it's valuable both to you and to your company to broaden your technical horizons, so using a project as an excuse to develop your Java knowledge is not an intrinsically bad thing. (In fact, you may even find that learning more Java makes you a better *Perl* programmer!) Where I'd start to get worried is if you are doing that learning at the expense of a paying customer. If your lack of experience with Java relative to Perl is going to cost them more money, or result in an inferior product, then it seems to me you need to do some hard thinking before you make that recommendation.

    If this is for an internal project, I think you just need to be honest about the tradeoffs with your manager, etc.: "Hey, boss, this may take longer to complete because I'm not as proficient in Java as in Perl, but in the longer term having the knowledge of Java's relative strengths and weaknesses will enable us to make better implementation decisions." Make your thinking explicit and get approval for the tradeoffs you're proposing. (There may be project constraints that you aren't aware of that would make this a really bad project to experiment on.)

    Your broader question about people's biases leading to bad IT decisions is an interesting one. I'm frequently amazed at how fervently programmers (and technology people in general) get attached to particular tools. To stretch an analogy really badly, I love the swiss army knife that is Perl, but there are times when the right tool would be a torque wrench or a pickaxe or an electron microscope, and using the swiss army knife to accomplish the task would be less than optimal.

Re: Loyalty, Personal gain or Professional Integrity
by lachoy (Parson) on Oct 04, 2002 at 18:26 UTC

    No offense, but it's pretty troubling to me that, by your own admission, you don't know Java but you're making recommendations about its use. This is exactly the attitude we blast PHBs about, since they recommend platforms, tools and languages based on what they read in trade rags.

    Using the right tool for the right job is always a good strategy, but only if you know something about the tool you're using!

    Chris
    M-x auto-bs-mode

Re: Loyalty, Personal gain or Professional Integrity
by trs80 (Priest) on Oct 04, 2002 at 18:43 UTC
    Mid 2001 I was faced with a challenge of refactoring our product for our next release and there were several issues that made it even more challenging.
    • Limited time with Perl as a programming language for the majority of the developers
    • No local source of thorough Perl training (developers based in India)
    • An educational system created bias toward Java
    • Specifications for the design requirements that didn't allow for the flexibility of Perl without language strong managers
    • Install and run on any platform
    So even though our product since 1999 had been Perl based, and my preference was Perl, it was determined that moving to Java made more sense. The results were even better then I had expected. Two months of design and then an alpha release one month after that.

    The original product consisted of over 350 Perl scripts, some embedded in Apache::ASP pages and others stand alone modules along with 47 database tables.

    However, that project would not have been a success or as fast to alpha had it not been for the Perl version which taught us many things about how the product needed to be structured and a base from which to re-engineer the Java solution from.

    In the end I was pleased with the Java work that was done. While at first I was apprehensive about the move because my lack of knowledge in Java, I found that it allowed me to look at the project from a different aspect since I was no longer as concerned with coding technique, but rather the final process of using the application and finding out if it worked correctly. I didn't realize until that move to another language how anal I was about the way something was coded, which can be good, but not when it keeps an item from getting to production on something that in the grand scheme of things simply needs to work not necessarily be pristine code (sad but true when the main goal is make money).

    I did learn one other valuable less, nothing is easy in Java, Perl spoils a programmer with its data structure creation and manipulation.
Marketing slogans != technology change
by blssu (Pilgrim) on Oct 05, 2002 at 13:02 UTC

    I don't like the "right tool for the job" slogan. 99% of the time that's just a marketing trick to suck you into an optimized/specialized solution. Perl for text processing. Java for web programming. Lisp for AI. FORTRAN for number crunching. This is why people think technology changes all the time. It's only the sales pitch that changes...

    Good programming languages have extremely broad application. Perl and Java are both good languages. The decision to use one over the other will almost always be political.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://202711]
Approved by valdez
Front-paged by rinceWind
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (16)
As of 2014-07-31 16:46 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My favorite superfluous repetitious redundant duplicative phrase is:









    Results (249 votes), past polls