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.



  • @jetcitywoman said:

    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.  

    When I teach system administration courses, I compare good and bad attitudes to the task at hand:
    • a good sysadmin seems to be sitting around doing nothing - all the systems are running themselves, they're just monitoring them; a proactive approach.
    • a bad sysadmin is continuously fire-fighting, a reactive approach to things going wrong.
    @jetcitywoman said:
    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. 

    If anything, a good sysadmin seeks to put themselves out of a job; it then means they can take on more responsibility or move on/up. Only the bad ones try to make a job-for-life.

    However.... there's no enquiry after a major incident? Most organisations I know tend to have some post-mortem procedures. The good ones don't perform it to determine who gets fired, they do it with a view to preventing a recurrence - which means a thorough analysis to understand how it happened in the first place. Although you can point the finger at someone, usually it boils down to process circumvention or communication breakdown.

    I've not known many senior managers that aren't interested in saving money by preventing the outbreak in the first place. Of those that appeared disinterested, it transpired that they knew exactly how it happened and who caused it - and were either named, related to, or sleeping with that individual, so there was a vested interest in not exposing costly cockups.



  • @Cassidy said:

    @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.

    1. It doesn't matter.  If an incompetent developer asks for documentation, there is no hope it will help, no matter how good or how relevant it is.  But, if you can't give them documentation, then they have an excuse.
    2. Nope.  Developer will never learn, management will never fire.  Remember, one of my examples was when Paula needed training/documentation for code she wrote.
    3. I'm not tolerating anything, I recommend she be fired every time I'm asked.  I've been disciplined for trying an alternate route of vocally pointing out this employee's skills problem hoping she would fix the problem or quit.

    @Cassidy said:

    @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.

    I don't know.  It could have something to do with the fact that 90% of our PMs are contractors and they have no long term interest in the company.

    @Cassidy said:

    @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?
    They have.  However, we have so many templates that we effectively have none.



  • What Jaime and the manager like about Paula is she is happy to fill that role of junior developer.

    Bring in a top developer and put them in a junior role like that and they won't be happy there. Why are you changing code to add a new CC to a notification? Why is it such a tricky task you need to deploy it to a junior to do and she needs to read a 300-page document to know how it's done?

    The problem is that Jaime is comfortable in his role as the senior developer who doesn't bite back at his code and he probably wants it to stay that way.

     

     



  • @Cbuttius said:

    Why are you changing code to add a new CC to a notification?
    The original developer forgot to make the CC configurable since the original requirement didn't have any CC at all.

    @Cbuttius said:

    Why is it such a tricky task you need to deploy it to a junior to do and she needs to read a 300-page document to know how it's done?
    We gave this task to this developer specifically because it was so easy.  She doesn't need any documentation, that's my while point.  However, even with 300 pages of documentation, she still can't get it done.

    @Cbuttius said:

    What Jaime and the manager like about Paula is she is happy to fill that role of junior developer.
    I don't like anything about this situation.  I would rather she was unhappy and walked in front of a train.

    @Cbuttius said:

    The problem is that Jaime is comfortable in his role as the senior developer who doesn't bite back at his code and he probably wants it to stay that way.
    If I wanted it to stay this way, I wouldn't have made potentially career-limiting drastic moves to try to change the situation.



  • @Cbuttius said:

    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.

    Then you're using a language with too much boilerplate and should pick something better. Every piece of code written should contribute directly to solving the problem. Boilerplate is bad, and programming environments that require boilerplate should be shunned.

    @Cbuttius said:

    Most C++ developers on UNIX do not need to be expert shell-scripters.

    Oh well there's your problem.



  • @blakeyrat said:

    @Cbuttius said:
    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.
    Then you're using a language with too much boilerplate and should pick something better. Every piece of code written should contribute directly to solving the problem. Boilerplate is bad, and programming environments that require boilerplate should be shunned. @Cbuttius said:
    Most C++ developers on UNIX do not need to be expert shell-scripters.
    Oh well there's your problem.

    I know you hate C++. I never intended to get stuck in it myself but ended up in a "played with the wrong toys" scenario so I can't get a job using C# because I haven't used it yet. Same happened to me with Java in the early 00s when I considered moving over to something more modern in that direction.

    You know, we all know that if you are able to program well in C++ you should be able to pick up C# or Java easily but you know what recruiters are like. Never allowed a learning curve, especially once you become rather expert in something, and it's no use going for a lesser paid role to try to re-learn because they know that as soon as you pick up the skill for long enough you'll leave for somewhere that will pay you more.

    I want to work on UNIX systems because C++ is seen as a primary development language there and is generally written there the way it should be without that awful WTF called COM getting in the way.

    In all the time I have developed on UNIX systems I have been required to write very very few scripts compared to C++ code. One tends to write a few short ones from the manuals then use them often. A typical "geeky" UNIX question would ask you to remember all the command line switches of some command in your head to achieve some output. I once got rejected with a message that they found it surprising because I knew some of the more complex featurse of UNIX but was unfamiliar with sed or awk... well perhaps because I wasn't required to use sed or awk in my previous project. I know what sed is now, and have used that a few times, it's quite a useful in-place find and replace tool. I don't think I have still ever used awk. And vi is one of the most repulsive dated editors.

    So yes, of course it's a much nicer development environment on Windows.

     



  • @blakeyrat said:

    Boilerplate is bad, and programming environments that require boilerplate should be shunned.
     

    I shun the fuck out of ASP.Net, but it's not a practical stance from a competent-professional point of view.



  • @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?

     

    And why do you say there is more WTF in IT?  It's simple to show a WTF (few lines of code) and you as IT person can actually understand it compared to a WTF in a completely different area. I can think of some at my company but they can't be explained injust a few lines...

     

    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.

     

    •  Project Managers. "Exception proofs the rule" as there certainly are good ones but most just have no clue...Hence the Project Plan will be unusable (a WTF) and how can the product of such a project not be a WTF itself?
    • Management: They hear of a "cool idea" be it internal or external from someone they "trust" or "believe in" and then force that idea down your throat regardless how loud you scream while at the same time they ignore any ideas that would actually benefit the users and hence the company. That can be applied to non-IT stuff just as well.

     



  • @beginner_ said:

    Management: They hear of a "cool idea" be it internal or external from someone they "trust" or "believe in" and then force that idea down your throat regardless how loud you scream while at the same time they ignore any ideas that would actually benefit the users and hence the company. That can be applied to non-IT stuff just as well.

    Oh man. One group at my company, they've spent a long time developing a feature which is, admittedly, extremely technically impressive and cool. Then a few weeks ago they demoed it to our group (we're one of the few groups in the company that actually consume the data the company provides) and asked us, "what can we use this cool new feature for?"

    We thought about it for a week or so, played around with the feature, and finally came to the conclusion: nothing. The data isn't useful statistically at all, it doesn't match other data in the system (different cleanup rules) so you can't use it comparatively, clients that aren't extremely technically-sophisticated won't be able to even retrieve the data (much less store it), and storing the data requires a huge IT outlay that clients won't make.

    The only thing it's good for, and this is iffy, is making pretty-looking animated infographics that the client can install in their lobby. That's it. And it's not even good for that, since it will in 99% of cases still require the client to be technically sophisticated enough to build servers on their own to back the display.

    Basically, they spent 9 months working on a feature without even once asking themselves, "what's the use-case? What's it for?" And that's why all you asshole engineers who love abstracting stuff to shit and back need people like me around, so there!



  • @blakeyrat said:

    @beginner_ said:
    Management: They hear of a "cool idea" be it internal or external from someone they "trust" or "believe in" and then force that idea down your throat regardless how loud you scream while at the same time they ignore any ideas that would actually benefit the users and hence the company. That can be applied to non-IT stuff just as well.
    Oh man. One group at my company, they've spent a long time developing a feature which is, admittedly, extremely technically impressive and cool. Then a few weeks ago they demoed it to our group (we're one of the few groups in the company that actually consume the data the company provides) and asked us, "what can we use this cool new feature for?"

    We thought about it for a week or so, played around with the feature, and finally came to the conclusion: nothing. The data isn't useful statistically at all, it doesn't match other data in the system (different cleanup rules) so you can't use it comparatively, clients that aren't extremely technically-sophisticated won't be able to even retrieve the data (much less store it), and storing the data requires a huge IT outlay that clients won't make.

    The only thing it's good for, and this is iffy, is making pretty-looking animated infographics that the client can install in their lobby. That's it. And it's not even good for that, since it will in 99% of cases still require the client to be technically sophisticated enough to build servers on their own to back the display.

    Basically, they spent 9 months working on a feature without even once asking themselves, "what's the use-case? What's it for?" And that's why all you asshole engineers who love abstracting stuff to shit and back need people like me around, so there!

    Because you should write something initially because there is at least one place in the business where it is needed, but with a view that if you write it properly, the more generic parts of what you write, have a bigger scope than just that one need.

    It isn't a lot of extra work to write it that way, and it isn't totally wasted because you are intending to use it at least once.

    I have seen code here where I am working now that is WTF'y in that they are using templates for the sake of it, when in the business code it is only ever used with one type. In particular you see that a lot with string types, when in reality you never handle Unicode in your project (except in all those awful COM components, of course, where the native string is unicode).

     



  • @Jaime said:

    complaining about documentation is a sign of a weak developer.
     

    @Jaime said:

    If an incompetent developer asks for documentation, there is no hope it will help, no matter how good or how relevant it is.  But, if you can't give them documentation, then they have an excuse.
     

    Your original statement alludes that someone requesting documentation indicates they are a poor developer, which I disagreed with. Your latter statement now observes that the competancy of the developer is unrelated to them requesting documentation, which I agree with.

    @Jaime said:

    Nope.  Developer will never learn, management will never fire. 

    Usually the message never hits home unless there is evidence to show the scope of the problem.

    I found arguing and complaining would be remembered for that day, forgotten tomorrow, so I began graphing the number of times it occured and showing these diagrams in meetings to expose the scope of the problem.  It didn't magically fix the problem, but each repeated incident caused the bar to grow, and attendees of successive meetings revisited the same disgram but with an ever-increasing bar length.

    Eventually management stopped asking me why it happened, but that didn't silence the problem - I began asking how much more time and money would be lost as a result of their inability to make a decision, even when presented with the facts and in full control of the knowledge that it's been an ongoing problem. They weren't really shamed into doing something about the problem, I simply played the same card at "Improvement Opportunities meeting", "Committment to Quality meeting", "Cost-savings meeting" and after higher-priority stuff was dealth with and fell off the top of the list, this issue bubbled up and then had a committment for action.

    Not saying that it'll work for you, but I've found exposure of the problem in metrics people can understand can change attitudes.

    @Jaime said:

    I'm not tolerating anything, I recommend she be fired every time I'm asked.  I've been disciplined for trying an alternate route of vocally pointing out this employee's skills problem hoping she would fix the problem or quit.

    I suspect there's some ulterior motive behind keeping her on. Are you being punished for something?

    @Jaime said:

    I don't know.  It could have something to do with the fact that 90% of our PMs are contractors and they have no long term interest in the company.

    Probably. If anything, that's a way of inflating the project effort and thus charge more (for unnecessary work). Do you have any long-term contractors?

    @Jaime said:

    They have.  However, we have so many templates that we effectively have none.

    Egads. That's the great thing about standards, there's so many of them.



  • @beginner_ said:

    Project Managers. "Exception proofs the rule" as there certainly are good ones but most just have no clue...
     

    I find this is a somewhat misleading title. I've come across good and bad project managers:

    • good Project Managers that manage projects effectively
    • people that are managing a project but don't call themselves "Project Managers"
    • people that call themselves "Project Managers" but are managing a single task and don't perform anywhere near the amount of activities required to manage a project
    I've also had arguments with people that blame project managers for monumental cockups, and thus conflate "PM = incompetant twunt". I think anyone can be incompetant, irrespective of their job title or daily responsibilties. 



  • @blakeyrat said:

    Basically, they spent 9 months working on a feature without even once asking themselves, "what's the use-case? What's it for?" And that's why all you asshole engineers who love abstracting stuff to shit and back need people like me around, so there!
     

    Or rather, the design team/asshole engineers needed a business case (and an approved one at that) before they commenced work. Was there even a project manager involved who committed the team to this 9 months of effort? Will anyone be held accountable for this sizeable investment without any value potential for returns?

    Is there any scope to licence or sell the product on, even if you can't make use of it?



  • @Cassidy said:

    Was there even a project manager involved who committed the team to this 9 months of effort?

    Yes, but they're the one who didn't think about what good it was.

    In fact it's actually worse than I explained. They wanted to get away from providing a reporting interface to clients (probably because that requires actual non-fun work) and transition a scheme where our company would only provide the APIs and clients would have to write their own reports. It took a lot of willpower to not say, "you have got to be fucking kidding me" when they mentioned that in the meeting.

    @Cassidy said:

    Will anyone be held accountable for this sizeable investment without any value potential for returns?

    I highly doubt it. In any case, I don't plan to stick around in this company long enough to find out. Hell, I got an interview this afternoon.

    @Cassidy said:

    Is there any scope to licence or sell the product on, even if you can't make use of it?

    Nope.



  • Here's another source of WTF-ery, based on recent Twitter conversations:

    A lot of IT people think git is actually a pretty good tool to use.

    If their standards for software are so low they think git is good, imagine what the products they produce must be like!



  • @blakeyrat said:

    Here's another source of WTF-ery, based on recent Twitter conversations:

    A lot of IT people think git is actually a pretty good tool to use.

    I prefer using more secure methods, like renaming files whenever there's a new revision. Also, I don't believe in testing. All programming should be done live.


    FTFY



  • @Jaime said:

    It could have something to do with the fact that 90% of our PMs are contractors and they have no long term interest in the company.
     

    This is such a good point that it must not go unremarked.  It also applies to software developers.  Part of the quality problem with H1B's is that they're contract workers; they know they'll be gone in a few months so they write the precise code they're asked for and never ask why or if it's the right thing to do.  If companies matched contract development teams up with FTE business analysts, that would mitigate the problem, but they don't.  For some reason corporate management can't fathom the concept that a contract worker only cares about his next paycheck, not whether the company will succeed or not.



  • Can we get a blanket ban on anybody who does FTFY? Seriously.



  • @jetcitywoman said:

    @Jaime said:

    It could have something to do with the fact that 90% of our PMs are contractors and they have no long term interest in the company.
     

    This is such a good point that it must not go unremarked.  It also applies to software developers.  Part of the quality problem with H1B's is that they're contract workers; they know they'll be gone in a few months so they write the precise code they're asked for and never ask why or if it's the right thing to do.  If companies matched contract development teams up with FTE business analysts, that would mitigate the problem, but they don't.  For some reason corporate management can't fathom the concept that a contract worker only cares about his next paycheck, not whether the company will succeed or not.


    Another bright reason why you should offshore work instead of hire H1B worker.
    Offshore to permanent employee in India.


    Also one option for American company is to get their own H1B employee instead of rely on some contract based company, but they don't want to get to legal thingies.



  • from my point of view, there is failure everywhere. not just IT. there are fields where failure is not tolerated (example: medicine still happen all the time). or where failure is ok like
    (law and politics). then there is stuff where you expect one thing and get another (example: custom made wedding jewellery, custom made clothing). there is no way to tell good craftman from bad tailor. reputation is what differentiate the two. in case of IT, there are so many eager fish jump to take bait that it is impossible to sort them out. End Result: bad craftsmen and poor tailors are making your software.



  • Here are two point that are rather unique to IT:

    1. The differences in employee performance are staggering. I'm not sure if it was in Peopleware, but Tom DeMarco does state in one of his books that programmers might differ in performance by a factor of 20. What one programmer will do in a day will take another the entire month. In two weeks, the fastest guy will accomplish what will take the other an entire year. This is a fact. Hardly anyone believes it. If the same team keeps working together, they can come up with fairly accurate project estimates. Our estimates range from about 50% to 200%, so we're not more off than by a factor of 2 either way. For a new team, this might easily be a factor of 10. It's terribly difficult to plan this way. It's impossible if this range of performance is entirely disregarded.

      (True story: our company decided to outsource some IT work to India. They argued that the developers there cost 1/10th of my rate. After a month, we got a functional package back. After my review, I deleted everything and wrote the package myself in half a day. After that, our company stopped outsourcing.)

    2. The time it takes to throw together a half-functional demo is incredibly short. Because of this, customers are not required to think hard about their requirements. They probably couldn't even if they wanted to. People have no problem defining every detail about a new house, maybe using one of those cardboard models from the architect. In IT, the customer can ask for a screen-dummy and then make up his mind what actually needs to be on the screen. I often encounter customers who can only be specific about a piece of software once they have a first version in front of them. Using drawings and such just doesn't draw out all the necessary details. Often, those demo versions make it to production.


  • @sniederb said:

    They argued that the developers there cost 1/10th of my rate
     

    The (initial) cost is what appeals, until the quality of the deliverables are examined - then people realise it costs a tenth of the cost but takes ten times as long.

    @sniederb said:

    I often encounter customers who can only be specific about a piece of software once they have a first version in front of them.

    I've found - in general - customers either:

    • don't really know what it is they want, but can easily point out what they don't want
    • know what they want, but aren't very good at articulating it
    • are apt to change their mind once results are forthcoming (either final products or prototypes) - either because there's something they never considered, or they have suddenly decided upon a new cool feature they'd like.

    A good BA or PM should draw out as much info as possible and capture it in a descriptive manner (usually diagrams) but treat those as working documents - just something that refines and clarifies the position of both customer and supplier. A coder is apt to run off too early and build the first thing they hear about, without taking other functionality or discussion points into consideration - hence them being excluded until designs are finalised. 

    Because S/W doesn't incur disposal costs and can be changed fairly easily/quickly, there is a misconception about the overall cost and speed of product delivery.



  • There is an "anti-patterns" book. The bad mistakes in IT and how to avoid them... Perhaps I should write one of my own, it might make good reading.

    Here are some home truths:

    1. The only people who can write code are developers. Business analysts cannot write code. Not in a high-level or low-level language and not in a scripting language. They just can't write it.

    2. In-house scripting languages are a bad idea for 3 main reasons: (i) Nobody outside your company knows it so it wil be a learning curve for them. (ii) Nobody wants to be programming in it as it can't be used elsewhere and people want transferrable skills. (iii) You need to devote programmers to writing and supporting your scripting language rather than writing business code.

    There are advantages of scripting languages but use a standard one that's out there. And you can find programmers who know it or are willing to learn it. Build libraries - yes.

    3. There are generally two types of programmers. Those who are "closer" to the business and those who are more "generic techies". Both types can be very useful. Work out what you need and mix and match appropriately. The "generic techie" ones should be thought of as a global resource within your company, not tied to one business area. It is very important that they interact and communicate effectively with the business-driven techies (not with BAs).  Most of the time your generic technies should not be writing business code but should be helping the business-driven techies to achieve their goals faster. Occasionally, business-driven technies may write some generic code and it's up to the "generic" team to manage what happens to this.

    In the case above by blakeyrat, I see the WTF being something on the grounds of:

    - violation of rule 1: expecting clients who are non-technies to be able to write code

    - possible violation of rule 2: were they creating a custom scripting language (possibly to enable the clients to write code without learning a formal language?)

    - possible violation of rule 3: lack of communication, the generic techies are supposed to be there to help the business-driven ones achieve their goals faster, not writing generic stuff for the sake of it (or for the purpose of  violating rules 1 and 2)/

    Rule 3 is so often the most violated I would like to split it into parts.

     3a: Recognise there are two different types of technicians.

     3b. Employ both types, even if you are small development team, and the right type for the right role.

     3c. Generic-types not tied to one business area, but have a manager who knows what is required and ensures the work performed is beneficial.

    The general WTF I find of creating teams of developers who all have exactly the same skillset or expecting individuals to have too many side skills is a WTF similar to rule 3. Many of us here probably have experience of being rejected from a job because we didn't have some side-skill.

     



  • @Cbuttius said:

    1. The only people who can write code are developers. Business analysts cannot write code. Not in a high-level or low-level language and not in a scripting language. They just can't write it.

    Well ok, but the developers need supervision or they tend to make things like git, or Vim, things which may contain clever code but nobody can fucking use without 12 years of training. You can't make good software with developers alone, just ask Google-- they hire the best "code-y" people they can find, and every product dev effort fails over and over again.

    @Cbuttius said:

    2. In-house scripting languages are a bad idea for 3 main reasons: (i) Nobody outside your company knows it so it wil be a learning curve for them. (ii) Nobody wants to be programming in it as it can't be used elsewhere and people want transferrable skills. (iii) You need to devote programmers to writing and supporting your scripting language rather than writing business code.

    What the... where does this come from? Who uses an in-house scripting language in 2012?

    @Cbuttius said:

    3. There are generally two types of programmers. Those who are "closer" to the business and those who are more "generic techies". Both types can be very useful. Work out what you need and mix and match appropriately. The "generic techie" ones should be thought of as a global resource within your company, not tied to one business area. It is very important that they interact and communicate effectively with the business-driven techies (not with BAs). Most of the time your generic technies should not be writing business code but should be helping the business-driven techies to achieve their goals faster. Occasionally, business-driven technies may write some generic code and it's up to the "generic" team to manage what happens to this.

    I don't fit into either of your weirdly-defined groups.

    @Cbuttius said:

    - violation of rule 1: expecting clients who are non-technies to be able to write code

    True.

    @Cbuttius said:

    - possible violation of rule 2: were they creating a custom scripting language (possibly to enable the clients to write code without learning a formal language?)

    No, and what the hell is your obsession with custom scripting languages? WTF man.

    They wanted to (eventually) replace our product with has a good-but-not-great web-based UI with REST APIs. The idea being we provide only the REST APIs and the client builds their own UI. Which is a terrible idea. No scripting languages are involved.

    @Cbuttius said:

    - possible violation of rule 3: lack of communication, the generic techies are supposed to be there to help the business-driven ones achieve their goals faster, not writing generic stuff for the sake of it (or for the purpose of violating rules 1 and 2)/

    This is also true, but it's more like: the developers never actually meeting or talking to any consumers of the data (until they started talking with my group, 9 months too late.)

    @Cbuttius said:

    The general WTF I find of creating teams of developers who all have exactly the same skillset

    Definitely a WTF, and goes back to the Google example. Google has too many engineers, not enough non-engineers. For something like their search back-end, or their ad serving exchange that's not necessarily a bad thing. For something customer-facing, like Buzz or Wave, it leads to failure every time. Even the "improved, lesson learned" version of Buzz, Google+, is having a lot of trouble gaining any kind of traction.

    @Cbuttius said:

    or expecting individuals to have too many side skills is a WTF similar to rule 3. Many of us here probably have experience of being rejected from a job because we didn't have some side-skill.

    All else being equal, I'd take the developer who has a side-skill over one who does not.



  • @blakeyrat said:

    just ask Google-- they hire the best "code-y" people they can find, and every product dev effort fails over and over again.
     

    @blakeyrat said:

    For something customer-facing, like Buzz or Wave, it leads to failure every time.
     

    I think your hyperbole is misplaced, given the ubiquity of Gmail, Chrome, Android and Google Search itself.

    @blakeyrat said:

    What the... where does this come from? Who uses an in-house scripting language in 2012?

    Didn't Bethesda do that? Isn't that a thing you complained about when making mods?

     



  • @blakeyrat said:

    Well ok, but the developers need supervision or they tend to make things like git, or Vim, things which may contain clever code but nobody can fucking use without 12 years of training. You can't make good software with developers alone, just ask Google-- they hire the best "code-y" people they can find, and every product dev effort fails over and over again.

    Not all of them. It just depends usually whether the idea has merit or is just some attempt to take over an idea that isn't theirs. Making a single software product too feature rich is a WTF in my opinion, and I have to say I really dislike iTunes as a typical example of being just that.

    @blakeyrat said:

    What the... where does this come from? Who uses an in-house scripting language in 2012?

    I am not sure how many new ones are being written and rolled out. There are plenty still out there, that we read about. I know of one large investment bank in which large amounts of its development have been historically done in their own in-built scripting language and it remains that way because it's far too difficult to change that now. Of course, most of the time at least, they can afford to pay a team of developers to maintain this scripting language, which has a regular 2-week release cycle. 

    @blakeyrat said:

    They wanted to (eventually) replace our product with has a good-but-not-great web-based UI with REST APIs. The idea being we provide only the REST APIs and the client builds their own UI. Which is a terrible idea. No scripting languages are involved.

    Not a scripting language but seems to still suggest that the client, who presumably are not developers, will develop part of the product. And if they are developers, they want to develop their own product, not yours.

    @blakeyrat said:

    All else being equal, I'd take the developer who has a side-skill over one who does not.

    All else has to be equal first though. And it depends on the importance of the side skill and of the primary skill that they will be doing. I would rather go for someone who is expert in the secondary skill and others who are just basically adequate in it, or at least competent enough to pick it up under the guidance of the expert.

    In particular I refer to shell-scripting and "system-level" UNIX stuff when your primary skill is writing code.

     



  • @dhromed said:

    I think your hyperbole is misplaced, given the ubiquity of Gmail, Chrome, Android and Google Search itself.

    Gmail is an exception, and perhaps Chrome. Chrome is 95% WebKit, but a lot of the UI decisions made-- packing in Flash so users don't have to worry about updating it, removing the "http" from the URL bar, etc-- are very good decisions. For the record "ubiquitous" doesn't imply "good". McDonald's is ubiquitous.

    Android isn't very good.

    Google Search is impressive back-end-wise, but the front-end was shit until Bing came along and Google started ripping off Bing.

    @dhromed said:

    Didn't Bethesda do that? Isn't that a thing you complained about when making mods?

    Yes, but the games industry is always a decade behind everybody else, software-practice-wise. Creation Engine also doesn't have any unit testing or fuzz testing capabilities, for example.



  • @Cbuttius said:

    Making a single software product too feature rich is a WTF in my opinion, and I have to say I really dislike iTunes as a typical example of being just that.

    I'm not talking about features, I'm talking about usability. Features people can't figure out how to use don't exist.

    iTunes is indeed complete trash.

    @Cbuttius said:

    I am not sure how many new ones are being written and rolled out. There are plenty still out there, that we read about. I know of one large investment bank in which large amounts of its development have been historically done in their own in-built scripting language and it remains that way because it's far too difficult to change that now. Of course, most of the time at least, they can afford to pay a team of developers to maintain this scripting language, which has a regular 2-week release cycle.

    I guess my question is, "why do you think custom scripting languages are so ubiquitous (LOVE THAT WORD!) that you add it to a piece of general advice about the industry at-large?" Because I think custom scripting languages is a drop in the bucket, problem-wise, and you gave it bullet point two.

    @Cbuttius said:

    Not a scripting language but seems to still suggest that the client, who presumably are not developers, will develop part of the product.

    Even worse, because it's not like our client's code would go into a shared bucket. They'd each be developing their own product.

    @Cbuttius said:

    And if they are developers, they want to develop their own product, not yours.

    Well, we still provide the data. But yes, that's basically what they were thinking.

    @Cbuttius said:

    All else has to be equal first though.

    Yeah, it's called a "hypothetical statement".

    @Cbuttius said:

    In particular I refer to shell-scripting and "system-level" UNIX stuff when your primary skill is writing code.

    The bigger problem there is that people doing shell-scripting and "system-level" UNIX stuff are going to think like UNIX users, which means they won't be able to write a usable product to save their lives.



  • @dhromed said:

    @blakeyrat said:
    ...

    I think your hyperbole is misplaced,

    I LOL'd.

    @dhromed said:

    ...given the ubiquity of Gmail, Chrome, Android and Google Search itself.

    I agree. Also, considering these generally come from employee experiments, I would expect a lot of stuff to fail, and I'm sure they do, too, so long as some of it sticks. Of course, anyone who thinks they can predict what will or won't work is just fooling himself.

    But the 20% stuff being the genesis, I suspect even with all of the failures, it's a lot less costly than something explicitly managed and engineered in a "proper" fashion in order to get equivalent results.

    @dhromed said:
    @blakeyrat said:
    What the... where does this come from? Who uses an in-house scripting language in 2012?
    Didn't Bethesda do that? Isn't that a thing you complained about when making mods?

    Yeah, I wouldn't worry about his ideas of what things are or are not (or even should or should not) be used in 2012. Even, as you point out, when he has direct WTF experience with them.



  • @blakeyrat said:

    For the record "ubiquitous" doesn't imply "good"
     

    You were talking about success/failure, not good/bad.

    @blakeyrat said:

    Android isn't very good.

    But it's not a failure.

    So, the (incomplete) list so far is:

    Search - success
    Gmail - success
    Wave - FAIL
    Buzz - FAIL
    Android - success
    GDocs - euh?
    Chrome OS - not sure
    Google+ - still working.

     

    Are your criteria for failure different than mine?

     


Log in to reply
 

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