• (cs) in reply to Konrad

    Captcha drove me mad this morning, and kept saying it didn't recognise my codes even though they were obviously correct.  Finally I joined and posted, after wasting 20 frustrating minutes.

  • (cs) in reply to lrb
    lrb:

    If the IT manager is working for me, I want him spending time working on projects that are most valuable to the company.  There should be a process to decide which projects are most important to the company.  Steve's job would be eliminated as well as any managers who went outside the process.  If the existing processes are wrong they need to be changed and fixed.  And ROI justification needs to be shown for any IT projects.  Most Steve projects don't produce enough ROI to justify pulling resources off projects that have a much higher ROI. 

    Somebody sounds bitter.

    But the above reasons is exactly why the Steves exist. The bossman wants something, that he feels is vital to his job. The "ROI Justification Process" has deemed it not so vital (for whatever reason). Bossman makes a decision he needs this doodad, so he gets Heroman Steve to write it for him. Steveo throws together awesome utility, Bossman becomes a happier more product worker. Other bossman see Bossman become a better worker, so they want in on it too. And so on.

     

  • UTU (unregistered) in reply to Bus Raker
    Bus Raker:
    I'll admit it, I was a Steve 8 years ago.


    It's true that sometimes we really need Steves to get something done in time. It must be noted that what Steve does might not be a good solution, much less a scalable solution, but it is usually a solution to an existing problem.

    I remember in the 90's, I was in a (bit too) tight schedule with a software I had adopted from earlier developer. It was still on testing phase, and though some parts worked great, there was no way it was going to get finished in time for testing (and thus, deployment).

    The only solution I saw was to take an extended weekend (friday & monday included) and make the system in a way that it works for the parts needed. The result looked horrible, but - it worked. Nearly every table in the database as well as most of the logic inside the application had been changed in the four day period I worked with it. Of course, the company was not happy that I did this without asking, but the version I did in those four days actually became the first major release of the software. Not much of the logic or database was changed when we eventually made version 2 of the software; it was basically a facelift for the user interface.

    Only problem with the version I created was that it didn't scale too well. Once the concurrent usercount went way above 1000, everything in the database went into complete standstill. This went on for a couple of years until I finally came forward and told there was nothing more we could do with the current code. It had had too many new features added, and it had generally swayed a lot from what it was originally designed for. At that time we started designing the database again from grounds up. We still haven't finished with this third major version of the software, but this time it has been done "right". Of course, the development cycle has been a lot longer than the original deployed version had, but I think it's been worth it; at least, if nothing else, this "Steve" has learned that if "doing it right" requires you to fail a deadline, it's usually better than cooking up something to "do the job" - very often such solutions, in the end, cause more trouble than they're worth.
  • lrb (unregistered) in reply to chrismcb
    chrismcb:
    lrb:

    If the IT manager is working for me, I want him spending time working on projects that are most valuable to the company.  There should be a process to decide which projects are most important to the company.  Steve's job would be eliminated as well as any managers who went outside the process.  If the existing processes are wrong they need to be changed and fixed.  And ROI justification needs to be shown for any IT projects.  Most Steve projects don't produce enough ROI to justify pulling resources off projects that have a much higher ROI. 

    Somebody sounds bitter.

    But the above reasons is exactly why the Steves exist. The bossman wants something, that he feels is vital to his job. The "ROI Justification Process" has deemed it not so vital (for whatever reason). Bossman makes a decision he needs this doodad, so he gets Heroman Steve to write it for him. Steveo throws together awesome utility, Bossman becomes a happier more product worker. Other bossman see Bossman become a better worker, so they want in on it too. And so on.

     

     

    No, I'm not bitter.  More like frustrated because I'm seen so much money wasted by taking Steve-like shortcuts.  Probably the biggest danger is that to Bossman it appears to be working.  Meanwhile, because it didn't enlist all the affected stakeholders and/or didn't do more than a token QA process, it's causing massive problems (much bigger than the ones being fixed) elsewhere in the company and/or only appears to be working when it really isn't. 

    I do understand the problems people faced when they can't get IT to do something that they feel is needed.  However doing  an end around only makes the situation worse, not better.  It helps mask the problem from the decision makers who need to appropriate more resources to IT and demand higher accountability of their use.  Without proper procedures and processes it's vitually impossible to have any meaningful level of accountability as to how IT resources are used. 

  • Steve. Number 1. Thou shalt have no steves before me (unregistered)
    Alex Papadimoulis:

    Nathan O's colleague ("Steve") works as a "rogue" IT operative. No one knows what department he works for, who is supervisor is, or even what his real name is. Steve's job is, apparently, to analyze, develop, deploy, and support "unofficial" IT projects without ever telling, let alone getting any support from, the IT department. No IT support means that Steve's job is a dirty one: he can only use non-development tools (such as Microsoft Excel), rely on rogue servers (such as a random user's workstation), and non-database databases (such as CSV files).

    But what Steve lacks in tools, he makes up in job satisfaction. Since no one seems to know his job title, many people from the "business side" just refer to him as "The Hero." Unlike the mean-old folks in IT, Steve works in a developmestruction environment[1] and doesn't bother with things like testing, code review, deployments, etc. -- he just does what it takes. The "business people" also empathize with Steve and his constant battles with IT who's sole purpose sometimes seems to be shutting down Steve and his rogue operations. In fact, just recently, the mean-old database folks shut down one of his latest creations called "Dashboard.xls"

    Dashboard.xls was a spreadsheet that boasts more lines of code than most "real" applications. It was developed for a single manager, who used it to view trends in over 500 critical datapoints (each one appearing in a cell) and with most varying by parameters (entered in different cells). Better still, the spreadsheet simultaneously and asynchronously refreshes the datapoints from live production data on a regular interval. The spreadsheet did this by opening a database connection for each of the 500 datapoints. Though it may seem like a lot of connections, a well-built SQL Server can easily handle the load.

    The problem came when the manager, who absolutely loved Steve's appli-spreadsheet, shared it with some of his peers. As it turned out, his peers liked it as well, and they decided to share it with their peers. When the database finally stopped working after ten or so thousand simultaneous connections, the DBAs frantically asked Nathan, responsible for maintaining application apparently making the connections, to help fix it. By the time Nathan tracked the connections down the spreadsheet, Steve was long gone, off working on some other rogue operation.

     

    [1] See The Developmestuction Environment (http://thedailywtf.com/forums/64401/ShowPost.aspx)

     

    Update: Fixed Typo (rouge --> rogue)




    This is a management WTF.   Steve's the go-to-guy to get things done.   Somebody needs a gun, Steve makes a gun.   If his boss sells the gun, and many copies to his buddies, is that Steve's fault?   

    Sheesh.  I solve problem A.   If I did such a good job of it that it gets handed off to a gazillion other people, and the handing off causes a problem, it's not my problem.

    Get a grip!








  • Angry Developer (unregistered) in reply to Junior IT Professional
    Junior IT Professional:

    It's unfortunate but a truth that guys like Steve are considered the real heroes of technology.  Joe average user hasn't a clue about the technical details of what is going on behind the scenes and could care less if it is a kludge.  All he cares about is that the GUI is shiny and it does what he wants with minimal learning curve.

    In fact, I am betting someone asked IT for something similar to this Dashboard.xls and they were refused.  Thus, Joe user had to go to Steve.  IT departments need to stop being so innundated with policy and paperwork and get back to creativity and output.  In my limited experience the big company IT is looked upon as the enemy that must be constantly fought with to get products you need, rather than a helpful customer service oriented development team.

    Joe user hates dealing with IT because they always tell him no or they speak in alien languages he cannot understand.  I do not wonder too long why the IT department is in the back of the building, well out of view from any customer tours.



    <RANT>


    ARGHHH!!!! This is because the IT section has had its budget cut so much that ALL WORK MUST BE CROSS CHARGED. If anyone in IT did anything like Steve's little project that would be hauled in for an arse kicking by their manager and bean counter.

    Unlike Steve, the IT people must account for every minute of their day. We cant waste weeks and weeks tweaking and playing and learning and yakking. We have to include the total time spent taking a dump during the project period for fucks sake.

    So while the qualified IT people that should be doing this have to provide quotes, get approval and then not go over that quote. Steve can do as he pleases. Who cares that his job in middle management accounting isn't being done? He's got spare time, a dummies book and knack for brillance!

    Every large organisation has an endless supply of Steve's wrecking havoc throughout the business. Only the heroic work of the IT guys that madly clean up the mess when the Steve's move on keep those  piece of shit, embarrassingly unprofessional and downright incompetent business systems running.

    To add insult to injury, the only thing people walk away thinking when IT saves their arse again is 'This never happened when Steve was around'. ARRRRGHHHHH!!!

    Don't bag out the IT section because some big wigs in accounting had a brain fart that has resulted in the false truth that Steve is better value than a skilled developer. Don't spend years winding the IT department in red tape just to complain things rant done quick enough. Most of all, Don't yell at the IT people when they point out that due to five years of non enforced relationships, untyped data fields and uncontrolled adhoc table level access that your data is in fact, absolute useless.

    *pant* *pant*

     OK, I'm off for a little lie down now. Sorry about that everybody, its been a tough month...

    </RANT>

  • awefawfawfe (unregistered) in reply to Opinion Dalek
    Opinion Dalek:

    As someone who develops Excel applications for large firms, my experience is (of course) form the other side.  The worst WFT I encountered is for huge firm where the IT department quoted (for one project I did) 1 Project Manager and 2 Programmers from one of the top 4 Accounting firms to deliver a project.  2 years ago.  They are still working on it.  In the meantime, my (fully tested every time) spreadsheet is now up to version 11.  Every time I do a new version they tell me they aren't going to need me for the next one.

    IT doesn't need to be about better communication, it needs to be about results.  And supporting their users.  Not telling them what they can't do, but how they can.

    LOL.  An "Excel application".  That's like saying "Non-dangerous nuclear explosion".
     
    Did you ever think that maybe the reason the "WTF" project has taken two years is because their deliverable is something other than an a rinky-dinky Excel spreadsheet?
  • Dermot (unregistered)

    I've been Steve for many years in my previous organisation, and I think he could well be a hero, because he gave a busy manager a valuable management tool. Why didn't IT take charge of scaling it up for use by other managers?

     I know the frustration of having an IT department with no development capability, and which seems (from the user perspective) to focus only on keeping the machines running, and not care how much users struggle. I have seen users do crazy things which would amuse some of you reading this, but in their situation, with total lack of support, what would you have done?

    Over the past 15 years, I've also seen many in-house applications produced by the IT department, and they included some of the biggest WTFs I've seen, including blank toolbar buttons, buttons that were offscreen on some monitors, document review tools that allowed easy forging, and so on. And most of all, those in house apps took forever to develop, and their UIs were always atrocious. Don't talk to me about rogue users!

    The various tools I wrote all worked - and I'm sure the code sucked - but they contained all the business rules and interfaces needed to turn them from prototypes into the real thing. That is the key, I think. The power user should be an ally of the IT department, in marrying the business needs and technical capability. The problems happen when the users and IT live in different worlds, "us" and "them". When either of them develops stuff in isolation, you have problems and WTFs.

  • Dermot (unregistered) in reply to awefawfawfe

    Do you really know enough about Excel to say that? I've been working for 30 years in financial consultingwith large firms, and Excel is the most essential and powerful tool I've ever seen.

    You know why? Because it  is a RAD tool, highly extensible with VBA, and just about all users know the UI. Sure, it is dangerous if badly built, but the same goes for any tool. I'll bet it is 10x easier to check an Excel app than a C++ app.

  • Welcome to the machine (unregistered) in reply to Dermot

    OH MY WORD - This is just like my current employers, a financial firm. Except they have whole departments doing it. I once got a phone call from a guy asking if I knew about macros in MS Access, he said he'd tried the guys in accounts who know about it and they were too busy and then he asked around the investments department (also experts in Excel) and someone suggested that perhaps someone in the IT department might know about programming.

    On another occasion one of our Actuaries was genuinely shocked to learn that there were people in IT who knew about programming. They have scores of applications written in VB [please don't start a 'VB sucks' thread] mostly without 'Option Explicit' set and usually with all the code in 1 function..

    Some years back, IT management disbanded the team that monitored these spreadsheets and databases and introduced some good practise (and suggested when a proper IT-built solution was appropriate) - apparently they weren't really needed, now it's 10 times worse.

    Oh yeah, the guy who phoned about MS Access? He wanted to write a function to automatically e-mail the IT department to complain when his support calls ran over their service standard, he kept all the support calls in a database of his own - because obviously the IT department wouldn't have one of them...

  • Axel Eble (unregistered) in reply to ogilmor

    <font size="2"><font size="4"><font size="3">I believe ammoQ's reply is right on target. IT is there to deliver what the Business needs. If IT doesn't manage that (or business is too demanding) there have to be some processes to take control of it. That's what IT Service Management is for (and while it's a buzzword it still is true - take a look at ITIL which is created by IT people for IT people).
    And, ogilmor, I don't agree that it's "tricky" to measure the helpfulness of IT. IT has to work closely with the business to agree on and define the KPIs that satisfy the business. Yes, it's basically an SLA or OLA - but that's what it takes.
    One should say good-bye to the notion that IT is a profit center in most companies. More often it's a cost-center and a business-enabler.
    </font></font></font>

  • Benjamin Smith (unregistered) in reply to Welcome to the machine

           

    Anonymous:
    OH MY WORD - This is just like my current employers, a financial firm. Except they have whole departments doing it. I once got a phone call from a guy asking if I knew about macros in MS Access, he said he'd tried the guys in accounts who know about it and they were too busy and then he asked around the investments department (also experts in Excel) and someone suggested that perhaps someone in the IT department might know about programming.

    On another occasion one of our Actuaries was genuinely shocked to learn that there were people in IT who knew about programming. They have scores of applications written in VB [please don't start a 'VB sucks' thread] mostly without 'Option Explicit' set and usually with all the code in 1 function..

    Some years back, IT management disbanded the team that monitored these spreadsheets and databases and introduced some good practise (and suggested when a proper IT-built solution was appropriate) - apparently they weren't really needed, now it's 10 times worse.

    Oh yeah, the guy who phoned about MS Access? He wanted to write a function to automatically e-mail the IT department to complain when his support calls ran over their service standard, he kept all the support calls in a database of his own - because obviously the IT department wouldn't have one of them...


    You are screwed. Quit now while you have the chance. Then, find someplace that has a ghost of a chance of not farking you up the rear.

    Seriously.

    Your job is  to be the guy that takes the hit when it doesn't work....

  • Cratig (unregistered) in reply to Ford351-4V
    Ford351-4V:
    <font face="Arial">Actually, many non-technical people firmly believe that all programs are coded in Excell.</font>


    Not too true.

    My wife had to do some basic Pascal stuff at school and she believes that programs are all written in the same language, I showed her a couple of different programming languages and she was soon put right!!

    I don't know why my wife was being taught Pascal at school because she can't even understand the microwave!!!
  • Reality (unregistered) in reply to ammoQ
    ammoQ:
    IMO the emergence of Steve-like guys and MS-Office-Hack apps is more likely in organisations where the IT department is not considered helpful;  where every change request, no matter how simple or small, takes 8 weeks to complete and costs the requesting department a minimum of, say, 5 hours internal charging.


    I don't think this is too far off.  Perhaps they're spending more time on thedailywtf.com overanalyzing then they should be.  All too often I've seen IT dept's have a 'smarter-than-you' attitude such as the posters. Frankly he sounds jealous of his covert-ops ;). This guy made his app quickly for one person and any boss would/should be happy for that. Obviously he was because he passed it on to everyone on his mailing list. If he put a tad more thought into the implementation, he would have hit a definite home-run
  • Oliver Townshend (unregistered) in reply to awefawfawfe

    The reason that the WTF project has taken 2 years (so far) is because its totally over-engineered.  My spreadsheet might be under-engineered, but it's delivered value. 

    One day I'll see their new project and be out of a contract, but I'm not holding my breath.

  • (cs) in reply to Steve. Number 1. Thou shalt have no steves before me
    Anonymous:
    This is a management WTF.   Steve's the go-to-guy to get things done.   Somebody needs a gun, Steve makes a gun.   If his boss sells the gun, and many copies to his buddies, is that Steve's fault?


    Ah, the old Gun Analogy again.

    Let me just put a stop to that once and for all:

    The fallacies:
    1. A program is not a gun.
    2. Nobody asked for a gun.

    Take good notice of number 2.
    2. Nobody asked for a gun.


    The breakdown:
    - It is an intrinsic, defining property of a gun to be dangerous. Without the danger, a gun is a hunk of smooth metal.
    - A program can be dangerous only if the progams final intent is to be dangerous. To others.
    - If a program's intent is harmless data overview, and yet is still dangerous, to the user, then it's the programmer's fault, every fucking single time.

    Rogue Steve's the fuckup. Management's only flaw in this case is to be ignorant.

    If I did such a good job of it that it gets handed off to a gazillion other people, and the handing off causes a problem, it's not my problem.


    Except the program blew up in the user's faces, and it is most definitely your responsibility to step up and fix what you fucked up.
    You're right in that it's technically not your problem if nobody comes to you and asks for a fix, but if you find out that your program has caused things to blow up unintentionally, then you should feel a little pang of guilt and how you screwed up. Because you did.

    UGH.
  • Robert Synnott (unregistered) in reply to stevekj
    stevekj:


    Is anyone else reminded of Harry Tuttle, the rogue heating engineer from "Brazil"?

    And as a side note, I object to the use of the name "Steve" as synonymous with "ungovernable rogue IT operative"!

    Steve

    Of course, though, he was competent.

  • (cs) in reply to Opinion Dalek
    Opinion Dalek:
    IT doesn't need to be about better communication, it needs to be about results.  And supporting their users.  Not telling them what they can't do, but how they can.


    Actually, sometimes it very much needs to be about telling the users what they can't do, and sticking to it, when your expertise tells you that doing it would result in major problems for little benefit.
  • (cs) in reply to lpope187
    lpope187:
    Seriously, can anyone say cowboy coder?  Unfortunately, some of the largest organizations are driven by Excel.


    I've read somewhere (in a comment on OSNews I believe) someone calling excel the "swiss army chainsaw" of the IT industry. Found it hilarious.
  • fgilcher (unregistered) in reply to brazzy
    brazzy:
    Opinion Dalek:
    IT doesn't need to be about better communication, it needs to be about results.  And supporting their users.  Not telling them what they can't do, but how they can.


    Actually, sometimes it very much needs to be about telling the users what they can't do, and sticking to it, when your expertise tells you that doing it would result in major problems for little benefit.


    Quite often the problem of IT is the blank statement "we can't do this", sometimes amended with the technical reason y (pick one of "security", "scalability", "you just don't do this") instead of explaining to the user in clear human-understandable words the reasons for not being able to do the thing asked for and then offering an acceptable way of achieving the same or similar results. I pretty much had to learn that lesson from both sides - once with our "it department" which gave me a good lesson how our customers must feel if I throw around buzzwords an technical reasons why solution "x" is not a viable solution.
    The customer is not at all interested in "how are you going to do this" but merely in solving a given problem, thats excactly what steveee did.

    sidenote: kinda interesting, typing gets slower the longer the text is.
  • (cs) in reply to dhromed
    dhromed:

    The breakdown:
    - It is an intrinsic, defining property of a gun to be dangerous. Without the danger, a gun is a hunk of smooth metal.
    - A program can be dangerous only if the progams final intent is to be dangerous. To others.
    - If a program's intent is harmless data overview, and yet is still dangerous, to the user, then it's the programmer's fault, every fucking single time.

    Rogue Steve's the fuckup. Management's only flaw in this case is to be ignorant.

    If I did such a good job of it that it gets handed off to a gazillion other people, and the handing off causes a problem, it's not my problem.


    Except the program blew up in the user's faces, and it is most definitely your responsibility to step up and fix what you fucked up.
    You're right in that it's technically not your problem if nobody comes to you and asks for a fix, but if you find out that your program has caused things to blow up unintentionally, then you should feel a little pang of guilt and how you screwed up. Because you did.

    UGH.

    Steve's original solution worked to spec - working for ONE user. It was that user who caused the WTF by turning an app causing no problems into one causing problems through overuse. Steve's design wasn't efficient, but for one person, as requested, it did the job and caused no problems. Cause of WTF? Business guys bypassing IT and possibly an inefficient IT dept, and business issues behind that.


    You don't blame Pepsi for killing someone who died because they drank 200 gallons of pepsi in 5 minuntes.


    Also it wasn't Steve's responsibility to fix it - as per the original post, STEVE HAD LEFT. The business guys in question  They CHOSE to have their 'development' done by a sole entity knowing there'd be zero support if/when he left. Their perogative. Steve just did what was asked. Cause of WTF? Business guys.


    'Steve' is probably the one I'd blame least in this situation. It sounds like the 'business guys' have no respect for the IT dept, and decide that they can do what they want. More than likely the IT dept. is either crippled by being rubbish or arrogant, or else have their hands tied by the business as a whole through red tape or retarded controls.


    Had 'Steve' ever said "no I won't do that" once the word got out, how long do you think it would have been before he said no to the wrong person and got the boot because of it? From his point of view, it was learning too, and probably interesting, and he was being paid to do it. It's the 'business guys' that did things wrong, going to the untrained unsupported, unprofessional guy.


    In my previous position I was both 'Steve' and 'the IT dept' at the same time (the IT dept for the company, a 'Steve' in the entire organisation). Being an unsexy part of the larger oganisation, we got little to no funding, support, or well, anything. Combine that with weak leadership so things couldn't change,  Steve-style skunkworks were the order of the day, and the only way to keep things running.  Locally however, there were enough know-enough-to-be-dangerous-idiots causing problems because they didn't want to down the 'proper' official-unofficial route.


    That's one situation I'm glad to be out of!

    (Post edited... just because I can now. :-P )

  • financial engineer (unregistered) in reply to RayS

    Just something to think about for everyone who is slating Excel as a development tool or environment.  Every investment bank in the world runs multiple mission critical trading applications in Excel.  Just to clarify, that's in New York, London, Tokyo, Amsterdam, Zurich and Paris at the very least (where I wrote at least a few).  Including, but not limited to JPMorgan, ABN Amro, Credit Suisse, UBS, Deutsche Bank, Bank of America to name but a few.

    Pretty much every bond price in the world that is quoted on Bloomberg or Reuters came from an Excel spreadsheet publishing data to the wire services.  Pretty much every derivative instrument is priced in an Excel based model.  Sure, excel may hook into a C++ dll or a remote compute grid, but the front end is Excel.

    The thing is that Excel is not amazing, it's buggy and slow.  It's also better than (I guess) 95% of all the code that anyone reading this is capable of writing.  It's just works and it does things that the designers had never thought of. 

    A bad developer writing code in Pascal, Lisp, Fortran, MASM, C++, Java or Perl is a bad developer.  It's really not about the tools, it's about the mentality, approach and intellect of the developer.  A lot of bad development is done in Excel, but that's because it's very accessible - you don't need a seperate compiler, linker, IDE and so on, it's all there - just click Alt+F11

  • peachy kean (unregistered) in reply to Free
    Free:

     This forum software doesn't seem to be getting better. Oh and update, passwod cookie gone too (normal except I've wriiten already).


    Damn right. It mangles your sig every time.
  • (cs) in reply to fgilcher
    Anonymous:
    The customer is not at all interested in "how are you going to do this" but merely in solving a given problem, thats excactly what steveee did.


    A major source of problems in application development is that most of the time, customers don't distinguish between the problem they need solved and the solution, the "how" they have already in mind (because that's how they saw something similar done somewhere else, or because they just thought it up and think it's a neat idea). Many times, this suggested solution is less efficient than what the IT people would have done if just presented with the problem, sometimes self-contradicting or otherwise fatally flawed.

    Ideally, in such a case the IT department should tell the user "Doing this is inefficient/insecure/impossible. But what is the actualy problem you need solved? Let's sit down together and find a better solution." And the user should agree to that.

    In the worst case, the IT department says "That's stupid, we won't do it. Go away and let us continue doing things beyond your mortal ken." and the user replies "How dare you puny technical peons imply there's anything wrong with what I have suggested in my MBA wisdom?!? Do it toot sweet or I'll have you fired!!!!" Invariably, the user wins and the IT department both has to implement the flawed solution and deal with the consequences - making them even more adverse to future requests.

    IT management and development processes are designed to ensure this doesn't happen, but  since they are most important for huge development projects, they tend to be implement first with those and then expanded to include everything, even if they are badly suited to handing small-scare requests.

  • (cs) in reply to RayS
    RayS:
    You don't blame Pepsi for killing someone who died because they drank 200 gallons of pepsi in 5 minuntes.


    A coke doesn't have a time bomb built-in.
    I've been guilty of many analogies in forum-arguments in the past and I've come to the conclusion that they're best avoided. Anyone can puncture a hole in an analogy, because analogies by definition are not 100% airtight -- otherwise they're not analogies, but re-iterations of the subject at hand. :)

    RayS:
    Also it wasn't Steve's responsibility to fix it - as per the original post, STEVE HAD LEFT.


    His app.
    His responsibility.
    But Steve left.
    Lucky for him.

    RayS:
    Steve's original solution worked to spec - working for ONE user. It was that user who caused the WTF by turning an app causing no problems into one causing problems through overuse. Steve's design wasn't efficient, but for one person, as requested, it did the job and caused no problems. The business guys in question CHOSE to have their 'development' done by a sole entity knowing there'd be zero support if/when he left. Their perogative. Steve just did what was asked. Cause of WTF? Business guys.


    It's true that one can design an app with a certain predicted load in mind. There is no WTF there. The business guys were only using their handy app, filled with glee that they could have their information. No WTF there.

    Steve's WTF is for making a design that was not merely "inefficient" or "designed for a certain load", but was grossly inefficient and a time bomb. Had Steve still worked there, it would have been his responsibility to fix it. At the very least, it was Steve's responsibility to explain to the user that his app was not intended for mass use. But apparently, he didn't.

    But naturally: two parties present, two parties at fault. The business guys should have had a bigger interest in how to properly use software and speak with IT depts.
  • Ron Ruble (unregistered) in reply to ammoQ

    > ...where the IT department is not considered helpful;  where every change request, no matter how
    > simple or small, takes 8 weeks to complete and costs the requesting department a minimum of,
    > say, 5 hours internal charging.

    Actually, that's not as bad as some. I've been in organizations where the 8 weeks is the minimum time required merely to acknowlege the receipt of the request!

    On one project, IT was proud of the high-end enterprise CM system they had. Of course, getting new developers an account on the system required an average of 6 -months-; mandatory training classes, offered twice a year. So I set up a (rogue, unapproved) CVS installation for my stuff.

    On the other hand, a similarly sized organization in the same industry had a helpful IT department. Requests were acknowledged promptly, and if any manager requested something potentially hazardous, it was quickly brought up at the correct management levels to deal with the problem.

    Documentation on existing apps, assistance for PC developers who needed help retrieving mainframe data, etc. were all handled promptly and efficiently.

  • Ron Ruble (unregistered) in reply to ammoQ

    > ...in many cases the IT department behaves like this because of the whole company culture.
    > If every little problem or failure (no matter how insignificant the affected system) causes
    > emergency sessions of the upper management, IT will focus on delivering uninterupted services
    > and tripple-checked updates - even if this causes long delays for every little update.

    Regrettably true. One of the worst problems in business today is the idea that anytime something goes wrong (even something very small), it's someone's fault.

    If it isn't OK to make mistakes, it usually doesn't prevent mistakes happening. It usually only stops  people from learning from them and preventing repetition.

  • J (unregistered)

    <rant>

    People like Steve exist because:

    1.  Business need results from technology investment.  (Newsflash: businesses don't invest in IT, because computers are *cool*)

    2.  Typical IT shops are slow and beauracratic, and all of the "developers" are busy whacking off with some new-and-shiny-gee-whiz-bang technology, which means they don't have much time to actually produce anything valuable to the business.

    True... Steve's solution was inelegant, but the bottom line is it provided value to the business.  IT probably acted in predictable fashion.  They killed the useful software and asked the manager to submit an request ticket which will be completed Q2 2009.

    </rant>

  • (cs) in reply to Ron Ruble
    Anonymous:


    Regrettably true. One of the worst problems in business today is the idea that anytime something goes wrong (even something very small), it's someone's fault.

    If it isn't OK to make mistakes, it usually doesn't prevent mistakes happening. It usually only stops  people from learning from them and preventing repetition.



    The bigger problem is that such organisations do not learn to live with problems. They want to avoid problems at all costs instead of developing some kind of fault tolerance.
  • (cs) in reply to ammoQ
    ammoQ:


    The bigger problem is that such organisations do not learn to live with problems. They want to avoid problems at all costs instead of developing some kind of fault tolerance.


    Part of my company's mission statement is "Get it Right the First Time." I translate this to "Failure will not be Tolerated."
  • lrb (unregistered) in reply to ammoQ

    ammoQ:
    Anonymous:


    Regrettably true. One of the worst problems in business today is the idea that anytime something goes wrong (even something very small), it's someone's fault.

    If it isn't OK to make mistakes, it usually doesn't prevent mistakes happening. It usually only stops  people from learning from them and preventing repetition.



    The bigger problem is that such organisations do not learn to live with problems. They want to avoid problems at all costs instead of developing some kind of fault tolerance.

     

    Sadly many corporate cultures are more concerned with finding someone to blame than about fixing the problem and making sure that it doesn't happen again.  If a type of mistake happens once there should be some tolerance for mistakes.  However if the same mistake keep recurring, then someone is to blame for not putting a process in place to mitigate the mistake or not following a process put in place or management has decided they don't want to expend the effort to fix the problem.  Mostly it seems that recurring problems are because management doesn't want to expend the effort to fix them, but management still wants to blame someone.  Often the person blamed did not have the ability to avoid the mistake. 

  • (cs) in reply to lrb
    Anonymous:

    Sadly many corporate cultures are more concerned with finding someone to blame than about fixing the problem and making sure that it doesn't happen again.  If a type of mistake happens once there should be some tolerance for mistakes.  However if the same mistake keep recurring, then someone is to blame for not putting a process in place to mitigate the mistake or not following a process put in place or management has decided they don't want to expend the effort to fix the problem.  Mostly it seems that recurring problems are because management doesn't want to expend the effort to fix them, but management still wants to blame someone.  Often the person blamed did not have the ability to avoid the mistake. 



    Of course a bug should be fixed once it is detected and pinpointed. Nobody should simply accept that a certain bug exists. But the organisation as a whole should be able to cope with more bugs to come, sooner or later. Without fault tolerance, the organisation is doomed into paralysis.
  • lrb (unregistered) in reply to ammoQ

    ammoQ:


    Of course a bug should be fixed once it is detected and pinpointed. Nobody should simply accept that a certain bug exists. But the organisation as a whole should be able to cope with more bugs to come, sooner or later. Without fault tolerance, the organisation is doomed into paralysis.

    I do agree with you about fault tolerance is needed.  I guess where I'm coming from is I've seen management demand 5 9's uptime (99.999%), but have 2 or more releases per week with less than 1 day QA quite often and no time allotted in projects for design among other problems.  Now it major releases are 1 per year and QA gets a minimum of 6 months start to finish on testing after feature freeze and other aspects are develop are similarly rigiours, then 5 9's is a more reasonable expectation.  However management often demands perfection and only allows resources for a WTF solution.  And then IT gets blamed by all for it.

    As for when finding a bug it should be fixed, I agree that it should be fixed or at least gracefully handled.  But I can't how many times that I've done this and been told not to fix it by management and then have them come back and gripe about why that bug was there.  Fortunately I've learned to document in writing all refusals by management to fix known bugs.

    Many times it not IT that decides that resources can't be allocated for projects, but rather IT is just the messenger.  Any solution must have support from the top or it is doomed to failure.

  • (cs) in reply to John Bigboote

    John Bigboote:
    We have a few Steves. The latest Pain-in-my-Steve is a guy who thinks that Flash is an acceptable tool for enterprise data reporting. So he runs reports, saves the results to XML, then posts the XML file to the intranet where it is pulled in by the Flash file.

    Then WE get calls asking why the Flash file doesn't update when the database does.

    Uh... Flash is an acceptable tool for enterprise data reporting. For the presentation thereof, anyway. You set up your Flash movie to get updates via an ASP/PHP/JSP/whateverSP script instead of a static XML file.

    Or, you just set up a timed job to regenerate the data file every five minutes (or whatever) and label the data as such.

     

  • (cs) in reply to Cratig
    Ford351-4V:
    <font face="Arial">Actually, many non-technical people firmly believe that all programs are coded in Excell.</font>


    From the makers of COBOL.net (not realy but..)

    Comes TurboExcel !!

    http://www.turboexcel.com/

    From the Site:

                <br>
    <!-- InstanceBeginEditable name="body" -->

    Develop C++ subroutines 10 times faster. No debugging. No testing.

                  </p>

    Have you ever written a program that worked on the first try? Neither have we. As any programmer knows, 90% of the time spent writing code is not writing the algorithm, it's debugging and testing. And debugging again. And testing again.

    TurboExcel breaks this cycle once and for all, giving you the ability to write perfect C++ programs instantly, on the first try. What's the secret? TurboExcel lets you use Excel to code in C++. Simply design your algorithm in an Excel spreadsheet, push a button, and TurboExcel will instantly convert your spreadsheet into a C++ subroutine that's error free and immediately usable. No more debugging. No more testing. No more screaming at the computer.

    With TurboExcel, you can now develop C++ subroutines in one tenth the time it usually takes. TurboExcel's C++ code is generated by the computer itself, so there's no room for human error: perfect working code gets written every time.


  • (cs) in reply to dhromed
    dhromed:
    RayS:
    You don't blame Pepsi for killing someone who died because they drank 200 gallons of pepsi in 5 minuntes.
    A coke doesn't have a time bomb built-in.
    I've been guilty of many analogies in forum-arguments in the past and I've come to the conclusion that they're best avoided. Anyone can puncture a hole in an analogy, because analogies by definition are not 100% airtight -- otherwise they're not analogies, but re-iterations of the subject at hand. :)

    Neither did the app. By the sounds of it, it would have chugged along quite happily for many years without causing a problem. Only by taking the app out of it's original position (single user) into a new one never accounted for in the (joke here, I doubt there really was one even) original spec.

    It was the unplanned change by the user(s) that caused the problem.


    RayS:
    Also it wasn't Steve's responsibility to fix it - as per the original post, STEVE HAD LEFT.
    His app.
    His responsibility.
    But Steve left.
    Lucky for him.

    I hope for your sake you never get into or involved in development. ;)


    Seriously though, you can't say "you wrote it, therefore it is your responsibility forever, even when we do things with it that weren't originally intended. In contractual terms:


    Steve was tasked with supplying a product to perform XYZ. He did. Everyone was happy. Then they changed the rules.


    It's true that one can design an app with a certain predicted load in mind. There is no WTF there. The business guys were only using their handy app, filled with glee that they could have their information. No WTF there.

    Steve's WTF is for making a design that was not merely "inefficient" or "designed for a certain load", but was grossly inefficient and a time bomb. Had Steve still worked there, it would have been his responsibility to fix it. At the very least, it was Steve's responsibility to explain to the user that his app was not intended for mass use. But apparently, he didn't.

    But naturally: two parties present, two parties at fault. The business guys should have had a bigger interest in how to properly use software and speak with IT depts.

    I agree.

    And while Steve's coding is a minor WTF (I can't really call it a big WTF since it worked to spec, did the job, and everyone was happy), that's overshadowed by the general political WTF that's behind it all.


    Just don't blame poor Steve who just did what he was told, and helped someone who possibly had the ability to fire him. :-)

  • captain damage (unregistered) in reply to pinguis

    I agree with someone above questioning who it is who is being difficult. For instance I have a VP who refuses to use some tools because they require two clicks instead of one.

    As for Steve. My experience with those sorts of people is that they happily produce tools which are have wrong calcuations and when writing lose data beacuse they don't handle errors or transations.

  • (cs) in reply to sammybaby
    sammybaby:


    Uh... Flash is an acceptable tool for enterprise data reporting. For the presentation thereof, anyway. You set up your Flash movie to get updates via an ASP/PHP/JSP/whateverSP script instead of a static XML file.

    Or, you just set up a timed job to regenerate the data file every five minutes (or whatever) and label the data as such.

     



    Excellent point, but our Steve did NEITHER of those things. He didn't even investigate them. He just knew he could load XML into Flash, so that was his development strategy. It's a classic case of having only a hammer and noticing that everything you see is in need of pounding.
  • (cs) in reply to pinguis
    pinguis:
    Ford351-4V:
    <FONT face=Arial>Actually, many non-technical people firmly believe that all programs are coded in Excell.</FONT>


    From the makers of COBOL.net (not realy but..)

    Comes TurboExcel !!

    http://www.turboexcel.com/

    From the Site:


    <!-- InstanceBeginEditable name="body" -->

    Develop C++ subroutines 10 times faster. No debugging. No testing.

    Have you ever written a program that worked on the first try? Neither have we. As any programmer knows, 90% of the time spent writing code is not writing the algorithm, it's debugging and testing. And debugging again. And testing again.

    TurboExcel breaks this cycle once and for all, giving you the ability to write perfect C++ programs instantly, on the first try. What's the secret? TurboExcel lets you use Excel to code in C++. Simply design your algorithm in an Excel spreadsheet, push a <FONT style="BACKGROUND-COLOR: #ffffff">button</FONT>, and TurboExcel will instantly convert your spreadsheet into a C++ subroutine that's error free and immediately usable. <FONT style="BACKGROUND-COLOR: #ffff00">No more debugging. No more testing.</FONT> No more screaming at the computer.

    With TurboExcel, you can now develop C++ subroutines in one tenth the time it usually takes. TurboExcel's C++ code is generated by the computer itself, so there's no room for human error: perfect working code gets written every time.

    Um, no debugging? What do they call it when you are trying to get the Excel spreadsheet to work, magic?

  • John (unregistered)

    Don't underestimate Excel macros.

    back in '96 I wrote a set of macros in Excel that pulled data from a OLAP cube, Access, Oracle, and FTP csv's from the Mainframe to print 5000+ page reports.

    And I was the DBA of the OLAP(Essbase) and Access databases.

    I got the system running well enough that I was able to sit down with the financial analyists and watch how they work, then offer them tools to make their work easier. They were, for example manually comparing a column of budget numbers from a group with the column of budget numbers from the executive office; so I wrote a macro that just highlighted the differances.

    When my contract expired, I'm sure the two people they needed to replace me emitted many WTF's over what I had produced. (nowdays I document everything I code as I code it.)

  • (cs) in reply to awefawfawfe
    Anonymous:
    Opinion Dalek:

    As someone who develops Excel applications for large firms, my experience is (of course) form the other side.  The worst WFT I encountered is for huge firm where the IT department quoted (for one project I did) 1 Project Manager and 2 Programmers from one of the top 4 Accounting firms to deliver a project.  2 years ago.  They are still working on it.  In the meantime, my (fully tested every time) spreadsheet is now up to version 11.  Every time I do a new version they tell me they aren't going to need me for the next one.

    IT doesn't need to be about better communication, it needs to be about results.  And supporting their users.  Not telling them what they can't do, but how they can.

    LOL.  An "Excel application".  That's like saying "Non-dangerous nuclear explosion".
     
    Did you ever think that maybe the reason the "WTF" project has taken two years is because their deliverable is something other than an a rinky-dinky Excel spreadsheet?

    It's like toilet paper, seriously!

    "Top 4 Firm, Inc" recommends that a process be put in place to buy all toilet paper products ten years before they're needed (the JIC - just in case - model).  They figure toilet paper prices will rise in the near future and buying now will provide substantial savings (the hedge bet).  They'll have to offer their consulting services, of course, to ensure the "process" is implemented using the latest whiz-bang productivity acronym that only they have extensive experience in [new, leading-edge process + extensive experience in said process = WTF?].  They figure out that even with the cost of properly storing all of this bulk toilet paper, the cost per sheet (CPS) would still end up being lower that the current production process.  Savings will start rolling in two years *after* the new process is put into production.  Awesome ROI!?

    The problem (waiting one the new process is now part of the problem) is now in the floor manager's hands.  He has to take a (data) dump now and can care less how much CPS savings will appear in the "planned" future.  His production budget has been cut by Accounting because the current process is deemed out-dated (thank you, "Top 4"!). However, if he can't get the dump completed quickly, and his drawers get dirty, then the production process comes to a halt! His anxiety has risen and therefore he makes more "pit stops".  Therefore, he starts purchasing and storing his own cache of toilet paper (at higher costs) using his own expense account.  These higher costs pass through Accounting with no problems (which is yet another problem - left hand not seeing what right hand is doing).

    Now some virtual system/process that is still not close to production is actually causing a higher CPS in production!  This means the initial ROI estimates are now wrong!  It'll now take three and a half years *after* the new process is put into production to recoup these additional soft dollars leaking out at the seams, but nobody knows it!

    <rant type="mini">Maybe Stephen Covey can help (A1, B2, C3.  Now I'm in control!)</rant>

    Next Chapter:

    "Cost-Cutting, Morale-Improving Lay-Offs!" - <FONT size=2>But why does everything cost so much now?</FONT>

    :)

  • Code Commando (unregistered)

    91 posts and NO ONE Gets it. The Excel Worm is the perfect example of what is wrong with I.T. today. I bet NO ONE can quote the cost / bennefit of their last project. Why do people hack out their own solutions in Excel files? Because running the problem by a bunch of  I.T. beurocrats  would have garnered a proposal that cost $200,000.00 Instead, they call Steve and 8 hours later they have what they need. I.T. would have had 32 man hours of meetings before even starting to write it up.
    So, apparently no one on this forum wants to admit that nothing they do has value. Thats right. I said it.  I'll bet that every project you have done has implemented a system that actually costs your company more than the problem you solved was costing.
    Imagine some poor secretary typing 500 numbers into a spreadsheet every day. Even a fat finger at 4 seconds per number does that in 30 minutes. The cost of the existing system in this example is $6 a day or roughly $100 a week. If the I.T. department codes a solution, it will cost meetings, discovery, design, overhead, development, delivery AND Maintenance. Maybe $200,000.00 for even the easiest thing.
    Thats SEVEN YEARS to break even on this one little I.T. project. Did your last project run un-modified for seven years? Steve hacked in some code in 8 hours. Payback in 16 days. And you guys call Steve the WTF. WTF? We in America spend all our time and money farking around with Computers, while the rest of the world builds things.

  • J (unregistered) in reply to Code Commando

    Anonymous:
    91 posts and NO ONE Gets it. The Excel Worm is the perfect example of what is wrong with I.T. today. I bet NO ONE can quote the cost / bennefit of their last project. Why do people hack out their own solutions in Excel files? Because running the problem by a bunch of  I.T. beurocrats  would have garnered a proposal that cost $200,000.00 Instead, they call Steve and 8 hours later they have what they need. I.T. would have had 32 man hours of meetings before even starting to write it up.
    So, apparently no one on this forum wants to admit that nothing they do has value. Thats right. I said it.  I'll bet that every project you have done has implemented a system that actually costs your company more than the problem you solved was costing.
    Imagine some poor secretary typing 500 numbers into a spreadsheet every day. Even a fat finger at 4 seconds per number does that in 30 minutes. The cost of the existing system in this example is $6 a day or roughly $100 a week. If the I.T. department codes a solution, it will cost meetings, discovery, design, overhead, development, delivery AND Maintenance. Maybe $200,000.00 for even the easiest thing.
    Thats SEVEN YEARS to break even on this one little I.T. project. Did your last project run un-modified for seven years? Steve hacked in some code in 8 hours. Payback in 16 days. And you guys call Steve the WTF. WTF? We in America spend all our time and money farking around with Computers, while the rest of the world builds things.

    Wow... Logic and reason... no knee-jerk-me-too response.  Are you sure you're on the right board? :)

  • (cs) in reply to Code Commando
    Anonymous:
    WTF? We in America spend all our time and money farking around with Computers, while the rest of the world builds things.


    Builds things..... that were designed with the programs we wrote with our computers.
    Builds things..... to house the computers we just sold them.
    Builds things..... to manufacter faster, smaller processors for our computers.
    Builds things..... to try and compete with US technology.
    Builds things..... like call centers to answer all of our calls while we are busy hacking away.
    Builds things..... like nuclear weapons to destroy the US.

    lol....

    Seriously though, not all companies operate like that. Many companies do operate like that, and many companies fail miserably. Nothing is ever the same, even in the same city. The better companies IMO are the ones that have streamlined their IT department with very intellectual, reliable IT people that get paid more than average, but deserve it because of how well they perform. Sadly, there aren't enough of these people for everyone, but there exist quite a few still, and the companies that have them know they do.

    just my $0.02
  • (cs) in reply to J
    Anonymous:
    Wow... Logic and reason... no knee-jerk-me-too response.  Are you sure you're on the right board? :)


    Unfounded and obviously wrong blanket generalizations with numbers pulled out of your ass are now called "logic and reason"?

  • Harsh (unregistered)

    What an idiot.  It's people like that that make me want to vomit all over myself

  • tdog (unregistered)

    Clearly, the disconnect in that office between business and IT was great enough to force the business into the behavior.  Business will do what is right for the business, not what makes IT sense.  IT must get off its high horse and realize the food chain.  Of course when I say this, I understand that sometimes IT must protect the business from itself.  So IT must work with business to effect change, not be the obstacle to change. 

    tdog

  • tdog (unregistered) in reply to Code Commando

    Anonymous:
    91 posts and NO ONE Gets it. The Excel Worm is the perfect example of what is wrong with I.T. today. I bet NO ONE can quote the cost / bennefit of their last project. Why do people hack out their own solutions in Excel files? Because running the problem by a bunch of  I.T. beurocrats  would have garnered a proposal that cost $200,000.00 Instead, they call Steve and 8 hours later they have what they need. I.T. would have had 32 man hours of meetings before even starting to write it up.
    So, apparently no one on this forum wants to admit that nothing they do has value. Thats right. I said it.  I'll bet that every project you have done has implemented a system that actually costs your company more than the problem you solved was costing.
    Imagine some poor secretary typing 500 numbers into a spreadsheet every day. Even a fat finger at 4 seconds per number does that in 30 minutes. The cost of the existing system in this example is $6 a day or roughly $100 a week. If the I.T. department codes a solution, it will cost meetings, discovery, design, overhead, development, delivery AND Maintenance. Maybe $200,000.00 for even the easiest thing.
    Thats SEVEN YEARS to break even on this one little I.T. project. Did your last project run un-modified for seven years? Steve hacked in some code in 8 hours. Payback in 16 days. And you guys call Steve the WTF. WTF? We in America spend all our time and money farking around with Computers, while the rest of the world builds things.

     

    Agreed. 

  • (cs) in reply to tdog
    Anonymous:

     So IT must work with business to effect change, not be the obstacle to change. 




    Nonsense. Anybody who wants me to do work for them has to beat me in a brawl. I am having one of our conference rooms converted into a mini-Thunderdome.
  • Code Commando (unregistered) in reply to brazzy

    Hit you a little too close to home brazzy? Generalizations work just fine when explaining concepts. The concept is cost / bennefit, ROI. 90% of the solutions we come up with cost more than the problem did. And 94% of statistics are made up on the spot. :)
    But, you are soooooo serious and sooooo technical that you need "real" numbers. Fine. Tell me what the cost of your last project was, and what the cost of the problem it fixed was. It a timed test.
    Go!

Leave a comment on “The Excel Worm”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article