• (cs)

    Look at the bright side -- maybe Victor's delays prevented his Wall Street bank from making some brain-dead loans.

  • (cs)

    What do you know, a happy ending!

    People like Victor give the rest of us programmers a bad name.

  • Eric (unregistered)

    DECLARE COMMENT AS TEXT DECLARE CAPTCHA AS TEXT INPUT COMMENT, CAPTCHA ON FORM IF ISCORRECT(CAPTCHA) THEN OUTPUT COMMENT ON FORM

  • (cs)

    Someone should have told Victor about LUA/Python/whateveryoucanintegrateonothersoftware...

  • Mark (unregistered)

    Apparently Victor has never heard of the Gathering Requirements phase of software development. Nor has he ever come across a Business Analyst either.

  • biziclop (unregistered)

    It's funny how all the stories nowadays seem to be about the pig-ignorant in-house developers confronting the intrepid and ingenious consultant.

    Whereas usually it's the other way around, most consultants don't know anything about anything, except acronyms and generic systems, so all they will suggest is you should stop developing a specific solution and try using Spring MVC and Axis.

    Even if the project isn't written in Java.

  • (cs)

    I certainly hope that Victor's access to the system was disabled as soon as he resigned.

    http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9127157

  • (cs)

    Let me get this straight. Victor was supposed to write a program to do loan underwriting. But he didn't want to, so instead he wrote what he had always wanted to write: MS Access, without the database. (To be fair, the database component was "practically done.") Then he wanted to push the job of actually writing the loan underwriting program back onto the customer, and he expected them to be happy about it.

    Contrast that with Bruce's "traditional" approach, which was to actually write the program he was hired to write.

    If you hire me to build a car, I'm going to build a car. I won't start by building my own wrenches, and I certainly won't finish by giving you the wrenches and telling you to do the rest.

  • Nodody (unregistered)

    This is why you need managers who actually understand software. The only way this project could have been approved is by someone whose eyes glazed over after the first ten seconds. "Sure, whatever, just make it work."

  • MK (unregistered)

    One more example of the famed Inner-Platform Effect.

  • Neil (unregistered)

    This seems like the opposite side of half of most TDWTFs - normally we have some bright IT guy getting overridden by some idiotic consultant or cleaning up after some idiotic consultant who was paid the huge hourly rate.

  • Chris (unregistered)

    I wonder if we might, perhaps be hearing a slightly partial view of the story. I've been in situations where bludgeoning management into providing the detailed workflows and specification was nigh on impossible and what specifications there were shifted each week. The tempation to create a "generic system builder was strong.

    I can imagine that getting a highly paid external consultant in might well have focussed management's thinking sufficiently to get them to cough up the specs, leaving Victors' work un-necessary.

  • (cs) in reply to Andy Goth

    You know, this reminds me of C++. C is fine for what it is, but many people wanted (let's say) first-class strings. But rather than put strings in C++, Bjarne put in lots of fancy-yet-low-level structure and function definition scaffolding which could conceivably be used to create an almost-first-class string. But he didn't actually put in true string support. That task was left to the same people who clamored for strings in the first place. Eventually a string was standardized, but it took a long time, and it's still not first-class. "a" + "b" doesn't work, but std::string("a") + "b" does. FAIL.

    C++ doesn't have solutions; it has meta-solutions.

  • (cs)

    Poor Victor, he was on the verge of creating the next generation of software. Had those short sighted fools only recognized his brilliance they could have revolutionized the industry!

  • biziclop (unregistered) in reply to Neil
    Neil:
    This seems like the opposite side of half of most TDWTFs - normally we have some bright IT guy getting overridden by some idiotic consultant or cleaning up after some idiotic consultant who was paid the huge hourly rate.

    Only in real life it's not 50/50 but rather 90/10. Either way, if you have to bring a consultant in after years of development, TRWTF is your company's management.

  • Frustrated coder.. (unregistered)

    I remember I had a boss who was determined to build a fully configurable system. Quite what it was or how it was supposed to work wasn't clear, but he was keen on software being "configurable".

    After one project was completed and shown to be working fine he asked me if it was configurable.

    "No." I replied "I mean yes," was my second instantaneous reply.

    He gave me a look that seemed to indicate he thought I was taking the piss, but didn't quite know how to pull me up for it.

    He was then made redundant a few months later, the Head of IT had realised what a numbskull he was.

  • Mark (unregistered) in reply to Frustrated coder..
    Frustrated coder..:
    He was then made redundant a few months later, the Head of IT had realised what a numbskull he was.

    So you're saying this story is made up then?

  • (cs) in reply to Chris
    Chris:
    I wonder if we might, perhaps be hearing a slightly partial view of the story. I've been in situations where bludgeoning management into providing the detailed workflows and specification was nigh on impossible and what specifications there were shifted each week. The tempation to create a "generic system builder was strong.

    I can imagine that getting a highly paid external consultant in might well have focussed management's thinking sufficiently to get them to cough up the specs, leaving Victors' work un-necessary.

    So potentially the real WTF is that a short term usage of a computer business analyst hadn't been utilised rather than an expensive long term consultant.

    If the scopes crap, then you are going to get a crap product. However, I think Victor may not have been a people person which does not help.

  • Rob (unregistered)

    There is some truth to feeling like the outside consultants are only able to fix a problem because they are the only ones tasked with fixing the problem.

    As a younger developer I'm given a big stack of things to do, lower level implementation details. There's plenty of work to be done, and I'm expected to plug away and work on it. My task is large, without any deadline or ending in site. So that's my task, and I do it.

    However, larger issues exist in our code base. Architectural issues, performance issues, poor coding practices.

    Since 100% of my time is spent tasking away on my little project; I'm never asked to address performance issues or to give a talk about how to improve our developers coding....but I could.

    It turns into a frustrating catch-22....

    You end up in a situation where your developers are focused on new development, perpetually behind schedule, coding away because that's what they've been told to do; then you bring in a high paid consultant or hire someone new into a new position who is asked to address those issues. They get paid bigger $$$ and get to 'save the day' when there were developers on the team, already working there, who already knew of the issues and who could have resolved them, just the same as the consultant; if they were just given the opportunity.

  • BigG (unregistered) in reply to Nodody
    Nodody:
    This is why you need managers who actually understand software. The only way this project could have been approved is by someone whose eyes glazed over after the first ten seconds. "Sure, whatever, just make it work."

    Except Victor made management work?

    Captcha: feugiat = fugetibouit?

  • Ryde (unregistered) in reply to Andy Goth

    When designing a system that is supposed to be user-configurable, I ask myself this question: "Is this actually configurable by the user, or are they going to have to ask a programmer to do so?" In a large number of cases, the answer is "Yes, they'll have to get a programmer." If that's the case, then its probably not going to be worthwhile to expend effort into anything other than code.

    Users can handle simple configuration options. Asking them to build their own rules into the system is usually too much.

  • jrrs (unregistered)

    This reminds me of a time and expense accounting system written by an individual entirely in APL(!) at our workplace sometime in the early '80s. Apart from the special keyboards required by the clerks, he (and his program) was canned when the director found out it was costing $20k each month for the usual accounting summaries. These days we have SAP. :-)

  • Paula (unregistered)

    DECLARE PAULA AS BEAN PRINT BRILANT

  • iMalc (unregistered)

    I guess you'd call that a Victor-y.

  • SoonerMatt (unregistered)

    I see working with consultants as a huge opportunity. They are there to strictly "get things done" and they have worked in a wide range of situations.

    Although it can be treated as a slap in the face that management had to hire someone else to do your work, it shouldn't be seen as such.

    I have had some great networking opportunities and learned alot from working with consultants/contractors.

  • rgz (unregistered)

    Poor Victor, he had a dream, I respect that...

  • (cs) in reply to biziclop
    biziclop:
    It's funny how all the stories nowadays seem to be about the pig-ignorant in-house developers confronting the intrepid and ingenious consultant.

    Whereas usually it's the other way around, most consultants don't know anything about anything, except acronyms and generic systems, so all they will suggest is you should stop developing a specific solution and try using Spring MVC and Axis.

    Even if the project isn't written in Java.

    I've seen (and been) both, and it goes both ways. Some consultants do suck, but they often have nice specialized skills that can be very effectively applied in a limited situation: most full timers have to do many different things, and while they may know more about their systems, that doesn't make them overall experts in specific technologies. If you need some specific thing built, it's usually better and quicker to go to an expert in that sort of system.

    On the other hand, consultants are specialty tools, and if you get a generic consultant, he's just going to milk you for money while not accomplishing anything measurable.

  • my name is missing (unregistered)

    The problem with most expert systems is they are written by people who are an expert in nothing.

  • WC (unregistered) in reply to Rob

    "They get paid bigger $$$ and get to 'save the day' when there were developers on the team, already working there, who already knew of the issues and who could have resolved them, just the same as the consultant; if they were just given the opportunity."

    You were. You said nothing when you saw the problems.

    Every software development company has both new development and bugfixes all the time. Your chance to be 'the hero' was to take one of those problems and just fix it. Believe me, if you do fix it in a reasonable amount of time, the amount of time you are behind on your other projects will be forgiven.

    On the other hand, if you fail, or take too long, it will go very badly on you.

    To excel, instead of just succeed, you have to take risks. Any businessman will tell you that.

  • Harold (unregistered) in reply to Rob
    Rob:
    There is some truth to feeling like the outside consultants are only able to fix a problem because they are the only ones tasked with fixing the problem.

    As a younger developer I'm given a big stack of things to do, lower level implementation details. There's plenty of work to be done, and I'm expected to plug away and work on it. My task is large, without any deadline or ending in site. So that's my task, and I do it.

    However, larger issues exist in our code base. Architectural issues, performance issues, poor coding practices.

    Since 100% of my time is spent tasking away on my little project; I'm never asked to address performance issues or to give a talk about how to improve our developers coding....but I could.

    It turns into a frustrating catch-22....

    You end up in a situation where your developers are focused on new development, perpetually behind schedule, coding away because that's what they've been told to do; then you bring in a high paid consultant or hire someone new into a new position who is asked to address those issues. They get paid bigger $$$ and get to 'save the day' when there were developers on the team, already working there, who already knew of the issues and who could have resolved them, just the same as the consultant; if they were just given the opportunity.

    I sometimes get to be the highly paid consultant (although the pay goes to my comany not me). When I do the job it is almost always true that I tell managementn something that their organization already knew. If can find the people "who already knew of the issues, and who could have resolved them", then my job is to give voice to their recommendations and convince management that they are right.

    The difficulty is that there may be several people that think they know how to fix it, and some of them are Victor,

  • (cs)

    ... So what you're saying is that Bruce showed up at SAP, and that's why they just fired about ten thousand people?

  • tecxx (unregistered) in reply to kastein
    kastein:
    ... So what you're saying is that Bruce showed up at SAP, and that's why they just fired about ten thousand people?

    excellent post ;)

  • greg (unregistered) in reply to Chris
    Chris:
    I wonder if we might, perhaps be hearing a slightly partial view of the story. I've been in situations where bludgeoning management into providing the detailed workflows and specification was nigh on impossible and what specifications there were shifted each week. The tempation to create a "generic system builder was strong.

    I can imagine that getting a highly paid external consultant in might well have focussed management's thinking sufficiently to get them to cough up the specs, leaving Victors' work un-necessary.

    Ok, but that doesn't excuse Victor's spending so much time creating something that he could have done in a DAY just giving management access to existing tools vs. trying to write his own language.

  • (cs) in reply to WC
    WC:
    "They get paid bigger $$$ and get to 'save the day' when there were developers on the team, already working there, who already knew of the issues and who could have resolved them, just the same as the consultant; if they were just given the opportunity."

    You were. You said nothing when you saw the problems.

    Every software development company has both new development and bugfixes all the time. Your chance to be 'the hero' was to take one of those problems and just fix it. Believe me, if you do fix it in a reasonable amount of time, the amount of time you are behind on your other projects will be forgiven.

    That's not always true. I was fired from a team for doing precisely what you suggest doing. (I was re-hired by the company owner as the IT administrator with a raise.)

  • Rob (unregistered) in reply to WC
    WC:
    "They get paid bigger $$$ and get to 'save the day' when there were developers on the team, already working there, who already knew of the issues and who could have resolved them, just the same as the consultant; if they were just given the opportunity."

    You were. You said nothing when you saw the problems.

    Every software development company has both new development and bugfixes all the time. Your chance to be 'the hero' was to take one of those problems and just fix it. Believe me, if you do fix it in a reasonable amount of time, the amount of time you are behind on your other projects will be forgiven.

    On the other hand, if you fail, or take too long, it will go very badly on you.

    To excel, instead of just succeed, you have to take risks. Any businessman will tell you that.

    Without turning it into an argument; you are making an assumption without any reason to do so. You assumed I didn't say anything about the issues I saw. That's not the case.

    Heck, performance issues are painfully obvious for anyone to see. It's slow, it's a problem. An end-user with no technical understand can tell you if your app has performance issues.

    In my particular case, I knew performance sucked. In an attempt to be a 'good' employee; I put in some extra time, used a profiler and tried to diagnose what exactly what making our app start-up so slowly. I found a significant issue, fixed it, and reduced the startup time from about 30 seconds to about 4. Obviously, I started with the 'low-hanging' fruit; subsequent improvements wouldn't have had that same kind of pay off.

    Pleased with myself, and reasonably certain my change would have no ill-effects; I shot off an e-mail to my boss/manager with the proposed changes and the performance numbers I'd put together - saying that unless he saw a problem, I'd like to check it in.

    I went way beyond just saying there was a problem, I spent my own free-time putting in extra hours, diagnosing and fixing a problem.

    My fix was approved and checked-in; but I was told that we didn't want 'worry about performance just yet' and that my assigned task was a 'high priority' and that I should really focus on that.

    I was told not to bother addressing or looking at larger issues. And, really performance was the easy one...imagine if I'd suggested refactoring a significant section of the application because it would clean up the code base...and it'd only take 2-3 weeks of my time. I'd have been laughed out of whatever meeting room I was in at the time.

    So, as instructed, I worked on my 'high priority' thing; that changed, changed again, and was restarted from scratch, then changed some more. Then, later, management announced a new round of hiring; and the formation of a new centralized team that would handle issues like performance and address some of our architectural problems.

    I'm not against those things; I agree that they need to be done.

    The people they brought in to the them are good programmers and they've done (and are continuing to do) a good job of addressing the issues...but they certainly get the spotlight (and I'm sure, the paycheck to match).

    Maybe, if I were a project manager I could better appreciate the logic behind these sorts of choices. "X has already been working with Y - so we don't want to bring in a new guy to do Y and move X to Z when we could just hire someone to do Z!". I don't know.

    Oddly enough, before this I was a consultant.

    This might all just be part of the normal 'curve' and in another 5 or 10 years I'll be the new guy that companies want to bring in; but I'm still left feeling like, given the opportunity, I could have done the task. And given the choice, I'd have preferred making improvements to the overall application; that writing and then rewriting and then changing the same tiny subsection of the application I've been given to work with.

    I wouldn't say I'm 'biter' but I also wouldn't say I'm motivated. Seems kind of like a lose-lose...

    /end rant

  • EVO (unregistered) in reply to Eric
    Eric:
    DECLARE COMMENT AS TEXT DECLARE CAPTCHA AS TEXT INPUT COMMENT, CAPTCHA ON FORM IF ISCORRECT(CAPTCHA) THEN OUTPUT COMMENT ON FORM

    Close. But not quite. Here: DECLARE COMMENT AS TEXT DECLARE CAPTCHA AS TEXT INPUT COMMENT, CAPTCHA ON FORM IF CAPTCHA="saluto" THEN OUTPUT COMMENT ON FORM

    But still. Not funny.

  • Jim Leonard (unregistered)
    "Why not just use an off-the-shelf expert system?"

    "Oh, believe me," Victor responded defensively. "We looked and looked and looked. There's simply no off-the-shelf system that meets our needs."

    "Why did you decide on an expert system for this?"

    Victor smiled. "I'm a programmer. I don't need, nor do I want, to learn the business. The business users can just tell the system what to do."

    It looks as if Bruce is the the real expert system!

  • Andrew (unregistered)
    Victor smiled. "I'm a programmer. I don't need, nor do I want, to learn the business. The business users can just tell the system what to do."

    WTF? Is this seriously how devs think?

  • (cs) in reply to Andrew
    Andrew:
    Victor smiled. "I'm a programmer. I don't need, nor do I want, to learn the business. The business users can just tell the system what to do."

    WTF? Is this seriously how devs think?

    Devs yes, Analysts, no. Devs just write code, analysts figure out why the code needs to be written a certian way. Victor is a dev trying to be an analyst, he needs to learn to care about the business.
  • sumoman (unregistered) in reply to Rob

    Rob...when there were developers on the team...who could have resolved them, just the same as the consultant; if they were just given the opportunity.

    No, Rob you and others make very wrong points here. Everyday local guys have the opportunity to get their shit together by cleaning up messy code bases or bad practices. Eventually they would be on top again, but because of cowardice or laziness this just never happens. And then management is in urgent need of external consultancy to save the day.

    So don't make dumb rants if you fail personally.

  • (cs) in reply to sumoman
    sumoman:
    No, Rob you and others make very wrong points here. Everyday local guys have the opportunity to get their shit together by cleaning up messy code bases or bad practices. Eventually they would be on top again, but because of cowardice or laziness this just never happens. And then management is in urgent need of external consultancy to save the day.

    So don't make dumb rants if you fail personally.

    You're the idiot. As I just mentioned, I did just fix things on my own - and I got fired for it. I should mention that my fixes didn't use any time that should have been directed elsewhere. Often, management doesn't want the existing employees to do it.

  • Bingo (unregistered) in reply to biziclop
    biziclop:
    It's funny how all the stories nowadays seem to be about the pig-ignorant in-house developers confronting the intrepid and ingenious consultant.

    Whereas usually it's the other way around, most consultants don't know anything about anything, except acronyms and generic systems, so all they will suggest is you should stop developing a specific solution and try using Spring MVC and Axis.

    Even if the project isn't written in Java.

    I've even heard one talking about the 'Java.Net-space....'

  • (cs) in reply to Andy Goth
    Andy Goth:
    You know, this reminds me of C++. C is fine for what it is, but many people wanted (let's say) first-class strings. But rather than put strings in C++, Bjarne put in lots of fancy-yet-low-level structure and function definition scaffolding which could conceivably be used to create an almost-first-class string. But he didn't actually put in true string support. That task was left to the same people who clamored for strings in the first place. Eventually a string was standardized, but it took a long time, and it's still not first-class. "a" + "b" doesn't work, but std::string("a") + "b" does. FAIL.

    C++ doesn't have solutions; it has meta-solutions.

    Apparently the noble art of flame wars is dying.

    Way to go, being reminded of <insert hated language of choice here> by someone ham-fistedly implementing a library-free version of Visual Cobol. Unless Alex anonymised the target "language" and it was actually Visual C++ ... which would be pretty mind-blowing, and an even better WTF.

    In re your apparent issue with C++, I sympathise with your desire for (say) first-class strings, although I was hitherto unaware of a massive ground-swell of support within the C community for said feature. If you want (say) first-class strings, an elementary consideration of the problem might lead you to use (say) a language that offers first-class strings. Which kind of restricts you to Ruby or a Lisp variant in the programming ecosystem of 2009. Shame about Ruby in the 1980s, really.

    I suspect that significantly more C programmers had a desire for (say) better encapsulation, better inheritance mechanisms, some sort of type-safe macro system, and random bits of kitchen sink. This they got. Whether the result satisfies your particular woulda couldas or not is largely beside the point.

    Incidentally, the solution to the particular problem you pose is to type "ab" rather than "a" + "b". Simple, elegant, and saves key-strokes.

    Should the strings in question be C++ variable strings, you can of course type

    std::string a;
std::string b;
std::string c = a + b;
    I find that this suffices for most real-world purposes, although unfortunately the operation is not commutative, and it does rather rely on intuition on what the programmer means when he types "a" + "b".

    Why the simple string type should be elevated above its lowly peers is beyond me.

    Except in PHP, of course ...

  • Oly (unregistered) in reply to Satanicpuppy
    Satanicpuppy:
    biziclop:
    It's funny how all the stories nowadays seem to be about the pig-ignorant in-house developers confronting the intrepid and ingenious consultant.

    Whereas usually it's the other way around, most consultants don't know anything about anything, except acronyms and generic systems, so all they will suggest is you should stop developing a specific solution and try using Spring MVC and Axis.

    Even if the project isn't written in Java.

    I've seen (and been) both, and it goes both ways. Some consultants do suck, but they often have nice specialized skills that can be very effectively applied in a limited situation: most full timers have to do many different things, and while they may know more about their systems, that doesn't make them overall experts in specific technologies. If you need some specific thing built, it's usually better and quicker to go to an expert in that sort of system.

    On the other hand, consultants are specialty tools, and if you get a generic consultant, he's just going to milk you for money while not accomplishing anything measurable.

    There was a TV show in Australia before the 2000 Olympics which mocked how the games were run and the planning (or lack thereof) that would go into it (with John Clarke, Brian Dawe, Gina Riley)... John Clarke at one stage questions a consultant... "So what do you do?" "I'm a fully qualified consultant." "But what do you consult on?" "Today? Today you have hired me as a traffic consultant." "But what qualifies you to talk about the traffic issues?" "Oh, I'm a fully qualified consultant." "What are you qualified in?" "Consulting" .... etc...

  • Robert S. Robbins (unregistered)

    Just teach management how to use Visual Studio and they can develop whatever program they need to solve their business problems.

  • (cs) in reply to Paula
    Paula:
    DECLARE PAULA AS BEAN PRINT BRILANT
    Didn't FTFY, since I assume the typo was intentional.

    Gotta be careful about spelling things like "brillant" correctly though, otherwise the memes round here will get bean-rot...

  • Toodle (unregistered) in reply to jrrs
    jrrs:
    This reminds me of a time and expense accounting system written by an individual entirely in APL(!) at our workplace sometime in the early '80s. Apart from the special keyboards required by the clerks, he (and his program) was canned when the director found out it was costing $20k each month for the usual accounting summaries. These days we have SAP. :-)

    So now you're spending $200k each month for the usual accounting summaries??

  • sumoman (unregistered) in reply to Heron

    You're the idiot. As I just mentioned, I did just fix things on my own - and I got fired for it. I should mention that my fixes didn't use any time that should have been directed elsewhere. Often, management doesn't want the existing employees to do it.

    [ ] I got fired for improving things!!! I performed the wrong strategy, maybe?

  • Vlad (unregistered) in reply to Rob
    Rob:
    WC:
    "They get paid bigger $$$ and get to 'save the day' when there were developers on the team, already working there, who already knew of the issues and who could have resolved them, just the same as the consultant; if they were just given the opportunity."

    You were. You said nothing when you saw the problems.

    Every software development company has both new development and bugfixes all the time. Your chance to be 'the hero' was to take one of those problems and just fix it. Believe me, if you do fix it in a reasonable amount of time, the amount of time you are behind on your other projects will be forgiven.

    On the other hand, if you fail, or take too long, it will go very badly on you.

    To excel, instead of just succeed, you have to take risks. Any businessman will tell you that.

    Without turning it into an argument; you are making an assumption without any reason to do so. You assumed I didn't say anything about the issues I saw. That's not the case. <snip> (not that I don't agree, but it was long to include)

    I had a very similar experience. I was working in a support role on a project, and was asked to prepare a design and plan for implementing some major changes for the next release. A Development team was brought in to actually do these changes, and complained first that the information in the provided documentation was inadequate (I think the biggest part of the problem is they came in for a fixed 3 month contract, and didn't have time to actually learn anything about the application they were to develop). The project 'regulars' (my TL, PM) initially saw one of the lead consultants as a trouble maker, and I was instructed to 'answer any question, but don't do his work for him'.

    Before long, I had a meeting with my TL, who reiterated - 'We can afford about 2hrs of your time to help him - but you are not to touch his machine'. Some days later, I had a meeting with my TL, and the Consultants Manager - this time I was instructed that they could afford to use 6-8 of my hours, and that I could sit over his shoulder and tell him EXACTLY what to type (so of course, I said 'When I get the time' - if they were gonna screw me, I was gonna offer some resistance at least). Not too long had passed, and I had a meeting with My TL, the Consultants Manager and the Consultant - the company could afford to give 12 hours of my time, and provided the problem was fixed they didn't care how it happened.

    Suffice to say, the problem was fixed (and naturally, the Consultant took credit for it), however I pointed out to my PM that he could have saved by paying me my wage and some share of what he paid the consultant and allowing me to make the change (given that I had anyway). He dismissed it with 'But the client is paying for a certain number of people' (ie their contract was about bums on seats, not about output).

    Admittedly there is more work than people where I live, and it's not the first (or last) time that I've noticed a vast number of under-qualified and/or incompetent people get jobs - occasionally above me, However the real issue I had, was that my TL didn't have the balls to stand up to the manager of the consultant - who in turn diodn't have the balls to stand up to his consultant (granted neither did I, but resource allocation is not really any of my business - I do what my manager wants, and when I have issue with what's going on, I mention it to him away from meetings involving other people - which I did several times, and he just grinned stupidly).

    Because of this (among other things) I left the company not long after, and think this is why the majority of people move on fairly quickly in IT - it has less to do with getting bored, than getting screwed. If the company doesn't look after you, be prepared to move on...

  • (cs) in reply to KattMan
    KattMan:
    Andrew:
    Victor smiled. "I'm a programmer. I don't need, nor do I want, to learn the business. The business users can just tell the system what to do."

    WTF? Is this seriously how devs think?

    Devs yes, Analysts, no. Devs just write code, analysts figure out why the code needs to be written a certian way. Victor is a dev trying to be an analyst, he needs to learn to care about the business.
    No, I think you just missed a spelling mistake.

    Q Is this how divs think? A Yes, it is.

    I'm usually at a loss to figure out what analysts do, other than Power Point and munching meetings. In theory they should be there to translate business requirements into development requirements. In practice, 99% of them are too busy Pointing and Munching.

    It's all categories though, innit? What you actually want in these cases is an intelligent person rather than a fruit-cake. Those (apparently) rare developers who are not fruit-cakes are generally quite capable of translating business requirements into development requirements. I'm sure that those (most certainly) rare analysts who are not walking, pointing, munching, gibbering, slavering, ass-kissing, certifiable brain-death-on-a-stick are equally capable thereof.

Leave a comment on “The Expert System”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article