The big question - why is there so much WTF-ery in Information Technology?



  • 1. There is WTF-ery in pretty much every industry but there seems to be more in software and IT than anything else.. why?

    2. What are the main general WTFs (please don't just give a language like VB/PHP without a reason) and why they are so frequent.

     

     



  • An accepted culture of non-experts.

    It's perfectly fine if the barrier to entry is low— that should be the standard for any field. The problem is that the peddlers of grap honestly believe they're doing a good job. There's no clear way of differentiating great work from shoddy work.

    Compare to visual art:

    Everybody can pick up a pencil and start drawing. This is obviously good.

    Everybody knows it when a master painter has produced a work.

    Everybody sees it when a work is crap.

    And, most importantly: every beginning artist sees how their own work has a long way to go.

    There is a culture of craftsmanship and slow improvement over time. Contrast with IT where apparently everybody is an opinionated expert after one year in the field.

    But the field is still extremely young. We've been painting and carpentingfor thousands of years. IT as we know it is half a century old.



  • @Cbuttius said:

    1. There is WTF-ery in pretty much every industry but there seems to be more in software and IT than anything else.. why?
     

    The IT industry is still an immature industry. Compare it to the financial industry, supply chain, construction - those have been around a lot longer, so have had many chances to iron out kinks. IT is still maturing, but it's the guidance of non-IT people forcing it to align to business perspectives that provide the best influence.

    There is also a culture that IT is a highly-skilled subject, and thus can command large salaries. I see it as a differently-skilled subject - it's no more complex than engineering or medical science; it's just as wide a field and it's impossible to be an expert in all areas, so many people specialise in some specific aspects and become generic in others, but there is still a misconception that someone working in that industry has a wide expanse of knowledge covering all aspects of that industry in great depth.

    Familiarity with commercial or domestic aspects (don't go to a heart surgeon for brain surgery, a car dealership may provide a better-quality but higher-priced servicing than a generic garage) is an education thing, and there are still many that see IT as an amorphous blob, not understanding layers and facets within.

    @Cbuttius said:

    2. What are the main general WTFs (please don't just give a language like VB/PHP without a reason) and why they are so frequent.

    People. To expand on that:

    • managers committing to unrealistic expectations with the customer and generating stress within IT (crunch time)
    • unskilled/inexperienced staff attempting to bat above their grade
    • perception that academic training trumps years of experience
    • silo mentality between disciplines - code devvers not talking to DB bods, neither engaging customer
    • self-serving (nest-feathering) within IT, rather than serving the business
    • poor project management, no QA, scope creep, weak stakeholder analysis/engagement
    • belief that tried and tested processes are appropriate for every situation
    • culture of decision-makers being insulated from accountability
    The sad fact isn't why this happens in IT, it's why it repeatedly happens in IT. It isn't limited only to the IT industry, but it seems more apparent - perhaps because IT hasn't grown up enough yet.



  • I think the fact that pretty much everywhere I have worked, developers are bottom of the hierarchy, with project managers as a senior position, explains some of why developers seem to have "no say" in matters. There is also the natural mentality to want to climb up the hierarchy, to be in a more senior position, and thus to move into project management.

    I totally dislike the fact that I am put into one project in a large organisation rather than be seen as an IT resource within the company that can switch between projects as appropriate, with some of my code shared between them when it is generic, and with my ability to work on whatever urgently needs to be done, and switch about if I am "blocked" waiting for something.

    This way I could actually end up working with several different project managers, and my manager would not be a project manager but someone who allocates the developer resources between the project managers.

    I think having that model would also improve the quality of the code, as developers would get a better understanding of scope.

     



  • @Cbuttius said:

    I think the fact that pretty much everywhere I have worked, developers are bottom of the hierarchy, with project managers as a senior position, explains some of why developers seem to have "no say" in matters.
     

    That isn't a reason why developers have no say.

    Developers have "no say" simply because those who are managing the analysis and design (PMs?) haven't engaged the developers - they aren't invited onto change management boards nor form part of the early activities because of their core skillsets. Developers should be used as a resource to build; designers will be creating plans of what to build, analysts will have determined why it needs to be built and for whom.

    This doesn't mean that developers can't provide value earlier upon in the chain, but they won't be attending in a developer role. IME, some developers are often chomping at the bit to start building before the prior stages are complete and signed-off, others contribute additional features that they'd like to see in the product but isn't of value to the customer - simply prolonging analysis stages.

    I feel it's up to the PM to decide who should be consulted (and why) during the overall process. If developers are ignored until the last moment then it's for a reason - which could simply be that the PM is a dickhead and doesn't value any input from devs (including more accurate estimates) and thus will receive what devs can deliver in the timescales allocated, no more, no less. Alternatively - as I have found - devs exhibit a target blindness that makes them unfocussed upon the task at hand and all too often muddy the water when discussing business outcomes and objectives with the customer/client, so there is just cause to exclude them.


  • Discourse touched me in a no-no place

    @dhromed said:

    An accepted culture of non-experts.

    It's not just a culture of non-experts, it's a culture of anti-intellectuals. Everyone's a non-expert at first, but only in IT is it acceptable to remain a non-expert and make fun of those who want to learn anything beyond what's necessary to handle the task at hand.



  • @dhromed said:

    An accepted culture of non-experts.

    There's also the culture of expert-experts, the developers who love to design and architect and invent with no consideration of whether the work they are doing is actually benefiting the end-product or not. This is one of the major causes of Lotus Notes, for example. Or that ImgBurn program I posted about this week.



  • @dhromed said:

    It's perfectly fine if the barrier to entry is low— that should be the standard for any field. The problem is that the peddlers of grap honestly believe they're doing a good job. There's no clear way of differentiating great work from shoddy work.
     

     I agree.  I would go a bit further and say that this is because of what someone else pointed out; that education is valued more than experience.  Which means that people with experience are generally assumed to have out-dated skills and nothing of value to teach the younger peers.  Which results in the industry overall staying immature longer because we have no mentoring/apprenticeship system, and keep committing (and tolerating) the same juvenile mistakes over and over again.



  • @Cbuttius said:

    I think the fact that pretty much everywhere I have worked, developers are bottom of the hierarchy, with project managers as a senior position, explains some of why developers seem to have "no say" in matters. There is also the natural mentality to want to climb up the hierarchy, to be in a more senior position, and thus to move into project management.

    I totally dislike the fact that I am put into one project in a large organisation rather than be seen as an IT resource within the company that can switch between projects as appropriate, with some of my code shared between them when it is generic, and with my ability to work on whatever urgently needs to be done, and switch about if I am "blocked" waiting for something.

    This way I could actually end up working with several different project managers, and my manager would not be a project manager but someone who allocates the developer resources between the project managers.

    I think having that model would also improve the quality of the code, as developers would get a better understanding of scope.

     

    Most of my experience has been in companies like that, but my current gig is exactly what you're longing for.  It's actually a fascinating case study, because the net result isn't what you think it would be.  The result is that everything is custom-coded and while we do re-use code whenever we can... well, everything is still custom.  Every project is implemented from scratch.  We use bits and pieces of purchased software like Oracle financials and instead of doing accounting like every other company I've ever worked for, every project includes a piece where somebody (usually the CRM, unless that team refuses, then accounting is left with manual processes - dead serious!) has to code up integration with financials. And not just financials.  Everything is custom-integrated with everything else.

    We have a PM who is always ranting that our systems should work more like commercial software; for example if we sell our services to a new client, he should be able to look at the product roadmap for our billing system and know what features he can use, and if it doesn't have what he needs he can see when it will be available.  (This is obviously internal IT, we don't sell software.)  He's got a fair point, because what we actually have to do is present a requirements document for every project to all of the development teams and ask them - requirement by requirement - if they can deliver that or if it needs to be developed.  The other day we were chatting about this.  He seems to blame the developers for this, because whenever he asks a developer for something the dev leaps into coding.  I told him that's what developers DO.  You can't blame developers for wanting to cut code, any more than you can blame a turtle for being slow and wearing a shell. 

    The problem at our company is that we have ex-developers throughout management so they pay a little TOO MUCH attention to the advice of the tech teams when there is canned stuff out there on the market that we could easily use.  Instead of evaluating commercial software (and I'm talking general business software like financials, CRM, etc) that fits our needs and championing it's purchase and use, the executives depend on the dev team managers to suggest solutions.  Since the dev team managers were all developers themselves at some point and they lead teams of developers, their suggested solutions are always "my team can build this".



  • @Cbuttius said:

    I totally dislike the fact that I am put into one project in a large organisation rather than be seen as an IT resource within the company that can switch between projects as appropriate, with some of my code shared between them when it is generic, and with my ability to work on whatever urgently needs to be done, and switch about if I am "blocked" waiting for something.

    This way I could actually end up working with several different project managers, and my manager would not be a project manager but someone who allocates the developer resources between the project managers.

    I think having that model would also improve the quality of the code, as developers would get a better understanding of scope.

    My organization works the way you wish yours does. It doesn't make any difference.

    I see this as a "the grass is greener on the other side" or a scapegoat argument. For the former, I see people saying both "I wish I could spend 100% of my time getting good at one thing" and "I wish I could be exposed to everything". You can't have both. The other way to look at this is that you always have one of the two scapegoats ready to go when something goes wrong. If you are on a single project, then you can blame the lack of knowledge of the other system. If you are a project-hopper, then you can blame the lack of time to get really familiar with the codebase.

    We have this discussion all the time where I work about documentation. Five years ago, I used to spend 30% of the time on any project creating thorough documentation. I created design documents, user manuals, install guides, support documents, etc. Then, when something went wrong or someone needed to add a feature, I would get called in to help the other person. I handed them the documentation, but they still couldn't figure out the problem and I had to spend my time on the problem anyways. Then I decided to switch to creating minimal documentation -- I still have to help people fix software, but I'm 25% more productive. Since the other guy is at zero productivity in either case, the organization is better off.

    All of these things are scapegoats. A good developer can figure out marginally crappy code pretty quickly without anyone's help, complaining about documentation is a sign of a weak developer. The point of modern software development is to make one piece of software less dependent on the implementation details of the software it interacts with. A developer who needs to know how everything works is a sign of a developer who doesn't understand encapsulation or loose-coupling. This is exactly why IT is full of WTFs, very few are willing to accept that they aren't good at what they do and work hard at getting better at the things that really matter. Clubuttius, you don't need to understand the other software better, you need to get better at interface design. Until you accept that, you won't get any better.

    A good developer isn't someone who knows everything, it's someone who has developed work habits that allow him to be successful while knowing the minimum amount of information (but no less). My favorite related quote - "If you insist on knowing all aspects of a problem before creating a solution, then you are doomed to work only on problems small enough to fit in your head."



  • @dhromed said:

    An accepted culture of non-experts.
     

    And a detail in one of the front-page articles reminded me of this other reason:  the general business community (anybody outside of IT) just plain can't tell the experts from the idiots.  So much of what we do still seems like black freaking magic, that we can't convince people which one of us are the charlatans and which are real.



  • @blakeyrat said:

    There's also the culture of expert-experts, the developers who love to design and architect and invent with no consideration of whether the work they are doing is actually benefiting the end-product or not.
     

    Do you think this is down to them believing their expertise in one field automatically makes them experts in others? Or that they're not properly managed/utilised into their correct domain (and kept isolated from others)?

    I know the academic world suffers from the former: those with qualifications cannot be informed of their mistakes or deficiencies by lower-qualified subordinates. It simply will not do.



  • @jetcitywoman said:

    Since the dev team managers were all developers themselves at some point and they lead teams of developers, their suggested solutions are always "my team can build this".
     

    .. and nobody asks if they should build this?

    I'm not going to cast aspersions about their capabilities, more their priorities.

    The IT world contains many rich tales of wheel reinvention: even web developers nowadays adapt some template or framework rather than build a CMS from scratch. It sounds like none of the devs are actually considering the cost/benefit implications of their decision.

    (yup... I know previous tales you've recounted have shown how some managers don't realise how much time and money they're wasting through their ill-informed decisions)



  • @Jaime said:

    complaining about documentation is a sign of a weak developer.
     

    Disagree there, if only for two reasons:

    • using the lack of documentation as a reason (or excuse) for not being able to fix the problem is a sign of weakness. Using the lack of documentation as a reason why it took so long, I can understand. Developers are the first to complain about lack of documentation, but they're also the last inclined to create any. They're not doing themselves any favours.
    • it's not just developers that use documentation. Project plans, configuration management, change management, designs - these are all documents. Without them, changes and maintenance involve lengthy information rediscovery to estimate required time and effort. I agree that you don't need to be completely anal about crossing eyes and dotting tees, but it's incredibly frustrating when you're pressured into producing results from unclear specifications, vague designs and wave-away committments.

    @Jaime said:

    A good developer isn't someone who knows everything, it's someone who has developed work habits that allow him to be successful while knowing the minimum amount of information (but no less).

    That. I think some of the better developers are those that not only don't know everything, but are actually aware of it and know they need to research and learn. Knowledge and skills are finite but it is attitude that focusses effort and produces results of value.



  • @jetcitywoman said:

    the general business community (anybody outside of IT) just plain can't tell the experts from the idiots. 
     

    It works both ways: I used to think Project Management was a dark art until I understood more about it (1: do a plan. 2: follow it) and I still feel the financial world is Cthulhu, instantiated.

    @jetcitywoman said:

    we can't convince people which one of us are the charlatans and which are real.

    If you're given plausible-sounding bollocks at the interview then you can't be blamed for hiring them.

    You can be blamed for keeping them on, once it transpires they're as effective as a fart in a hurricane. You'd normally know within a week, and be certain within a month.



  • @Cassidy said:

    • using the lack of documentation as a reason (or excuse) for not being able to fix the problem is a sign of weakness. Using the lack of documentation as a reason why it took so long, I can understand. Developers are the first to complain about lack of documentation, but they're also the last inclined to create any. They're not doing themselves any favours.

    Here's what I almost always see:

    Me: I need you to add this department as a CC to this system notification that goes out when X happens. Here's how to make X happen in the test environment and here's a copy of the notification that goes out today.
    Paula: OK, I'll look into it.
    Paula (the next day): I can't figure out what the system does, can I have some documentation?
    Me: I only asked you to add a CC to an existing notification, can you look into what the system does another day, the client is breathing down my neck?
    Paula: I can't do my job without the proper tools.
    Me: OK, here's the 300 pages of documentation we have. Also, here are the last twelve change controls related to it.
    Paula: Thanks.
    Me (the next day): How's the notification CC add coming?
    Paula: I'm still trying to figure this thing out, give me a few more days.
    Me (16 minutes later): I added the CC and checked in into source control, can you handle the change control for this.
    Paula: No problem.
    Me (the next day): What's the status of the change control for the notification CC add?
    Paula: Still working on it.
    Me (10 minutes later): Never mind, I did it.

    The next week:
    Manager: I hear you didn't give Paula enough opportunity to succeed last week.
    Me: She was taking too long, and I did it in a few minutes.
    Manager: You can't do everything, I need the whole team pulling on this.
    Me: OK, what can I do to help?
    Manager: Maybe you can give Paula something that is really simple and the requirements are spelled out very clearly.
    Me: That's exactly what we gave her; it didn't work.
    Manager: Do two hours a week of training to help get the new people up to speed. I'm sure it will get better over time.
    Me: OK.

    A few months later:
    Paula: I love this training, I feel better about working with this stuff every time we have a session.
    Me: Great, I need you to add this department as a CC to this system notification that goes out when X happens. Here's how to make X happen in the test environment and here's a copy of the notification that goes out today.
    Paula: OK, I'll look into it.
    Paula (the next day): I can't figure out what the system does, can I have some documentation?
    Me: I only asked you to add a CC to an existing notification, can you look into what the system does another day, the client is breathing down my neck?
    Paula: I can't do my job without the proper tools.
    Me: OK, here's the 300 pages of documentation we have. Also, here are the last twelve change controls related to it.
    Paula: Thanks.
    Me (the next day): How's the notification CC add coming?
    Paula: I'm still trying to figure this thing out, give me a few more days.
    Me (16 minutes later): I added the CC and checked in into source control, can you handle the change control for this.
    Paula: No problem.
    Me (the next day): What's the status of the change control for the notification CC add?
    Paula: Still working on it.
    Me (10 minutes later): Never mind, I did it.

    Four years later, Paula still works here and still doesn't know any of our software. Paula has written a total of about a thousand lines of code in those four years. Paula even once asked me to find documentation on code she wrote. When I couldn't find it, the irony was lost on her.

    @Cassidy said:
    • it's not just developers that use documentation. Project plans, configuration management, change management, designs - these are all documents. Without them, changes and maintenance involve lengthy information rediscovery to estimate required time and effort. I agree that you don't need to be completely anal about crossing eyes and dotting tees, but it's incredibly frustrating when you're pressured into producing results from unclear specifications, vague designs and wave-away committments.

    We manage to fail here on a totally new and unique level. Projects are always run by a Project Manager from our PMO office. Every project gets a collaboration site created at its inception. The Project Manager is usually very studious about making sure that all project related documents are on the collaboration site and to prevent confusion, we are to only use the copies on the site, no other repository is to be created. Sounds great so far, but shortly after the project is closed, the collaboration site is destroyed along with all of the documentation on it. This becomes an active obstacle to creating a long-lived, robust documentation store for our software. Also, every PM has a different format that they want the stuff in, so even if we do manage to keep it, it's difficult to merge it with the existing documentation.



  • @Jaime said:

    Here's what I almost always see:
     

    Summary:

    1. Paula lacks the capability to do the task, requests documentation - is this documentation about the system's functionality, or a training manual upon how to use the system?
    2. Manager insisting you throw incapable staff further lifelines. Does any monitoring process exist to compare the expected v actual benefits of said lifelines? It seems both of you are going down the "further training" route but there's no clear metrics to assess the suitability of the staff being trained. Have you got any documentation showing training attended versus required skills (skills matrix, SFIA, TNA charts, etc)?
    3. Both you and your manager are tolerating Paula's inefficiency. You're simply smoothing over the symptoms, rather than addressing the problem. Your manager is right in the sense that you shouldn't be doing it yourself, but you should throw the problem back at them and request a more skilled resource to free you up from those tasks.


    @Jaime said:

    but shortly after the project is closed, the collaboration site is destroyed along with all of the documentation on it.

    Why hasn't any PM actually flagged up how historical information from one project can provide a valuable contribution to specifications/business case for the next project? Most PMs I know try to approach every project as though it's BAU to them; it is pointless doing "lessons learned" if that learning is mindwiped when it could hvae been put to use.

    @Jaime said:

    Also, every PM has a different format that they want the stuff in, so even if we do manage to keep it, it's difficult to merge it with the existing documentation.

    I'm surprised the PMO hasn't established a set of common templates yet. Have you raised this as a potential improvement for change?



  • @Jaime. said:

    Clubuttius, you don't need to understand the other software better, you need to get better at interface design. Until you accept that, you won't get any better.

    Whilst what you are saying is indeed the case, i.e. yes it is very important for software to make its implementation more transparent and to separate it from the interface, you seem to be completely missing my point.

    My point was about scope. I see things from a software point of view. It is true that there are some areas of the code that require extensive business knowledge, but there are many others that do not. And those who are writing what I call the "business" code should be writing just that, not writing generic tools and sticking them into their business-scope code. The generic tools should be just that, i.e. generic and not belong to one business model. And should be used universally.

    In order to have this code used universally, there has to be integration between departments of a company.

    People who are writing business code and need something "generic" that isn't there should discuss how their generic code / tool should be integrated into the generic code base. There should also be one or more formal software librarian who is/are responsible for maintaining the integrity of the generic tool base, and - yes - documenting it. Ideally this will involve an experienced technical author. Those seem to be rare nowadays as "the powers that be" don't see their benefit and contribution. They see that they don't directly add anything to the business, whilst in reality they do indirectly by saving the time of developers who can get on with writing new features  / fixing bugs faster.

    In addition, and I'm pretty sure I'm not the only developer who has experienced this, getting them to part with their money on software tools like good bug-tracking, memory checkers, etc. and also in improving hardware and providing a proper test environment can be a huge challenge. Yet the money this costs is trivial to the cost of development time.

    Writing build systems is a skill in itself. In addition to "shell scripting". Most C++ developers on UNIX do not need to be expert shell-scripters. And most expert shell-scripters don't need to be C++ programmers. Shell-scripters will often be good at build-systems so if there isn't enough work around for a full-time shell-scripter, get one who does both. But don't keep rejecting experts in the main field of the project through the lack of a far-less essential secondary skill.

     

     

     

     



  • @Cassidy said:

    @jetcitywoman said:

    we can't convince people which one of us are the charlatans and which are real.

    If you're given plausible-sounding bollocks at the interview then you can't be blamed for hiring them.

    You can be blamed for keeping them on, once it transpires they're as effective as a fart in a hurricane. You'd normally know within a week, and be certain within a month.

     

    In principle, you're right.  However, it fails to explain the numerous times I've seen (and we've read here on DWTF) managers fall in love with technical idiots simply because they're so good at putting out fires - the managers never ask who started the fires, they only see that Paula is really good at putting them out, therefore without Paula they'd go out of business in a week.  

    The really good people don't let fires start in the first place, so they tend to look like lazy wastes of space to management and are the first to be laid off.  Right?  We've all seen that, I'm sure.  I guess my point is that the definition of a GOOD technician (to use a general term) is one that makes the job look easy, which is counter-intuitive to management.

     



  • @Jaime said:

    complaining about documentation is a sign of a weak developer.
     

    There are times when I agree with this, and times when I don't.  One of the times when I disagree is when the work you're doing is integration with another team of developers and you don't get to see their code.  Yes, people in integration roles should know how to properly build interfaces so that you don't have to see the code to know how to use it.  But in the real world....  When I was an engineer, there were several times when I spent days trying to get a new integration working, or running the debugger on MY code trying to figure out why a formerly-working integration stopped working after they "upgraded" the other side.  The one I remember best was only a few years ago:  I spent days trying to get a new integration working, and it just.  Would.  Not.  Work.  Went back to the other team several times to ask their help, they'd give me suggestions for things to look at, but wouldn't take the time to sit down with me and get it working all in one shot.  After beating my head against the wall, and even succumbing to using the debugger (a fantastic tool when the software isn't working the way it's supposed to) for about a week, the debugger finally helps me pinpoint the exact point of failure.  I take that back to the other dev team and ask why it does that.  Oh, they designed it that way because the other project needed it to work that way, why would you want it to be different?

    Complaining about documentation could also mean the OTHER developers are weak.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.