"That limits functionality, doesn't it?"



  • Several years ago I was one of the front-end developers for a system that was primarily used in-house by our account managers, but we had some clients using it as well. To put in the most generic terms, it was a website marketing system which, in addition to managing ad campaigns (not just online campaigns, but TV and radio) and SEO data, also reported traffic statistics and other data with a wide array of demographics. Like many systems, users could be assigned to groups, each of which had certain permissions. Account managers were only allowed to see their own clients' data, and there were certain users who were only allowed access to view statistics as opposed to, say, creating new campaigns or creatives. Doing the wrong thing on these accounts could cost us or the client thousands of dollars, so some more advanced tasks followed a strict workflow between admins and account managers to ensure things were done right, and to prevent some rouge employee from wrecking havoc.

    We were in the midst of a huge project which revamped the system to make it more user-friendly, have better performance, all that great stuff. We had hired someone to do all of the mockups and wireframes for the new interfaces. When we got to the account creation page for admins, there was a glaring piece missing.

    I went up to her with the diagram and asked, "I don't see anywhere in this mockup that assigns the user to a set of groups. Is that going to be done on some other page?"

    She furrowed her brow. "Uuuh, huh? What groups?"

    "I'm pretty sure it was in the spec." I pulled it out. "See? Here: 'Accounts shall be assigned to at least one group which will correspond to a set of permissions.'"

    "Permissions? Why permissions?" She looked very confused.

    "Well, you know, like some people shouldn't be able to create new accounts, and others might be able to create new ad campaigns, but they must be approved by a supervising manager and there are those users who have read-only access to the traffic data and nothing more."

    "Huh..." and the next words out of her mouth would live in infamy at that place. "That sort of limits functionality, doesn't it?"

    "Yes. That's the point."

    "Well, it's bad UI design to limit one's functionality. What if they wanted to create a new account?"

    "They'd have to seek someone with those permissions to do so. System account creation is only reserved for admins, not for junior account managers and definitely not for clients."

    "I don't agree with that philosophy," She frowned. "Best practice is to make tasks and operations in this system as simple as possible for all users, not just admins. Just implement the page like I mocked it."

    We went back and forth a little while longer before I got the project manager involved. The designer didn't budge, calling our plans to "box in" users a horrible idea that made the system useless.

    After a few more instances similar to this followed (including a tirade saying logging someone out after 30 minutes of inactivity was what caused her to cancel her bank account and thus we shouldn't even think about doing the same thing here), she was reassigned to do other tasks, such as writing end-user documentation.



  • Dang rouge developers.

    Also, she sounds like she shouldn't be let anywhere near a decision.



  • @Sutherlands said:

    Dang rouge developers.

    Obligatory rogue/rouge joke.



  • Reminds me of something from my job. I was redoing the UI to add users, and one thing assigned to accounts was permissions level. Fairly standard stuff: "Read Only", "Read and Insert", "Limited Admin", "Admin", "Super Admin", that sort of thing.

    The only WTF is that no single part of the code checked for permissions above "Read/Write". Talked to the project lead about this and he said that that the reason this was was that if a user could be trusted with inserting data into the app (which is in a specific way tied to their user account), they should be trusted with the ability to nuke the database from orbit and lock everybody else out of the system...

    At least your WTF being "backwards" seemed to afford it a happy ending.



  • @RHuckster said:

    "I'm pretty sure it was in the spec." I pulled it out. "See? Here: 'Accounts shall be assigned to at least one group which will correspond to a set of permissions.'"...

    "I don't agree with that philosophy," She frowned. "Best practice is to make tasks and operations in this system as simple as possible for all users, not just admins. Just implement the page like I mocked it."

    And therein lies the issue. Implement the specs you're given, not the philosophy you've decided.

    Bloody ignorant developers, thinking they know better, etc.@RHuckster said:

    including a tirade saying logging someone out after 30 minutes of inactivity was what caused her to cancel her bank account and thus we shouldn't even think about doing the same thing here

    Missed a great opportunity to tell her that for bet practise her bank account should be accessible to ALL people, not just her.

     



  • @MiffTheFox said:

    if a user could be trusted with inserting data into the app (which is in a specific way tied to their user account), they should be trusted with the ability to nuke the database from orbit and lock everybody else out of the system...
     

    What project lead confuses an INSERT operation with a DELETE?



  • @RHuckster said:

    she was reassigned to do other tasks, such as writing end-user documentation.
    all those users are going to be calling tech support asking why they can't create new accounts like the documentation says they can.



  • @Cassidy said:

    What project lead confuses an INSERT operation with a DELETE?

    It's all in the UI, so it's along the same lines of Items -> Add vs Admin -> Data -> Delete Everything. The only thing keeping a rouge user from firing up a copy of SSMS and pointing it to the databse server is... nothing tightly controlling the deployment.



  • @RHuckster said:

    After a few more instances similar to this followed (including a tirade saying logging someone out after 30 minutes of inactivity was what caused her to cancel her bank account and thus we shouldn't even think about doing the same thing here), she was reassigned to do other tasks, such as writing end-user documentation.

    Moral of the story: don't hire blakeyrat's sister.



  • It sounds like they didn't even want security, and the development team tried to force it on them. That's a WTF. Security is just one more feature... despite the fact that developers with a Barney Fife complex think it's cool.



  • @Cassidy said:

    Missed a great opportunity to tell her that for bet practise her bank account should be accessible to ALL people, not just her.

    I wasn't there for that tirade, but from what I gathered, it was quite a spectacle to watch. I'm sure someone eventually at least uttered those words under their breath during the heated discussion.



  • @RHuckster said:

    "Well, it's bad UI design to limit one's functionality. What if they wanted to create a new account?

     

    To be fair, I can see how it might be a good idea to show the option, but also show it as being disabled. That way, the person knows the option is there, specifically that they don't have access to it, and if they need to do that thing they should escalate their task to someone who might have the permission.

    I hate it when I search for ages looking for an option I know should exist, and then it turns out I just don't have permission to use that option so I can't even see it.

     



  • @bridget99 said:

    It sounds like the designer didn't even want security, and the development team tried to force it on her.
     

    There, fixed it for you. After that, the development team escalated the problem to the client, that confirmed thathe can't live without the security features.



  • @MiffTheFox said:

    It's all in the UI, so it's along the same lines of Items -> Add vs Admin -> Data -> Delete Everything. The
     

    Oh, okay. I read your "insert" literally, rather than interpert as "change access".

    Surely there would be some safeguards against making an utter fuckup, like being able to delete only one row through the interface at any one time...?



  • @Tacroy said:

    I hate it when I search for ages looking for an option I know should exist, and then it turns out I just don't have permission to use that option so I can't even see it.
     

    I favour that approach, actually. If I don't have permissions to do such stuff then it shouldn't be shown to me. Don't dangle a carrot.



  • @Cassidy said:

    Surely there would be some safeguards against making an utter fuckup, like being able to delete only one row through the interface at any one time...?

    Not if you have admin permission, though I'm going to see if I can get it taken out in a future version. Currently it's there just for a "we need to reset the test database from scratch" type situation.

    If you use the UI without admin permission, you can only delete one row at a time, deletes are logged (you're required to enter a delete reason), and rows become read-only after a certain amount of time.



  • @MiffTheFox said:

    deletes are logged (you're required to enter a delete reason), and rows become read-only after a certain amount of time.
    If there's an audit trail I'm less worried about bulk deletions.

    I'd still configure flashback, though. It's not I don't trust applications or users or anything...

     



  • @blakeyrat said:

    @Sutherlands said:
    Dang rouge developers.

    Obligatory rogue/rouge joke.

    If that's a rogue/rouge, is this a roguelike/rougelike?



  • ROUGE

    ROUGElike


  • And don't forget:

    ROUGElikelike


  • ROGUE 



  • I once played in a band that decided on the name "Rogue".  Which led to a constant barage of "Why is your band called Rouge?"



  • @RHuckster said:

    she was reassigned to do other tasks, such as writing end-user documentation.

     

    No wonder end-user documentation is often useless if only idiots are assigend to do it. I mean this not the first time I read this here.

     

     



  • @El_Heffe said:

    Which led to a constant barage of "Why is your band called Rouge?"
     

    "We dropped the Moulin bit when we realise people couldn't spell proper"



  • @El_Heffe said:

    I once played in a band that decided on the name "Rogue". Which led to a constant barage of "Why is your band called Rouge?"
    I remember a usenet newsgroup discussion (yes, that was back in the time when people actually still knew what usenet is) about a Star Wars themed game called "Rogue Squadron" - not hard to guess what most people wrote instead, and was kind of funny to imagine them talking about the adventures of a squad of drag queen X-Wing pilots...



  • Moulin Rouge

    Mulan Rogue



  • @MiffTheFox said:

    Moulin Rouge / Mulan Rogue

    Well played, sir.



  • @El_Heffe said:

    I once played in a band that decided on the name "Rogue". Which led to a constant barage of "Why is your band called Rouge?"

    Lies.

    Nobody makes that mistake the other way around.

    EDIT: Unless you mean they were trying to ask "why is your band called Rogue?" but typoed the word "rogue" as "rouge", then it makes sense, but is also a boring story.



  • To be fair though most business users, if given the opportunity, will want EVERYTHING completely customizable and want infinite permissions.  I had the misfortune of working in a company that had to implement their own pseudo-Active Directory security detail in the database to lock down anything and everything down to individual UI widgets on a page (e.g. users with Permission A can't see this text box at all, Permission B can view but not edit, Permission C can edit).  It was flat out ridiculous; I think the page to manage all of it had some 100+ checkboxes.


  • Winner of the 2016 Presidential Election

    @ObiWayneKenobi said:

    To be fair though most business users, if given the opportunity, will want EVERYTHING completely customizable and want infinite permissions.  I had the misfortune of working in a company that had to implement their own pseudo-Active Directory security detail in the database to lock down anything and everything down to individual UI widgets on a page (e.g. users with Permission A can't see this text box at all, Permission B can view but not edit, Permission C can edit).  It was flat out ridiculous; I think the page to manage all of it had some 100+ checkboxes.

    This is why it's important that scope be defined as a function of constraints such as schedule and resources. With infinite time and resources, your scope is infinite; and with infinite scope, you'll need infinite time and resources.



  • @joe.edwards said:

    This is why it's important that scope be defined as a function of constraints such as schedule and resources. With infinite time and resources, your scope is infinite; and with infinite scope, you'll need infinite time and resources.
     

    This company operated on "The boss decides the scope, and constantly changes it, and we just do what we're told because he's the boss".  Of course this was also a company that [b]forbade the dev team from talking to the users[/b] and the boss outright said that the users don't know anything, management knows best and go and revamp a critical page in the application because he thought it would "look better", despite a long list of user complaints that was preventing them doing their jobs efficiently.

     



  • @blakeyrat said:

    @El_Heffe said:
    I once played in a band that decided on the name "Rogue". Which led to a constant barage of "Why is your band called Rouge?"

    Lies.

    Nobody makes that mistake the other way around.

    EDIT: Unless you mean they were trying to ask "why is your band called Rogue?" but typoed the word "rogue" as "rouge", then it makes sense, but is also a boring story.

    No, there was no "typo".  These were people who were speaking.  And yes, it's a boring story, but it's true and I wasn't aware that being interesting was a requriement.

     



  • @ObiWayneKenobi said:

    To be fair though most business users, if given the opportunity, will want EVERYTHING completely customizable and want infinite permissions.  I had the misfortune of working in a company that had to implement their own pseudo-Active Directory security detail in the database to lock down anything and everything down to individual UI widgets on a page (e.g. users with Permission A can't see this text box at all, Permission B can view but not edit, Permission C can edit).  It was flat out ridiculous; I think the page to manage all of it had some 100+ checkboxes.

    Yes, and sad to say this was admittedly one of those systems. It wasn't quite as bad as 100+ checkboxes, but there were, IMO, too many checkboxes. And the logic behind those checkboxes were a pain, where certain permissions were prerequisites for other permissions (i.e. write access could only be granted if they had read access; that was the simplest and most straight-forward, of course, some of the other logic wasn't quite as simple to follow as that). Her complaint wasn't about that, though, it was about the fact that we even had permissions at all.



  • @RHuckster said:

    Her complaint wasn't about that, though, it was about the fact that we even had permissions at all.

    I've met a few people with that mindset. Strangely, they all locked their front doors.


  • Discourse touched me in a no-no place

    @ObiWayneKenobi said:

    This company operated on "The boss decides the scope, and constantly changes it, and we just do what we're told because he's the boss".  Of course this was also a company that forbade the dev team from talking to the users and the boss outright said that the users don't know anything, management knows best and go and revamp a critical page in the application because he thought it would "look better", despite a long list of user complaints that was preventing them doing their jobs efficiently.
    I've seen that occasionally. It's an indication that the boss is dangerously incompetent and suspects that people aren't giving him/her the respect that he/she believes they are entitled to. They're usually especially worried that they might be made to look foolish to their own boss, and so spend most of their time working to ensure that nobody anywhere is ever able to reveal the true depth of the incompetence. Curiously, if they stopped that and let people actually get on with their jobs properly, they'd be a better boss; their insecurity is powering their incompetence. The best we can usually hope for is for the business to go bankrupt because of the density of WTF power, but that doesn't happen as often as it should (whether "too big to fail", too small a component of the overall business to matter, or too many people ignoring the boss's restrictions in order to get things done).

    To be clear, I've seen it with male bosses — though never my own line manager, thankfully — and heard of it with female bosses too. This form of incompetence is definitely no respecter of gender boundaries.



  • @ObiWayneKenobi said:

    This company operated on "The boss decides the scope, and constantly changes it, and we just do what we're told because he's the boss". 
     

    That therefore means he's accountable for every failure, since he's the only one making the decisions and you're just following orders.



  • @Cassidy said:

    @ObiWayneKenobi said:

    This company operated on "The boss decides the scope, and constantly changes it, and we just do what we're told because he's the boss". 
     

    That therefore means he's accountable for every failure, since he's the only one making the decisions and you're just following orders.


    HAHAHA... oh wait, you're serious? Let me laugh harder...



  • @ObiWayneKenobi said:

    To be fair though most business users, if given the opportunity, will want EVERYTHING completely customizable and want infinite permissions.  I had the misfortune of working in a company that had to implement their own pseudo-Active Directory security detail in the database to lock down anything and everything down to individual UI widgets on a page (e.g. users with Permission A can't see this text box at all, Permission B can view but not edit, Permission C can edit).  It was flat out ridiculous; I think the page to manage all of it had some 100+ checkboxes.

    <elided>? They did that. No, I'm not afraid to use their name. Come sue me. I dare you, <elided>. Have your State of New York tax records handy.






  • @havokk said:

    @RHuckster said:
    Her complaint wasn't about that, though, it was about the fact that we even had permissions at all.

    I've met a few people with that mindset. Strangely, they all locked their front doors.

    Perhaps, but you could probably have stolen their garden hose if you really had to. The problem is that some programmers won't admit they've been tasked with making the software equivalent of a garden hose, not the software equivalent of a four-bedroom house.



  • @bridget99 said:

    Perhaps, but you could probably have stolen their garden hose if you really had to. The problem is that some programmers won't admit they've been tasked with making the software equivalent of a garden hose, not the software equivalent of a four-bedroom house.

    I see what you did there. You sexist asshole.



  • Security is just one more feature

    No No NO!

    Security needs to be designed in from the ground up, not just addded as an after thought.

    If the end user wants to give everyone full permisions there is nothing to stop them (& they can clean up their own mess afterwards)



  • @ip-guru said:

    Security is just one more feature

    No No NO!

    Security needs to be designed in from the ground up, not just addded as an after thought.

    If the end user wants to give everyone full permisions there is nothing to stop them (& they can clean up their own mess afterwards)


    Security can be added after-the-fact just as easily as storylines can be added after an RPG is finalized.

    All you have to do is make your system in a non-idiotic way and have placeholder functions for permission checks and input sanitization that you fill in laterby version 7


  • Winner of the 2016 Presidential Election

    @Ben L. said:

    Security can be added after-the-fact just as easily as storylines can be added after an RPG is finalized.

    Oddly, your own example illustrates why this is a bad idea. An RPG should be driven by the storyline, it shouldn't be tacked on as an afterthought. In the same way, if security isn't considered at every point during development, you're likely to have more holes than you can shore up later.



  • Good job, you understand Ben L's sarcasm. You get a cookie.


  • Winner of the 2016 Presidential Election

    Yeah, that one slipped under my radar.

    To be fair, I see both happen far too often.



  • @boomzilla said:

    You sexist asshole.
     

    I can see a Richards variation of Godwins emerging at some point.

    @CodeNinja said:

    HAHAHA... oh wait, you're serious? Let me laugh harder...
     

    They're not biting today, are they?



  • @ip-guru said:

    Security is just one more feature

    No No NO!

    Security needs to be designed in from the ground up, not just addded as an after thought.

    If the end user wants to give everyone full permisions there is nothing to stop them (& they can clean up their own mess afterwards)


    Oh, OK. What if I'm building firmware for a CANbus-based vehicular control system... should the throttle body authenticate itself to the ECU? What if I'm writing a program to move data off of my TRS-80 over RS-232... do you really expect me to encrypt that? I'm sorry... I know people who succeed in the world of bloatware think like you. But my statement was not made out of ignorance. It was well-considered and based on a thorough understanding of the factors involved. For many programs, perhaps most programs, security is about as relevant as three-voice FM audio or crossover cable detection. IT IS JUST ONE MORE FEATURE.



  • @beau29 said:

    Oh, OK. What if I'm building firmware for a car? Should I really make sure that people can't just call a phone number and lock the car into accelerate mode? I know people who succeed in the world of bloatware think like you.

    FTFY

    @beau29 said:

    But my statement was not made out of ignorance.

    BAHAHAHAHAHAHAHAHAHAHAHAHA oh you were serious?


  • Discourse touched me in a no-no place

    @bridget99 said:

    [Security] IS JUST ONE MORE FEATURE.
    It's usually people's first proper exposure to a non-trivial global property. By that, I mean that security is one of those things that you only get when you don't make any mistakes (or at least no mistakes of a particular large class of blunders). Deadlock freedom is another one, but that usually only hits people when they really get into multithreaded programming. Global properties are awkward because they depend on the interaction of everything being right, and not just the little individual bits being right. Dealing with these things is easiest by far when you integrate it from the beginning of the project, and adding as an afterthought is hard because you've got to go through and look at how everything interacts with everything else.

    The other problem with a global property is that changing something somewhere else can have far-reaching consequences.
    Marketing: “Oh, let's put the car's ECU online so our licensed mechanics can address problems while the user is driving along! It will make a great feature as none of our competitors have done this!”



  • @dkf said:

    @bridget99 said:
    [Security] IS JUST ONE MORE FEATURE.
    It's usually people's first proper exposure to a non-trivial global property. By that, I mean that security is one of those things that you only get when you don't make any mistakes (or at least no mistakes of a particular large class of blunders). Deadlock freedom is another one, but that usually only hits people when they really get into multithreaded programming. Global properties are awkward because they depend on the interaction of everything being right, and not just the little individual bits being right. Dealing with these things is easiest by far when you integrate it from the beginning of the project, and adding as an afterthought is hard because you've got to go through and look at how everything interacts with everything else.

    The other problem with a global property is that changing something somewhere else can have far-reaching consequences.
    Marketing: “Oh, let's put the car's ECU online so our licensed mechanics can address problems while the user is driving along! It will make a great feature as none of our competitors have done this!”

    That's an interesting way of putting it. Maybe it's a pretty common way of analyzing things... as I've admitted, I'm a man of limited curiosity when it comes to Computer Science. I've got a fair amountof training and experience with it, I'm just not usually seeking out more of either (beyond the bare minimum necessary to survive in a quasi-middle-class fashion).


    Using your preferred terminology, I can tell you that I've avoided assignments and architectures that would have made me to deal with global properties. Many developers seem to want to attack them head-on.


Log in to reply
 

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