Code Refuse

« Return to Article
  • Ollie Williams 2010-05-25 09:05
    The first rule of DAL is: you do not talk about the DAL
    The second rule of DAL is: you do not talk about the DAL
  • Jaime 2010-05-25 09:10
    This sounds familiar. I've been re-writing DAL code that takes grid parameters for the past three years. I can't fathom how these people think it's a good idea.
  • frits 2010-05-25 09:14
    Too bad Jeff wasn't able to effectively present his view. His code could have been an efficient and effective model for his company.
  • SR 2010-05-25 09:20
    frits:
    Too bad Jeff wasn't able to effectively present his view. His code could have been an efficient and effective model for his company.


    It sounds more like the company didn't effectively listen to Jeff.

    Besides we all enjoy reinventing the wheel. Go on, admit it! ;o)
  • java.lang.Chris; 2010-05-25 09:21
    There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue.

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.
  • ObiWayneKenobi 2010-05-25 09:22
    Carl, a twenty year veteran with the company


    MAJOR red flag right there. What is with these people who have worked for a company for years? Every single one I have met during my career was basically an ignorant sloth who knew nothing about proper software engineering practices and, when confronted or asked about doing things the right way, used seniority to shoot it down.

    I mean, I can understand using shitty practices when you're first learning the stuff; that's expected. But you should REALIZE it's a bad way of doing things, and constantly improve yourself so the next project, you do a little better. And the next, and so on until you're doing things properly. You don't keep churning out the same shit because you're too stupid to understand it's wrong and don't want to be bothered learning better ways.
  • wtf 2010-05-25 09:23
    As an aside, I don't see why everyone complains about re-inventing the wheel. Bicycle companies do it all the time, and the bicycles have better wheels on them because of it.

  • Jellineck 2010-05-25 09:24
    "Ignoring the fact that is idiotic," Jeff replied, "why would we do that? The UI and the DAL are completely separate. It doesn't matter how we present the data, the DAL is just fetching it."

    Someone needs to work on his interpersonal skills. Everything after the word "idiotic" will always be ignored. He might as well have said "Ignoring the fact that is idiotic, I read the Twilight book and cried the whole time."
  • wtf 2010-05-25 09:25
    java.lang.Chris;:

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    Works great if you're interviewing your twenty-year veteran employees. A good idea, perhaps, but not something that's done very often.
  • 50% Opacity 2010-05-25 09:27
    He could grab the Windows team's DAL and business layer, slap a web front end, …


    It seems he should've rather slapped the DAL instead.
  • highphilosopher 2010-05-25 09:27
    java.lang.Chris;:
    There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue.

    Ways to avoid this kind of cluster fuck (at least for Java projects) is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then.


    You know, I think you're painting the whole world of development into one little box. There's plenty of other good design pattern books, however expecting all your developers to be architects is like trying to have an army of generals. What you need is 1-5 GOOD Architect(s) that build the framework around which the developers can work. Many companies try to save some money on their development budget by skipping the Architect (and sometimes even the Project Manager). Generally these companies end up with a codebase of useless snippets organized by prepending the name of the ASP.NET files with "Web".
  • Code Refuser 2010-05-25 09:32
    "There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue."

    Even though our young developer wanted to do things the "right way", I have to say that both parties came off as pretty clueless here. He should have expected that unless the application he was piggybacking on was designed with abstraction and re-use in mind, that whatever he was provided was going to be almost useless to him.
  • frits 2010-05-25 09:37
    SR:
    frits:
    Too bad Jeff wasn't able to effectively present his view. His code could have been an efficient and effective model for his company.


    It sounds more like the company didn't effectively listen to Jeff.

    Besides we all enjoy reinventing the wheel. Go on, admit it! ;o)


    I think you missed something.
  • Ed 2010-05-25 09:46
    Christ, at least his project HAS a DAL.

    The one I'm working on these days just have 3000 line classes that do every concievable permutation of getting tiny bits of data in and out of the database and into the relevant control on the page...

    I should start submitting some of the WTFery that I find on a daily basis I think.
  • Remy Porter 2010-05-25 09:55
    Ed:
    Christ, at least his project HAS a DAL.

    One of the applications I inherited has a DAL, of sorts. The really great part about the whole thing, though, is that the Classic ASP layer calls out to the COM+ layer to get the widgets it should render. The COM+ layer returns a string of XML that the page outputs in-line in the body, and never looks at directly again. Instead, when the page wants a widget, it passes the XML string back into the COM+ layer with the name of the widget it wants. The COM+ layer then returns an HTML string that represents that widget on the page.

    Honestly, when I read the submission, I had to make sure Jeff wasn't a co-worker. Because my company has a crapload of applications like that.
  • iToad 2010-05-25 10:16
    ObiWayneKenobi:
    Carl, a twenty year veteran with the company


    MAJOR red flag right there. What is with these people who have worked for a company for years? Every single one I have met during my career was basically an ignorant sloth who knew nothing about proper software engineering practices and, when confronted or asked about doing things the right way, used seniority to shoot it down.

    I mean, I can understand using shitty practices when you're first learning the stuff; that's expected. But you should REALIZE it's a bad way of doing things, and constantly improve yourself so the next project, you do a little better. And the next, and so on until you're doing things properly. You don't keep churning out the same shit because you're too stupid to understand it's wrong and don't want to be bothered learning better ways.


    Sometimes, the twenty year veteran really has twenty years of experience. Sometimes, they only have one year of experience, twenty times.
  • sd 2010-05-25 10:19
    I have some advice for Jeff. Once you start off your sentence with "Aside from the fact that this is idiotic..." the other person stops listening to your argument and goes on the defensive.

    If you're really trying to convince someone to change something, insulting them for writing or suggesting it isn't the way to go about it. All you'll end up with from that is the cold comfort that you're right, and possibly the material for a TDWTF article.
  • Doug 2010-05-25 10:24
    The first rule of code reuse is that the code needs to be worth re-using.


    Reading this almost made me cry. Or maybe that was the onions from my omelet.

    Either way, it's true.
  • toshir0 2010-05-25 10:28
    Ed:
    Christ, at least his project HAS a DAL.

    The one I'm working on these days just have 3000 line classes that do every concievable permutation of getting tiny bits of data in and out of the database and into the relevant control on the page...

    I should start submitting some of the WTFery that I find on a daily basis I think.
    Don't make us drool, dude... show us your dirty bits.
  • AnOldRelic 2010-05-25 10:30
    iToad:
    Sometimes, the twenty year veteran really has twenty years of experience. Sometimes, they only have one year of experience, twenty times.

    This. I can't tell you how many times we've had people come through the interview process here that claimed 10+ years of experience with their particular point of expertise... but showed little-to-no improvement over individuals who were considered by HR to be "under-qualified" because they only had 3-5 years' experience. Quality > Quantity. I'd sooner hire the 2-year rookie with a degree, a grasp of theory, the desire to learn and the ability to adapt and put him/her under the wing of a project lead. He/she will be infinitely more useful to the company than a 20-year veteran who is set in their erroneous ways and has not bothered to grow with the industry over time.
  • Jaime 2010-05-25 10:32
    java.lang.Chris;:
    There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue.

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.
    I wish I had that luxury. I spend months waiting for a single candidate that won't fill this site with fresh WTFs. I'd hate to ignore a candidate with potential because they hadn't read my pet book.

    I just interviewed someone who was very versed in the singleton pattern. I know this because she gave me a very detailed explanation of how to create a singleton database connection for a web application. She read GoF, and she understood it, but she is still a bad designer.
  • Luis Espinal 2010-05-25 10:34
    wtf:
    java.lang.Chris;:

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    Works great if you're interviewing your twenty-year veteran employees. A good idea, perhaps, but not something that's done very often.


    Fowler's book on EEA Patterns is not an appropriate book to use as a baseline unless you are hiring a software architect, a senior software developer, integrator or a systems engineer, and by "systems engineer" I don't mean a Sysadmin+Network Admin, but someone whose work is in the actual field of systems engineering. As a general interview question for junion/mid developers, I don't think it is appropriate.

    Everything else you said is on the mark though (specially grilling one's knowledge of design patterns, and most importantly how not to use them.) Other books I'd add to the list would be Fowler's "Refactoring" and Brown et al. "Anti Patterns". If they have actually read Bruce F. Webster "Pitfalls of Object Oriented Development", that should count for something.
  • Kensey 2010-05-25 10:36
    ObiWayneKenobi:
    Carl, a twenty year veteran with the company


    MAJOR red flag right there. What is with these people who have worked for a company for years? Every single one I have met during my career was basically an ignorant sloth who knew nothing about proper software engineering practices and, when confronted or asked about doing things the right way, used seniority to shoot it down.


    I know at least one guy who's a 30-plus-year veteran with the company I used to work at (he's still there, running out the clock on his pension vesting with about 6 months to go). His tenure literally predates the existence of the company as he was an employee of one of two companies that merged into the current entity.

    There isn't much he doesn't know about his job area, either technically or politically, as he worked on software and hardware development through most of his career and is now marking his time administering systems he helped create. When he says "no, that's stupid" (which isn't often as he picks his battles conservatively), it's for more than sufficient reason and he has the seniority to just do things the right way rather than what our idiot managers wanted him to do.

    I'd put that guy up as a counterexample to your red flag.

    Having said all that, Jeff's desire to reuse code would work better if he created his own code and offered it rather than trying to reuse code the authors clearly were going to play silly seniority games with. But it would only work at all in a corporate culture that understands, encourages, and supports code reuse, which is clearly not the culture he was in.
  • DOA 2010-05-25 10:36
    java.lang.Chris;:
    There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue.
    Can we add some SO functionality in here so I can upvote this? A clueless rookie you may be able to shape into something. A clueless veteran should just get the boot, not just because he clearly doesn't give a shit about improving himself, but also because he thinks he's doing things right and is incapable of listening to anyone else.

    I've had to work with a clueless dev "with years of experience" before. His first svn commit didn't have indentation. Who the hell writes code without indentation?! I haven't done that since I was writing BASIC when I was 11. Eventually I had to forcefully take control of the design process, because it was clear I'd end up being the one maintaining the code after this guy left. Eventually he did leave and after a while I got a feature request that would have taken about two days to deal with. I finished it in about 4 hours thanks to the proper design I had insisted on.
  • Zylon 2010-05-25 10:36
    sd:
    I have some advice for Jeff. Once you start off your sentence with "Aside from the fact that this is idiotic..." the other person stops listening to your argument and goes on the defensive.

    Work isn't always about getting the immediate task done. Sometimes you need to take the long-term morale boost of publicly crushing incompetent coworkers.
  • Me 2010-05-25 10:41
    Code reuse is good, yes, but it has it's limits.

    I just refactored some code that reused the same DAOs (yes! we have data access objects!) to a) fill a form with data from several related tables and b) fill a drop down list with the "name" column of one of the tables.

    In other words, the second use case used exactly the same five DB queries for each of the 80 or so items to be displayed, and discarded all but "name".

    Sometimes you have to tailor your DAL to the job.
  • Jason Y 2010-05-25 10:41
    Yeah, he definitely should have:
    1. been more diplomatic, using evidence (e.g. resources like PoEAA) rather than insults.
    2. looked at the existing DAL before insisting that he use it. If the desktop software writers claim that their DAL is for the desktop software, that should have clued him in that their "DAL" was actually customized for the desktop software, rather than being written as a real DAL.
    3. communicated that the DAL he writes is UI-ignorant, and explained to the destop UI team how they can use DAL's that follow this pattern in the future, complete with sample desktop UI code, so that they would not have to duplicate efforts in the future. He could also show how desktop-specific crap in their desktop-specific "DAL" could be placed in another layer that is still desktop-specific, but delegates the DAL work to the real, UI-ignorant DAL.

    Just my 2 cents.
  • wtf 2010-05-25 10:44
    Zylon:
    sd:
    I have some advice for Jeff. Once you start off your sentence with "Aside from the fact that this is idiotic..." the other person stops listening to your argument and goes on the defensive.

    Work isn't always about getting the immediate task done. Sometimes you need to take the long-term morale boost of publicly crushing incompetent coworkers.


    "Morale boost" from promoting stupid inter-office squabbling over getting the job done? Gosh, I'm glad I don't work with you.
  • Anonymously Yours 2010-05-25 10:44
    wtf:
    As an aside, I don't see why everyone complains about re-inventing the wheel. Bicycle companies do it all the time, and the bicycles have better wheels on them because of it.
    A lot of people hear rules, "best practices," and so forth and just commit them to memory. They don't actually think them through. They think you should reuse code whenever possible when, really, you should reuse code whenever practical. I've been subjected to cleaning up some horrible code my coworkers are rushed into producing, all because pre-existing code keeps getting hammered into whatever shape it needs to fit from site-to-site.

    All things considered, when Jeff has a few more years under his belt, he'd know the right way to ask for code. By which I mean noncommittally and (if Carl seems the type to buy it) to "learn from." That way, if Jeff finds the code is an unusable pile of shit, he doesn't have to offend anyone if he decides to imitate the functionality instead of recycling it.
  • Mads H. 2010-05-25 10:57
    Meh. The usual one-sided story written by the guy who lost the argument and then petulantly decided to add more crap to the codebase.
  • Zylon 2010-05-25 10:59
    wtf:
    "Morale boost" from promoting stupid inter-office squabbling over getting the job done? Gosh, I'm glad I don't work with you.

    Awww, that's just darling. Be sure to let us know if you ever land in a real-world job with incompetent toxic coworkers and a useless boss who doesn't do anything to keep them in check.
  • Skeptic 2010-05-25 11:03
    Technically, he won the argument. Or, to put it another way:

    Meh. The usual one-sided comment written by the guy with no reading comprehension, and petulantly adds more crap comments to the Internet.

    //STOP WHINING
  • Anonymouse 2010-05-25 11:04
    Anonymously Yours:
    A lot of people hear rules, "best practices," and so forth and just commit them to memory. They don't actually think them through. They think you should reuse code whenever possible when, really, you should reuse code whenever practical.


    In my experience, the best cases of reusable objects are from cases where I didn't intend something to be reusable, but rather actually had the time to design the entire application properly, and re-use was a side-effect.
  • wtf 2010-05-25 11:07
    Zylon:
    wtf:
    "Morale boost" from promoting stupid inter-office squabbling over getting the job done? Gosh, I'm glad I don't work with you.

    Awww, that's just darling. Be sure to let us know if you ever land in a real-world job with incompetent toxic coworkers and a useless boss who doesn't do anything to keep them in check.


    Been there. The incompetent toxic co-workers usually tried to cover up their incompetence by playing politics.
    (You don't go by "Lyle", do you?)
  • Dr Solar 2010-05-25 11:21
    AnOldRelic:

    ...individuals who were considered by HR to be "under-qualified" because they only had 3-5 years' experience. Quality > Quantity. I'd sooner hire the 2-year rookie with a degree, a grasp of theory, the desire to learn and the ability to adapt...

    THIS! I'm finding it impossible to get into anything resembling a 'real' role because they see 3 years not in the filed I'm actually good at and trhow me straight into the bin.
  • Anonymously Yours 2010-05-25 11:27
    Anonymouse:
    Anonymously Yours:
    A lot of people hear rules, "best practices," and so forth and just commit them to memory. They don't actually think them through. They think you should reuse code whenever possible when, really, you should reuse code whenever practical.


    In my experience, the best cases of reusable objects are from cases where I didn't intend something to be reusable, but rather actually had the time to design the entire application properly, and re-use was a side-effect.
    Same here, actually. I think things come together better when you have a clear idea what to support and make your code flexible, rather than when you try to make your code flexible enough to support some great unknown.
  • Bosshog 2010-05-25 11:30
    When I re-invent the wheel, I sometimes add new features. Like corners.
  • Remy Porter 2010-05-25 11:32
    Anonymously Yours:
    Same here, actually. I think things come together better when you have a clear idea what to support and make your code flexible, rather than when you try to make your code flexible enough to support some great unknown.
    Never write flexible code for the sake of flexible code. At the same time, if you're doing application integration in your database, there's something horribly wrong.

    Flexible code arises from a clear understanding of your problem, not from inventing a generalized version of a problem and solving that, which is where mistakes happen. "Oh, I need to write a web presentation layer for customer accounts. My first step will be to write a generic web presentation layer and then customize it for customer accounts."

    If you really understand what your customer account system is supposed to do, and you implement to that with even a modicum of OOD, you're going to have code that's reasonably flexible, or can be refactored into something flexible.

    And when you need a more general presentation layer, you can pull up methods from your classes into newly created abstract classes that can be shared.
  • SOLID Man 2010-05-25 11:32
    Writing DAL and BLL layers that are totally and completely decoupled from any UI technology (such as ASP.NET or WinForms) is actually quite difficult to do. The temptation to stick an HttpContext.Current or a Windows.Forms.Form in your BLL is always there. It requires a certain mindset towards development to write DAL/BLL layers like this, a mindset geared more towards SOLID principles and a TDD/Unit Testing approach.

    If a dev refused to allow code reuse for the DAL/BLL from a Winforms app into a Web app, I'd immediately suspect that UI specific code had somehow crept into the DAL/BLL.
  • PRMan 2010-05-25 11:37
    wtf:
    java.lang.Chris;:

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    Works great if you're interviewing your twenty-year veteran employees. A good idea, perhaps, but not something that's done very often.


    Actually, this doesn't work at all if you are interviewing a 20-year veteran, since we invented all the best practices that you now call "Design Patterns". We don't know their new-fangled names, to us they are just called "no duh, don't be a first-year VB programmer".
  • facilisis 2010-05-25 11:37
    Bosshog:
    When I re-invent the wheel, I sometimes add new features. Like corners.


    So do I. You put a store-bought wheel on the ground, it rolls away. Not mine.
  • Barry 2010-05-25 11:47
    SOLID Man:
    Writing DAL and BLL layers that are totally and completely decoupled from any UI technology (such as ASP.NET or WinForms) is actually quite difficult to do. The temptation to stick an HttpContext.Current or a Windows.Forms.Form in your BLL is always there. It requires a certain mindset towards development to write DAL/BLL layers like this, a mindset geared more towards SOLID principles and a TDD/Unit Testing approach.

    If a dev refused to allow code reuse for the DAL/BLL from a Winforms app into a Web app, I'd immediately suspect that UI specific code had somehow crept into the DAL/BLL.


    True it takes dicipline I sometimes find myself wantign to fall into that with data validation where you need UI prompts as the data goes in.
  • bd 2010-05-25 11:51
    What you need is 1-5 GOOD Architect(s) that build the framework around which the developers can work.
    I wholeheartedly agree, frameworks produced by software architects are framework you have to work around a lot.
  • Jim Danby 2010-05-25 12:06
    Bullshit.

    Just because you have worked at a company for a long time does not mean you are automatically useless. I could make the same argument that everyone that I have met with only one year or less at a company was rubbish. even if it were true (it isn't), one person's experience does not represent the entire planet.
  • Jay 2010-05-25 12:13
    java.lang.Chris;:
    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    If you literally mean that to be a competent programmer someone must have read those two specific books, and that no other books on the subject will suffice, well, that's just idiotic ... oops, I mean, I think that's a little narrow-minded. Do you honestly believe that those two books are the only books ever written on the subject that are worth reading?

    P.S. I've read GoF. I've neither read nor, I must admit, heard of the Fowler book. I guess this makes me completely unqualified to touch a computer.
  • Jay 2010-05-25 12:14
    Jellineck:
    "Ignoring the fact that is idiotic," Jeff replied, "why would we do that? The UI and the DAL are completely separate. It doesn't matter how we present the data, the DAL is just fetching it."

    Someone needs to work on his interpersonal skills. Everything after the word "idiotic" will always be ignored. He might as well have said "Ignoring the fact that is idiotic, I read the Twilight book and cried the whole time."


    Or at leat, "Ignoring the fact that this is idiotic, I read the GoF Design Patterns book and cried the whole time."
  • wtf 2010-05-25 12:20
    Jay:
    java.lang.Chris;:
    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    If you literally mean that to be a competent programmer someone must have read those two specific books, and that no other books on the subject will suffice, well, that's just idiotic ... oops, I mean, I think that's a little narrow-minded. Do you honestly believe that those two books are the only books ever written on the subject that are worth reading?



    No, he means that applying this test will avoid this problem. This will eliminate potentially good candidates, such as yourself, but evidently that's a trade-off that he likes.
    (I don't think it's very good advice, but it's obvious what he means)
  • Jay 2010-05-25 12:22
    "For the umpteenth time in his tenure, he re-invented the wheel ..."

    Re-inventing the wheel is a stupid waste of time. That's why in the real world of wheeled vehicles, there is only one company in the world that makes wheels, they make exactly one kind, and it is used on all vehicles from passenger cars to children's tricycles to heavy construction equipment. Having different wheels for different kinds of vehicles would be insane. And of course the thought that someone might come up with improvements on the wheel has caused many people to waste countless hours fiddling with an invention that was already complete and perfect. The wheels used on chariots in 100 BC were good enough for Julius Caesar and they're good enough for me.
  • Me 2010-05-25 12:23
    PRMan:
    wtf:
    java.lang.Chris;:

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    Works great if you're interviewing your twenty-year veteran employees. A good idea, perhaps, but not something that's done very often.


    Actually, this doesn't work at all if you are interviewing a 20-year veteran, since we invented all the best practices that you now call "Design Patterns". We don't know their new-fangled names, to us they are just called "no duh, don't be a first-year VB programmer".


    I second this. The computer industry is packed with "new" ideas that have just been re-invented and re-named by somebody who didn't know they were already old news. Meanwhile, the old guys like me are looking at these "new" ideas and wondering what all the fuss is about.

    But if you're going to terminate the interview if I haven't read your favorite book, be sure to mention that in your ad. I can avoid wasting my time by coming to talk to you.
  • Vlad Patryshev 2010-05-25 12:29
    I agree, all those 20-year-veterans are mostly ignorant idiots. Refactoring is an insult to them. Well... even 10 years is too much. I've just left a company where a 10-year-veteran-architect threw away my unittests (in his niche, he never heard of them), because there was no "order from above" to do unittesting.

    I believe the only way to deal with them is to leave them alone. Let them code; there's enough places where people are up-to-date.

    (In case it sounds insulting to the veterans, I have to add that I started programming in 1970. Still learning, though.)
  • Vlad Patryshev 2010-05-25 12:31
    Maybe just asking what book have they read recently would suffice? I bet the last time they read a book was in XX century.
  • facilisis 2010-05-25 12:40
    Dr Solar:
    AnOldRelic:

    ...individuals who were considered by HR to be "under-qualified" because they only had 3-5 years' experience. Quality > Quantity. I'd sooner hire the 2-year rookie with a degree, a grasp of theory, the desire to learn and the ability to adapt...

    THIS! I'm finding it impossible to get into anything resembling a 'real' role because they see 3 years not in the filed I'm actually good at and trhow me straight into the bin.


    It is no wonder why you can't get into a 'real' role.
    Any resume with 2 or more typos gets thrown into the garbage can.
  • cklam 2010-05-25 12:41
    From the OP:
    He could grab the Windows team's DAL and business layer, slap a web front end, get the project done in a fraction of the time allotted for it, and make sure future maintenance helped both applications.


    Somebody was after a bonus ...

    From the OP:

    Over the course of the next week, the battle continued, in meetings, emails and conference calls.


    Invested a lot of time of his project's budget and wasted in the end wasted lots of people's time.

    From the OP:
    Carl, a twenty year veteran with the company, had more knowledge of the political terrain and out maneuvered Jeff.


    Which was most likely as easy as out-pacing an one-year old toddler ...

    From the OP:
    "I was apparently mistaken."


    ... and sees the error of his ways. Specifically that one should not pick a fight without good prior reconnaissance of the battle ground (the code base) and accurate intelligence about one's adversaries.

    Jeff would have been better off writing his own DAL and using the time reading good ole Dale Carnegies "How to make friends and Influence People" or "48 Laws of Power" by Robert Greene and Joost Elffers. :)
  • duis 2010-05-25 12:47
    Vlad Patryshev:
    Maybe just asking what book have they read recently would suffice? I bet the last time they read a book was in XX century.

    I thought Dos Equis only made beer.
  • Franz Kafka 2010-05-25 12:48
    Jay:
    "For the umpteenth time in his tenure, he re-invented the wheel ..."

    Re-inventing the wheel is a stupid waste of time. That's why in the real world of wheeled vehicles, there is only one company in the world that makes wheels, they make exactly one kind, and it is used on all vehicles from passenger cars to children's tricycles to heavy construction equipment. Having different wheels for different kinds of vehicles would be insane. And of course the thought that someone might come up with improvements on the wheel has caused many people to waste countless hours fiddling with an invention that was already complete and perfect. The wheels used on chariots in 100 BC were good enough for Julius Caesar and they're good enough for me.


    You're absolutely right. Either there's only one way to make a wheel or every wheel must be built from first principles. There's no way it could be something in between.
  • java.lang.Chris; 2010-05-25 12:50
    To all the dimwits saying that an understanding of systems design isn't a required skill for an "ordinary developer" - thanks, you've just confirmed how incompetent most developers are.
  • Anon 2010-05-25 12:52
    facilisis:
    Dr Solar:
    AnOldRelic:

    ...individuals who were considered by HR to be "under-qualified" because they only had 3-5 years' experience. Quality > Quantity. I'd sooner hire the 2-year rookie with a degree, a grasp of theory, the desire to learn and the ability to adapt...

    THIS! I'm finding it impossible to get into anything resembling a 'real' role because they see 3 years not in the filed I'm actually good at and trhow me straight into the bin.


    It is no wonder why you can't get into a 'real' role.
    Any resume with 2 or more typos gets thrown into the garbage can.


    +1 insightful
  • Peter 2010-05-25 12:53
    facilisis:
    It is no wonder why you can't get into a 'real' role.
    Any resume with 2 or more typos gets thrown into the garbage can.

    Should be "It is no wonder that..."

    Still, only one typo. You're still in with a chance ;-)
  • awefawef 2010-05-25 13:00
    java.lang.Chris;:
    There's only one thing worse than a two year veteran without a clue, and that's a twenty year veteran without a clue.

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    Obviously the veteran read the GoF book. He used Inversion of Control.
  • Mason Wheeler 2010-05-25 13:06
    Code Refuser:
    He should have expected that unless the application he was piggybacking on was designed with abstraction and re-use in mind, that whatever he was provided was going to be almost useless to him.


    QFT.
  • SCSimmons 2010-05-25 13:06
    This caught my attention on my second read-through:
    "No sanely developed ASP.NET app would have access to Windows Forms objects."
    Hey--that's not true! Here is a little rundown on reasons to do this, at the start of an article on how to do it. Although now that I look at it, reasons 3 and 4 are pretty stupid with regard to a production project ... and #1 is just laziness ... and you can't really determine #2 for sure until you test your app built both ways, which nobody would ever do ...

    Never mind--carry on!
  • Jaime 2010-05-25 13:33
    SCSimmons:
    This caught my attention on my second read-through:
    "No sanely developed ASP.NET app would have access to Windows Forms objects."
    Hey--that's not true! Here is a little rundown on reasons to do this, at the start of an article on how to do it. Although now that I look at it, reasons 3 and 4 are pretty stupid with regard to a production project ... and #1 is just laziness ... and you can't really determine #2 for sure until you test your app built both ways, which nobody would ever do ...

    Never mind--carry on!
    That's not ASP.Net using Windows Forms, that's ASP.Net emitting markup that causes Internet Explorer to host a Windows Forms control. It has every possible downside of a thick client app without most of the upsides.

    I have used Windows Forms in an ASP.Net app just for fun before. One of my students asked if it would be possible to take a complex graphing control and "webify" it. We simply instantiated the control and caused it to render to an in-memory image, then spit the image bytes out to the Response object.
  • Max Kode 2010-05-25 13:35
    We had a 20 year veteran who told us all about the wonderful redesign he had in mind, which would involve about 17 abstraction layers between the various front ends and the part that did the real work. The problem is, he was a little weak on the "real work" part.

    After a few years of promises and nothing else, he retired, and his grand project died a silent death about 20 minutes later.

    Abstraction is a tool, not an end goal.
  • duis 2010-05-25 13:39
    Peter:
    facilisis:
    It is no wonder why you can't get into a 'real' role.
    Any resume with 2 or more typos gets thrown into the garbage can.

    Should be "It is no wonder that..."

    Still, only one typo. You're still in with a chance ;-)

    It's No Wonder Why

    Typo infers a spelling error, but you are applying it to a grammatical choice.
  • NorgTheFat 2010-05-25 13:45
    iToad:
    ObiWayneKenobi:
    Carl, a twenty year veteran with the company


    MAJOR red flag right there. What is with these people who have worked for a company for years? Every single one I have met during my career was basically an ignorant sloth who knew nothing about proper software engineering practices and, when confronted or asked about doing things the right way, used seniority to shoot it down.

    I mean, I can understand using shitty practices when you're first learning the stuff; that's expected. But you should REALIZE it's a bad way of doing things, and constantly improve yourself so the next project, you do a little better. And the next, and so on until you're doing things properly. You don't keep churning out the same shit because you're too stupid to understand it's wrong and don't want to be bothered learning better ways.


    Sometimes, the twenty year veteran really has twenty years of experience. Sometimes, they only have one year of experience, twenty times.


    So true, so true...thankfully the place where I work, this sort of problem is kept in check (mostly)
  • anon 2010-05-25 13:50
    duis:
    Peter:
    facilisis:
    It is no wonder why you can't get into a 'real' role.
    Any resume with 2 or more typos gets thrown into the garbage can.

    Should be "It is no wonder that..."

    Still, only one typo. You're still in with a chance ;-)

    It's No Wonder Why

    Typo infers a spelling error, but you are applying it to a grammatical choice.


    s/infers/implies/
  • ObiWayneKenobi 2010-05-25 13:51
    I'm sure there are exceptions to the rule, just in my experience every time there's a senior developer, lead or manager who's big thing is they've been with the company since the start (was the first programmer, developed the first version, etc) the person in question always has no idea of new trends in doing anything, and typically the code is a sludge pit.

    It wouldn't be so bad if they at least understood that they've been "out of touch" for years and would LISTEN to the advice of people who know more, even if they're juniors (i.e. "Why would MVC be a better choice? Okay.. I see. Alright, that does sound like it would help us out." instead of "What's this newfangled MVC stuff? Back in my day we wrote all our logic and presentation together, and gosh darn it that's what we're doing now! That's why I'm the manager and you're the programmer."). But invariably the person also has a huge chip on their shoulder and won't listen to anyone who isn't above them on the hierarchy.
  • mainframe_web_developer 2010-05-25 14:47
    At first, these comments made me sad. I am 13 year veteran. But then I realize, there must be a lot of kids (<30) on the board.

    One guy thinks the gray beards don't know MVC and won't discuss simply because they are old and stubborn. Well, that's probably because this was the best practice for CICS which was invented the same year as Unix.. back in 1968.

    Sometimes folks stick around in a company because they actually like the company. They like the people. Sure, some are waiting for retirement.

    Do you find the veterans in your way? Do they make your job hard? Simple solution: ignore them. Do what needs to be done. No matter how loud PM, architects, DBAs, SVPs and all those others howl that you wrote the program the wrong way, the business-oriented guys will use it if it works. Stop talking and start doing.

    Maybe I am the only one who notices that the developers today only want to program for about six years. No project should last more than 15 months. After that, they expect to be in management...
  • Anonymously Yours 2010-05-25 15:00
    Remy Porter:
    Anonymously Yours:
    Same here, actually. I think things come together better when you have a clear idea what to support and make your code flexible, rather than when you try to make your code flexible enough to support some great unknown.
    Never write flexible code for the sake of flexible code. At the same time, if you're doing application integration in your database, there's something horribly wrong.

    Flexible code arises from a clear understanding of your problem, not from inventing a generalized version of a problem and solving that, which is where mistakes happen. "Oh, I need to write a web presentation layer for customer accounts. My first step will be to write a generic web presentation layer and then customize it for customer accounts."

    If you really understand what your customer account system is supposed to do, and you implement to that with even a modicum of OOD, you're going to have code that's reasonably flexible, or can be refactored into something flexible.

    And when you need a more general presentation layer, you can pull up methods from your classes into newly created abstract classes that can be shared.
    ... are you expanding on my point or are you unaware you're agreeing with me? I honestly can't tell from the way you wrote that.
  • monkeyPushButton 2010-05-25 15:23
    mainframe_web_developer:
    Maybe I am the only one who notices that the developers today only want to program for about six years. No project should last more than 15 months. After that, they expect to be in management...
    Lord no. I've seen management's job and I don't want it. Then again, being a gov't employee, my work is slightly different than a standard corporate environment.
  • LANMind 2010-05-25 15:33
    TRWTF is all the supposed architects offering highly situation-dependent practices.
  • AnOldRelic 2010-05-25 15:34
    mainframe_web_developer:
    Do you find the veterans in your way? Do they make your job hard? Simple solution: ignore them. Do what needs to be done. No matter how loud PM, architects, DBAs, SVPs and all those others howl that you wrote the program the wrong way, the business-oriented guys will use it if it works. Stop talking and start doing.

    The problem is, juniors can't "just ignore them." Often, we are team-leads, management, or generally higher up than them. We hold their jobs (and effectively livelihoods) in the balance. I don't use my seniority to bully, but that's just out of an ethical choice. I can guarantee that there are many old-timers who would willingly crush progress and innovation in favor of comfort and the familiar.

    I'm a 17-year veteran myself. I think the problem is not so much veterans themselves, as it is an inability (or unwillingness?) to change the way of doing things out of fear of obsolescence. When I started, processors had a single pipeline, a single core, and tracing assembly from start to finish could be done in a matter of a couple of hours, and optimizing said assembly was a job I could do in my sleep. Hardware complexity has grown by leaps and bounds, often leaping by several orders of magnitude in a fraction of my lifetime. Keeping up is certainly not easy, and I could see why many of my contemporaries/colleagues simply gave up on keeping up with current trends.

    Sure, I remember FORTRAN, and have many fond (or hate-filled, not sure which yet...) memories of COBOL. But I sure am not going back there without having a genuine need/requirement. I've grown through multiple iterations of C/C++, and have slowly slipped into developing in C# on many .Net applications. But - that's all entirely not the point. The point is, the arguments I have with some of those I've worked with in years' past have all stemmed around a definite "get off my lawn" mentality these individuals maintain. The bulk of their argument boils down to little more than a simple "Back in my day, I had to walk fifteen miles to/from school, in the snow, up-hill, both ways."

    When these arguments began, it was "Why would you ever use C++ over C?" Now it's "Why would you ever use C# over C++?" Next, I'm waiting for the "Silverlight? Why not use classic ASP?!" And this is why I'm tired of working with them and tend to hire the younger, less entrenched crowd. At least they're willing to learn and make improvements without a major verbal brawl. I've learned a lot from my junior devs, as I'm sure they've learned a lot from me. But I can guarantee I'm a minority among my generation of programmers, and that's genuinely discouraging.
  • ObiWayneKenobi 2010-05-25 15:58
    AnOldRelic:

    The problem is, juniors can't "just ignore them." Often, we are team-leads, management, or generally higher up than them. We hold their jobs (and effectively livelihoods) in the balance. I don't use my seniority to bully, but that's just out of an ethical choice. I can guarantee that there are many old-timers who would willingly crush progress and innovation in favor of comfort and the familiar.


    This. I've worked with a few "experienced veterans" that knew their shit and who I could learn a lot from. I've worked with far more people who used tenure to achieve seniority, and routinely knew nothing about modern development and squashed any and all attempts at using best practices. Hell, I've actually been FIRED from jobs for trying to get the team to care a little about craftsmanship instead of doing things the old crufty way they had been using for years. The veteran was much like the one in this story and wouldn't have any of that newfangled nonsense because he couldn't understand it, and the idea that a junior developer might know something he didn't was downright heresy.

    This is the more common scenario. Well-meaning junior developers, who spend their time learning and broadening their skills, come head to head with "senior" (in tenure, not always in experience) developers or team leads or IT Managers who are incapable of understanding this, and out of fear of them showing their own incompetency kill any notion of doing things "right", and punish anyone who dares to try and point out a better way of doing things.

    I think it has a lot to do with the fact a lot of BS artists got into IT during the dot com boom, and hoodwinked management into trusting them. As the years rolled on these people have stayed in their cushy jobs so they get promoted. Eventually, you have managers and seniors who really don't know anything because they just BSed their way in when nobody knew anything about computers or programming or the internet. Out of fear of losing their cushy position they have to squelch others who might upstage them, because the truth (i.e. that they're incompetent BS artists) might come to light.

    Not saying EVERYONE is like that, but there are still a lot of them out there running (or should that be "ruining") IT departments.
  • EvanED 2010-05-25 16:07
    Me:
    I second this. The computer industry is packed with "new" ideas that have just been re-invented and re-named by somebody who didn't know they were already old news. Meanwhile, the old guys like me are looking at these "new" ideas and wondering what all the fuss is about.


    To be fair, at least the GoF people acknowledged that. They specifically say that nothing in that book is stuff they came up with, and that what they did was to describe practices that were already in use and give them a name so that programmers and architects would have a vocabulary to talk about what they were doing.
  • marv 2010-05-25 17:03
    ObiWayneKenobi:
    MAJOR red flag right there. What is with these people who have worked for a company for years? Every single one I have met during my career was basically an ignorant sloth who knew nothing about proper software engineering practices and, when confronted or asked about doing things the right way, used seniority to shoot it down.

    What it is? I'll tell you what it is. They were never able to get a job anywhere else, or too insecure to even dare trying.
  • Quirkafleeg 2010-05-25 17:50
    AnOldRelic:
    When these arguments began, it was "Why would you ever use C++ over C?" Now it's "Why would you ever use C# over C++?"
    (Those should be either “choose X over Y” or “use X instead of Y”.)

    Let's turn that around.

    I use C rather than C++ because there's less complexity (and anyway, I'd probably end up with C-like code anyway); and I'd use C++ rather than C# because of a certain large monopolist (and I know more about C++).
    Next, I'm waiting for the "Silverlight? Why not use classic ASP?!"
    With ASP, you're only maintaining one copy of the site…?

    Then there's “Silverlight? Why not use Flash?” – but let's turn that around again: why use Flash, not Silverlight?

    User base (for public-facing sites), and that large monopolist in the background.

    OTOH: web sites implemented using Flash, Flash buttons chewing up CPU time (and, possibly, battery), and Flash adverts chewing up CPU time. Although those are arguments for using plain HTML (and not visiting sites which do these things, or at least preventing the Flash files from being run), not for using Silverlight (or Moonlight) instead.

    … not seen any of these for years, though! ☺
  • Peter 2010-05-25 18:27
    duis:
    Peter:
    facilisis:
    It is no wonder why you can't get into a 'real' role.
    Any resume with 2 or more typos gets thrown into the garbage can.
    Should be "It is no wonder that..."

    Still, only one typo. You're still in with a chance ;-)
    Typo infers a spelling error, but you are applying it to a grammatical choice.
    Nah, I was giving the benefit of the doubt - assuming that he knew the correct phrase, but had just mistyped it.
  • Pants 2010-05-25 19:31
    You seem rather optimistic. My organization skips the Architect, Project Manager, and every other type of management role. In many cases, an individual developer plays all roles, including server admin, etc, etc. It's kind of a nightmare, but no one likes to make waves.
  • Veldan 2010-05-25 19:33
    Remy Porter:

    Honestly, when I read the submission, I had to make sure Jeff wasn't a co-worker. Because my company has a crapload of applications like that.


    Hands up anyone else who is stalking the office trying to find "Jeff"?

    *Hand up*
  • icebrain 2010-05-25 19:34
    Quirkafleeg:
    I'd use C++ rather than C# because of a certain large monopolist (and I know more about C++)

    There's always Mono.
    Also, let's not use neither Flash nor Silverlight, they're both s***. Unless you're making web games, HTML+CSS+Javascript is all you need.

    About PoEEA, I disagree that only software architects should know the patterns (they don't have to have read the book, but knowing the names is mandatory for good communication); any software developer should know how to identify and implement the patterns, even if they're not required to know *when* to use them.

    I have the book and it's very interesting, especially for someone with virtually no experience like me.
  • Dave 2010-05-25 21:14
    I've seen code where I work that was obviously written by somebody who's idea of "code reuse" was copy/paste.

    Although I like the first rule of code reuse. I'm going to reuse that.
  • Quirkafleeg 2010-05-25 21:35
    icebrain:
    Quirkafleeg:
    I'd use C++ rather than C# because of a certain large monopolist (and I know more about C++)
    There's always Mono.
    Yes… but that's… sort of… well… indirectly tainted. IMO.
    Also, let's not use neither Flash nor Silverlight, they're both s***.
    As far as is practical.
    Unless you're making web games, HTML+CSS+Javascript is all you need.
    BBC iPlayer. Want to reimplement that?

    Well, yes, they could get away with streamed video, up to a point; but rights holders may well want their video or audio to be ‘protected’, and the BBC have little choice but to comply if they want to make that content available.
  • AnOldRelic 2010-05-26 00:20
    Quirkafleeg:
    Let's turn that around.

    I see your point, and am not arguing it. However, where I am arguing is the inability for people to see benefits in the new instead of hacking away at the old. Far too many applications and existing libraries in the world are kludge on top of kludge with some crap in between as mortar. Refusing to give them up in favor of something new because it's new and contrary to principle or past practices (past, not best) leads to stagnation, lack of innovation, and frankly, the kind of entrenched, thick-headed individuals I personally have broken away from. I still use assembly, C, C++, and even dabble back in COBOL where I need to, but I don't cling to them as if they were my only floatation device keeping me afloat and from sinking into the liquid abyss of joblessness. (Every language/IDE has a use. Except VB. That can go die a firey, painful death.)

    icebrain:
    Also, let's not use neither Flash nor Silverlight, they're both s***. Unless you're making web games, HTML+CSS+Javascript is all you need.

    I can't tell if you're being serious or sarcastic. Though - I partially agree here. Unless you're presenting a media-rich application, there's no need for Flash or Silverlight. But - still a far cry from my point. I was providing simple, contemporary examples. What I was poking at were the people who still insist on using classic ASP when the rest of the world has taken two giant leaps "ahead" and have found greener pastures.
  • SCSimmons 2010-05-26 01:03
    Jaime:
    I have used Windows Forms in an ASP.Net app just for fun before. One of my students asked if it would be possible to take a complex graphing control and "webify" it. We simply instantiated the control and caused it to render to an in-memory image, then spit the image bytes out to the Response object.

    Goose:
    Is this your idea of fun, Mav?
  • mcalex 2010-05-26 02:37
    he hasn't used a common phrase, but 'it is no wonder why ...' isn't incorrect. Personally, I'd not have 'why' or 'that' or anything else there. 'It is no wonder you can't get into a 'real' role' works fine.

    2c
  • Nyan 2010-05-26 04:36
    "Carl glared at him like Jeff had been bitten by a zombie and might turn at any moment."

    Who would glare at a zombie-bitten person while waiting for them to turn? =[

    -----------------------

    A scene from Code Refuse, zombie edition:

    Everyone stared at Jeff, wide-eyed in horror, their faces twisted into expressions of sheer dread... except for Carl, who could only find himself consumed with utter rage.

    Carl glared at Jeff angrily. "Why did you have to go and get yourself bitten!?" he bellowed. "I told you a MILLION TIMES not to let them bite you!"

    "I'm sorry!" moaned Jeff. "It just came out of nowhere, I couldn't get away fast enough... AUGHH--!" He coughed violently and grabbed at the bite wound.

    Carl shoved Jeff up against the wall. "Just tell me this one thing. Did you reuse any of my team's DAL in your web app?" he hissed through clenched teeth.

    "I... I d-..." Jeff's body began to convulse wildly as the virus began to take over and he struggled to form words.

    "DID YOU, OR DID YOU NOT?!" Carl roared. "Tell me, NOW! The survival of all humanity may rely on this!"

    "I... AUUGHHH-!!" Jeff screamed.

    Carl shook Jeff's contorting body by his shirt collar. "I need to know this!! JEFF!"

    It was too late.
  • callcopse 2010-05-26 04:48
    To summarise then, experienced or inexperienced developers can be closed or open in their outlook. Those who never move jobs at all seem particularly prone to being one dimensional in their programming. The grimy code of those set in their ways can still be useful but we will still all point and laugh. Most seasoned software developers are also pedants.
  • TInkerdom 2010-05-26 05:11
    Dave:
    I've seen code where I work that was obviously written by somebody who's idea of "code reuse" was copy/paste.

    Although I like the first rule of code reuse. I'm going to reuse that.


    My last coding job had 3 separate instances of code that independently calculated the taxes. Worse, all 3 were written differently. Worse still, they were out of sync in different ways.
  • SCB 2010-05-26 07:49
    facilisis:
    Bosshog:
    When I re-invent the wheel, I sometimes add new features. Like corners.


    So do I. You put a store-bought wheel on the ground, it rolls away. Not mine.

    Yeah, but watch out for those inverted catenaries!
    http://en.wikipedia.org/wiki/Square_wheel
  • Helix 2010-05-26 07:50
    Quirkafleeg:
    icebrain:
    Quirkafleeg:
    I'd use C++ rather than C# because of a certain large monopolist (and I know more about C++)
    There's always Mono.
    Yes… but that's… sort of… well… indirectly tainted. IMO.
    Also, let's not use neither Flash nor Silverlight, they're both s***.
    As far as is practical.
    Unless you're making web games, HTML+CSS+Javascript is all you need.
    BBC iPlayer. Want to reimplement that?

    Well, yes, they could get away with streamed video, up to a point; but rights holders may well want their video or audio to be ‘protected’, and the BBC have little choice but to comply if they want to make that content available.


    TRWTF was BBC trying to protect the content in the first place.
  • TimG 2010-05-26 07:58
    AnOldRelic:
    I've learned a lot from other people, as I'm sure they've learned a lot from me. But I can guarantee I'm a minority among human beings, and that's genuinely discouraging.

    FTFY.
  • PB 2010-05-26 08:27
    Is nobody else wondering whey they seemed to have spend an inordinate amount of time arguing about whether this code should be used before Jeff had even looked at it to see if it was suitable? Little experience might have helped here...

    Just because it's called a DAL doesn't necessarily mean that's actually just what it's doing.
  • AnOldRelic 2010-05-26 09:32
    PB:
    Is nobody else wondering whey they seemed to have spend an inordinate amount of time arguing about whether this code should be used before Jeff had even looked at it to see if it was suitable? Little experience might have helped here...

    Just because it's called a DAL doesn't necessarily mean that's actually just what it's doing.


    I think they were arguing if Jeff should have been allowed to even SEE the code, let alone re-use it. Either way, a little experience and arguably a little cynicism (which comes from the experience) would have prevented the wasted time.
  • wutwut 2010-05-26 11:28
    Actually, it probably should be: "It is no wonder you can't..."


  • operagost 2010-05-26 11:54
    TRWTFs are people who don't understand what the cliche "reinventing the wheel" means, or even the difference between "improving" and "inventing" for that matter.
  • Luis Espinal 2010-05-26 12:39
    Zylon:
    wtf:
    "Morale boost" from promoting stupid inter-office squabbling over getting the job done? Gosh, I'm glad I don't work with you.

    Awww, that's just darling. Be sure to let us know if you ever land in a real-world job with incompetent toxic coworkers and a useless boss who doesn't do anything to keep them in check.


    Nope, gotta disagree with you here. The fact is that in any job and in any type of work, whether doing software or flipping burgers, you will deal with incompetent/toxic people to one degree or another.

    I used to believe in the same stupidity of shooting incompetent people down, when I was young and inexperienced and thought I was Dijkstra's second coming. Working in the real world showed me pretty quickly I wasn't (not even by a long shot).

    Furthermore, I quickly realized that professionalism and smoothing things out in the office are part of my job description, even if those are never spelled out during the hiring process. Most importantly, I learned that shooting people down, even the truly inept, that was just projection of insecurities or arrogance from my part. None of that has any place at work, at any work.

    We. Do. Not. Get. Paid. To. Do. That. Shit.
    We get paid to get things done with the least drama and insult possible. Drama and stupidity are unavoidable, but that doesn't mean I have to contribute to them. I cannot control other people's stupidity. I can only control my own. Implicitly, it is part of our job to control our own stupidity, and just because co-worker cannot do that part of his job, that does not mean I should be equally inept at that.

    The only time conflict is to be used if it to the business' benefit (and ultimately, developing software is a means to promote a business benefit.)

    If I run into an incompetent person,

    1. I try to reason with them (and I save every piece of email wrt to this effort).

    2. If I can't, then I work around them (and save every piece of email wrt to this effort... and if it helps me, I'll let my manager know to that effect).

    3. If I can't work around, then I escalate in a professional manner (here, every piece of e-mail and docs saved come handy).

    4. If that doesn't work, then I shrug my shoulders. If something breaks because #3 didn't work, I've already have a trail indicating I did my job in preventing so. And if nothing breaks significantly, nothing was lost (my ego does not rely on things breaking for me to say "I told you so.")

    5. And if #4 doesn't work, and if #3 and #4 occur continuously and generates a lot of drama, then I simply do the professional thing to do: I leave as soon as it is financially prudent.




    Your professional creed and quality of work experience are not a boolean function of whether you have worked in a real-world environment with incompetent, toxic people (that is an almost constant given.) Instead, they are a function of whether you can work and behave ethically and professionally in a toxic environment.

    I can understand young cowboys fresh out of college not understanding this. But for people who claim to have real world experience, how could you not know this? It is beyond me.
  • frits 2010-05-26 13:21
    Well said. +1000
  • Patrick 2010-05-26 13:44
    Carl, a twenty year veteran with the company


    I've learned not to mess with those guys, just do your job, and let them self-destruct at some point. Also calling the twenty year veteran an "idot, " in a meeting is a surefire way to lose the argument. Even if you win the argument, it will only breed harsh resentment in the future by the guy who has more clout than you and eventually bite you in the ass.
  • EngleBart 2010-05-26 15:57
    Why not just create a terminal services or Citrix application for the windows form application?

    Guarantees 100% reuse and the same logic. The progress bar and status bar would even work!

    No need to reinvent the wheel, just hook up the pipes to get the wheel displayed where you need it.
  • RogerInHawaii 2010-05-26 16:38
    java.lang.Chris;:

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    And perhaps that's a good suggestion for any potential employee to ask of his/her potential employer. Who wants to work for someone who hasn't got a clue?
  • Gumby 2010-05-26 17:12
    java.lang.Chris;:

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    What if you're not an OO weenie, and you prefer functional or logic programming instead? Besides, I've worked with people who read such things, missed the whole point, and wrote superficially OO code that was just unrelated method/function calls grouped together in an arbitrary class.

    And why not include "Code Complete" in your list? I hear people recommend that also. I didn't get much out of it. I guess I have an uncanny grasp of common sense.
  • Marshall 2010-05-26 18:37
    Warning - politically incorrect language follows ...

    (IMO) The ability to actually work in abstractions rises with intelligence. My guesstimate would be that the ability to use design patterns as part of a design process wouldn't kick in until at least the 80/90 percentile.

    So I agree with an earlier post that suggested you get your (few) architects who can do this and (once you trust them) make the foot soldiers follow the design even if they don't understand it.

    And as also posted, designing with patterns (or good OO design) is a skill an order of magnitude higher than answering an exam on the contents of the book.
  • Steve Parker 2010-05-26 19:22
    So, the story is that a MSWindows program used MSWindows structures?

    As a Unix/Linux person, I would be very surprised if any interfaces (other than, say, direct access to the back-end database, through something structured such as SQL, XML, etc) would escape the MSWindows-specific stuff.

    What am I missing?
  • frits 2010-05-26 21:53
    Gumby:
    java.lang.Chris;:

    Ways to avoid this kind of cluster fuck is to ask any potential employee whether they've read Fowler's "Patterns of Enterprise Application Architecture" and the GoF "Design Patterns" book. If they haven't, then terminate the interview there and then. If they have, find out the depth of their understanding, such as whether they understand the Observer pattern and separation of concerns.


    What if you're not an OO weenie, and you prefer functional or logic programming instead? Besides, I've worked with people who read such things, missed the whole point, and wrote superficially OO code that was just unrelated method/function calls grouped together in an arbitrary class.

    And why not include "Code Complete" in your list? I hear people recommend that also. I didn't get much out of it. I guess I have an uncanny grasp of common sense.


    I agree with your basic premise, but just so you know: Design Patterns != OO.
  • not even 5 yrs experience. 2010-05-27 18:34
    Also, I would just point out that sometimes, they do not want to touch the already working code because it would require additional resources to verify that it still works. From a business perspective, they would only care about what costs less money. ofcourse there are very rare cases where its cheaper to refactor and fix the code. but in general from a developer's perspective its always better to fix the code now.

    If it ain't broken, don't fix it. (or use correct processes for that matter)
  • Jay 2010-05-28 03:50
    A wise man once said -- not talking about IT but it probably applies to almost everything in life, It is just as foolish to embrace every new idea out of a love of novelty as it is to reject every new idea out of a fear of change.

    Yes, I've known plenty of programmers who refused to learn a new language because FORTRAN is perfectly good, why do we need this new-fangled stuff. On a less dramatic level, it is easy to fall into the trap of not being willing to learn something new because what you are able to get done what you need to get done with what you already know. The catch, of course, is that if you learned something new you might be able to do it better and faster, or you might be able to do things that you didn't know you really needed to do.

    But on the flip side, I've also known plenty of programmers who are constantly jumping on the latest bandwagon, who think they are great programmers because they know 100 languages or tools or frameworks. Except, they don't really know how to get anything useful done in any of them. They just know how to repeat what's in the marketing literature, and maybe put together a demo app that says "Hello, world."
  • Gary Wheeler 2010-05-29 08:01
    iToad:
    ObiWayneKenobi:
    Carl, a twenty year veteran with the company


    MAJOR red flag right there. What is with these people who have worked for a company for years? Every single one I have met during my career was basically an ignorant sloth who knew nothing about proper software engineering practices and, when confronted or asked about doing things the right way, used seniority to shoot it down.

    I mean, I can understand using shitty practices when you're first learning the stuff; that's expected. But you should REALIZE it's a bad way of doing things, and constantly improve yourself so the next project, you do a little better. And the next, and so on until you're doing things properly. You don't keep churning out the same shit because you're too stupid to understand it's wrong and don't want to be bothered learning better ways.


    Sometimes, the twenty year veteran really has twenty years of experience. Sometimes, they only have one year of experience, twenty times.


    I get my '20' at my current employer this year. I find your generalities about long-term employees... disturbing.

    Most of the long-term types I know are bona fide experts at what they do. They bring a level of knowledge, experience, and pragmatic wisdom to a project that pays off in more robust solutions. Youngsters who fail to appreciate this invariably either re-invent the wheel or fail miserably.

    Even though it has become cliche, I'm reminded of this: I'll always take age and treachery over youth and zeal.
  • Hubert Humphrey 2010-05-29 11:07
    I believe I may have worked at that place. Briefly.
  • oksupra.com 2010-06-19 03:07
    Supra shoes are so popular all over the world. Whatever you take on Supra being in the Supra Skytop Shoes market. Now Supra Strapped Shoes also very popular attention. It is nice that they actually took the time to make Supra Skate Shoes that work well. Supra shoes is a brand that has been inspired, designed and marketed by passionate individuals. We have brought to you the fullest selection of Supra footwear at cheapest price. Overload Skateshop carries a wide range of Supra Shoes to fit your 9-stair kickflips.


  • oksupra.com 2010-06-19 03:09
    Supra shoes are so popular all over the world. Whatever you take on Supra being in the Supra Skytop Shoes market. Now Supra Strapped Shoes also very popular attention. It is nice that they actually took the time to make Supra Skate Shoes that work well. Supra shoes is a brand that has been inspired, designed and marketed by passionate individuals. We have brought to you the fullest selection of Supra footwear at cheapest price.


  • Programmer 2010-08-19 16:23
    I've heard this for the first time from a manager of a previous job a couple years ago, and... oh boy... so many times I've seen it proven it right (the sad way, unfortunately)!
  • Stewie 2010-08-20 10:59
    [quote user="iToad"][quote user="ObiWayneKenobi"]

    Sometimes, the twenty year veteran really has twenty years of experience. Sometimes, they only have one year of experience, twenty times.
    [/quote]

    BEST Quote EVER ! !!
  • TheCPUWizard 2011-04-27 12:28
    Actually, I believe things were in much better shape when people did spend their careers with one company. There was significant value to be gained by the company investing in the person. These days, that is gone.

    As a concrete example, I worked for the samecompany from 1977 until 1992, and only left when the defnense industry crashed. It was fairly common for an engineer to spend 1 or even 2 weeks at company funded (all expenses) training, along with additional time for smaller seminars, conferences, etc.