Software problems that really ought to be solved by now


  • I survived the hour long Uno hand

    Continuing the discussion from Nice wiki with templating?:

    @mott555 said:

    I hate to say it, but the wiki world is awful right now.

    It is 2015. Wikipedia has been around for 14 years. Why do wikis all suck?

    See also: Bug tracking. Everyone who writes software has to track bugs somewhere, and yet every major bug tracker has huge problems. WTF?

    Oh! Also! Test management. I have tests in word documents. I want to track manual and automated execution. I don't want to convert my existing automated scripts into some proprietary language. I'm SOL.



  • My take is it has to do with near-monopolies. MediaWiki is the largest, most-visible wiki engine right now. They don't have any real competition, so they don't have any need to improve themselves. A lot of people are using it, and apparently that's good enough for them. (Not to mention the Open Source issue...) I have no idea why nobody has managed to dethrone them yet, either nobody has tried or the Wikipedia brand is too strong to overcome.

    I've seen it in the for-profit software industry, especially in niche markets. Someone gets a product that kind of works, but they have 90%+ marketshare and use their money and power to squash competitors rather than improve their own products.


  • I survived the hour long Uno hand

    @mott555 said:

    MediaWiki

    Honestly, I think most fan groups have moved off of hosted Mediawikis and into Wikia. It's easier for smaller groups



  • Isn't Wikia just a hosting provider for MediaWiki instances?

    MediaWiki is the name of the software.


  • I survived the hour long Uno hand

    My bad, I thought Wikia had its own custom wiki software. Now I wonder who I was thinking of that offered cheap hosting of wikis and had their own WTF-worthy wiki software... probably someone Wikia drove out of business.



  • My big complaint in this category: line endings in text files.

    Both CRLF and LF are around to stay. Why do so many tools not work with both?! (Mostly this is an indictment of a number of Unixy utilities; Notepad excluded, Windows programs in my experience almost always deal correctly with both.)

    Edit: Also: not having to configure backspace/delete over SSH. (It usually works, but not always, which is pretty ridiculous.)



  • Paste an emoticon or “smart quotes” into a (usually Windows) text editor? Save the file going "eh, it'll be fine, UTF-8 will just work..."?

    You just dropped the BOM.
    #💣

    <!-- ,  everywhere! -->


  • @EvanED said:

    Both CRLF and LF are around to stay. Why do so many tools not work with both?! (Mostly this is an indictment of a number of Unixy utilities; Notepad excluded, Windows programs in my experience almost always deal correctly with both.)

    And then there's the very special category of software that accepts both, but uses one in it's output. So you end up with files that have a mix between CRLF and LF line endings. Which is total bollocks.


  • BINNED

    So... ummm...

    http://what.thedailywtf.com/t/its-2014-this-it-problem-should-be-solved-by-now/709

    Then again, the year is wrong...

    NOTE: I wrote this hours ago. Discourse never posted it. Yay.



  • @Onyx said:

    NOTE: I wrote this hours ago. Discourse never posted it. Yay.

    Discourse was acting up a few hours ago.


    Filed under: Nothing specific, but it's safe to assume that at any point in time, Discourse is acting up



  • @cvi said:

    you end up with files that have a mix between CRLF and LF line endings. Which is total bollocks.

    I just cleaned up a few hundred files like that. Some "developers" don't know how to configure their text editors. Luckily a sed script removing all ^Ms from the text files was easy to do. And setting props in svn so it can't happen again.


  • sockdevs

    @Yamikuronue said:

    Software problems that really ought to be solved by now

    IPv4

    amirite? why is that still a think when we already have more than 2 billion networked computers in the world and we're rapidly coming up on having 2 bilion that want to be directly addressible over the itnernet...



  • We've had a software solution to that since 1998. It's been solved in firmware since ... whenever DOCSIS 3 came out.

    We need to break out the torches and pitchforks on our ISPs. If not for saying "We're totally competitive, honest! *snirk*", and not for defining Ben Lubar's connection as "acceptable broadband", at least we should sack them for this.


  • sockdevs

    hear hear!

    /me starts forging new pitchforks out of scrap iron


  • I survived the hour long Uno hand

    @TwelveBaud said:

    defining Ben Lubar's connection as "acceptable broadband"



  • They actually followed through and did that? Awesome!


    Filed under: we need a new tag cloud to attack, WHERE'S MAH ONEBOX?


  • I survived the hour long Uno hand

    I don't see the point, I mean, 4 down is plenty to send 640k, much more than that and you fill up your ram right quick.

    <!--- #sarcasm --->


  • @Yamikuronue said:

    FCC Votes To Make 25 Mbps The New Minimum Definition Of Broadband

    So what would @ben_lubar's connection be called (besides [vulgar word for excrement])? It's not dialup, and it's faster than dialup (though not by much), but it's not broadband. How do ISPs market that class of service? (Yes, I know, in 2015 they shouldn't.)


  • sockdevs

    @HardwareGeek said:

    How do ISPs market that class of service?

    i believe it's typically called DSL?



  • @accalia said:

    DSL

    Is that what he has? Back in the days when I had DSL, it was faster than that, IIRC. How far is he from the telco CO?



  • Waay too many things to list.

    I have considered making a "if you had to redesign computers (hardware and software), how would you do it?" thread, but never got around to it.



  • Another problem that should be solved by now: Text encoding.

    Someone committed a .cpp file to the repo that was somehow in a weird encoding. It looked perfectly normal in every single text editor I opened it with, but g++ would barf over it, and the error messages had nonsense function names and such. The solution was to open it in various text editors, save, try again, repeat until it worked. Eventually I must have found a text editor that fixed the encoding on save.


  • BINNED

    @Yamikuronue said:

    Bug tracking. Everyone who writes software has to track bugs somewhere, and yet every major bug tracker has huge problems. WTF?

    I've been thinking about this, and I reckon it might be worth thinking about as my next side project. What do you see as the main problems in current bug trackers? What would be a killer feature in a new one?



  • @Jaloopa said:

    I've been thinking about this, and I reckon it might be worth thinking about as my next side project. What do you see as the main problems in current bug trackers? What would be a killer feature in a new one?

    Sub'd for response. (Oh wait...)

    The two major bugtrackers I've used are BugTracker.NET and Redmine. Both are decent in features, Bugtracker is easy to deploy and Redmine has a lot more features. But Redmine is Ruby on Rails and you will grow a lot of gray hair trying to get it properly installed and configured.


  • I survived the hour long Uno hand

    I had to write up a requirements document recently, looking at defect tracking from a project management/SQA lens. Basically, I want to be able to track metrics across the whole SDLC. This means I have three kinds of users:

    1. Analysts, who create documents; a defect in a document is either an inconsistency or a ambiguity
    2. Developers, who create code; a defect in code is either an omission or a error
    3. Testers, who create tests; a defect in a test is likewise either an omission or an error

    That gave us the following major features:

    The system will need to capture the following information about each defect:
    1.	Type of defect
        o	Ambiguity – lack of clarity around desired functionality
        o	Inconsistency – contradiction between two or more artifacts or portions of an artifact
        o	Omission – functionality needed for successful execution, but not specified
        o	Error – functionality that is specified, but was not implemented correctly
    2.	Description of defect
    3.	Artifact in which the defect was discovered
    4.	Phase of the project in which the defect was discovered
    5.	Severity of the defect
    6.	Status of the defect
    7.	The person who is assigned to resolve the defect
    8.	For code errors:
        o	Steps to repeat
        o	Environment discovered in
        o	Screenshots or other visual artifacts 
    
    The system will provide a means to analyze by type, project phase, artifact, and environment the number of defects discovered for a given project. The analysis shall be structured in a way that facilitates monitoring for purposes of process improvement.  
    
    The system shall have a means to manage the data for any element representing a controlled list of options.
    
    The system shall allow for customization of the options for each of the above items to track for a defect. The system shall allow us to define the bounds of what is allowed in each field, and also to add or remove from it at any point. 
    

    Add to that a nice reporting output so I can see what areas we're not carrying out well and voila.


  • area_deu

    @accalia said:

    i believe it's typically called DSL?

    My ISP calls 2-16Mbit/s DSL and 25-50Mbit/s VDSL.


  • BINNED

    @aliceif said:

    VDSL

    Voluminous Digital Subscriber Line?



  • @aliceif said:

    VDSL

    Very DSL?


  • area_deu

    And before the pedants arrive, DSL is a technical term that basically means "digital data over telephone line".


  • Discourse touched me in a no-no place

    @mott555 said:

    Eventually I must have found a text editor that fixed the encoding on save.

    Notepad's save dialog supports several common encodings, including ASCII and UTF-8.



  • @TwelveBaud said:

    They actually followed through and did that? Awesome!

    Not really.

    See, the Verizon's and Comcast's of the world get funding for providing "Broadband" to new users. This is supposed to provide access to underserved rural and low income areas.

    Instead, ever few years we redefine what "Broadband" means, and they get the same tax breaks by upgrading the same rich, densely populated areas again.



  • @Yamikuronue said:

    5. Severity of the defect wtf discourse? I typed a 5 there!

    I think this is one major failing of many bug tracking systems - they only offer one axis here, where I believe there are at least three, possibly more. Instead of using names for them, which would be spark debate and end up being an ambiguity defect of this post :wink:, I'll just define the three axes I believe exist:

    1. When the defect is encountered, how bad is it?
    2. How commonly is the defect encountered?
    3. How important is it that we fix the defect?

    The first two feed the third - a defect that destroys the planet but occurs only once every trillion years is not very important to fix, whereas a defect that is mildly annoying but happens upon every keystroke is very important to fix. Some might argue that the third should simply be calculated from the first two, but I challenge any organization to come up with a formula that works every time. The best you can do, I think, is to calculate an initial guess at that value.

    Another problem of many bug tracking systems is that they don't provide tools for authors, developers, and testers to manage their workflow. So they need additional information such as

    • Resolver importance relative to other tasks
    • Resolver working status
      (queued, working, waiting for response from reporter, etc)
    • Resolution notes (includes discussion back and forth between resolver and reporter)
    • Probably much, much more

    For complete lifecycle tracking, it also needs information about the version or versions in which the fix appears.

    Finally, all multi-line text fields must allow marked-up text and pasting of images and movies for screenshots and reproduction steps. The system I'm using now has a repeating Description section that produces one section for each time someone adds information, which is really nice for tracking who said what and when, but it only allows plain text. To put in screenshots and the like, you have to put them all in one large Attachments section, which is utter rubbish.


  • sockdevs

    @aliceif said:

    DSL is a technical term that basically means "digital data over telephone line"

    tell that to marketing!

    :laughing:



  • @RobFreundlich said:

    When the defect is encountered, how bad is it?
    How commonly is the defect encountered?
    How important is it that we fix the defect?

    This may be Doing It Wrong™ but this is always important in our shop:

    How difficult is it to fix the defect?



  • @ijij said:

    This may be Doing It Wrong™ but this is always important in our shop:

    How difficult is it to fix the defect?

    I would say that is doing it right. An important bug that requires a huge restructuring to fix is very different from a slew of minor bugs that each take 10 minutes when it comes to scheduling work.



  • @ijij said:

    How difficult is it to fix the defect?

    99.9% of the time that's "unknown". In cases where it is known, typically, the bug fix goes in faster than the ticket describing it.

    I like these ideas, but I think the biggest obstacle to bug tracking is getting people to actually use the damned thing. (I mean really use, every day, not just at the end of the sprint to close things out.) Which means you need to make the process simpler, which is generally against the trend in the last few posts of adding more fields and more information to the form.

    EDIT: another possibility is to scrap the web interfaces and build a really nice GUI app that users could enter bug-related information in with fewer context switches and less waiting for web servers in Idaho to load. TFS has one, but theirs has a really shitty UI-- you can do a million times better.


  • I survived the hour long Uno hand

    Yeah. The problem I have is we have very simple tracking, and people eschew it in favor of emails, which are even simpler... but provide 0 visibilty for process improvement purposes. I want to know what's going on so I can advise how to prevent it, but we can't get there. Definitely the UI would have to be very clever to balance between usability and information capturing.


  • BINNED

    @blakeyrat said:

    another possibility is to scrap the web interfaces and build a really nice GUI app that users could enter bug-related information in with fewer context switches and less waiting for web servers in Idaho to load. TFS has one, but theirs has a really shitty UI-- you can do a million times better.

    Since I'm not too keen on/experienced in web dev, any project I did would be GUI based rather than web. With the right API it shouldn't be too hard to expand to a web version later.

    @Yamikuronue said:

    people eschew it in favor of emails

    This is why the bug tracker problem got my attention. At my job, everything is done through email and lots falls through the cracks. There is an issue tracker but it's horrible and ancient so people avoid it whenever possible



  • @ijij said:

    This may be Doing It Wrong™ but this is always important in our shop:

    How difficult is it to fix the defect?

    Using Fermi estimation, at that!



  • @chubertdev said:

    Using Fermi estimation, at that!

    Unfortunately Pauli is more applicable....

    "If we fix that we can't fix that."


    No, not Pauly.

    That would be "Hey, Pauly! Get dis guy! He sez der's a bug in our software. He wansus to fix it. Pauly, we ain't got no bugz in our software? Doz we?"
    "Eh,no boss. We ain't got no bugz" :facepunch:


    Also, thanks to whoever brought up Pauli yesterday.
    Fortunately, two posts can both reference Pauli...



  • I ain't no Mona Lisa Vito with bugs here...



  • @locallunatic said:

    I would say that is doing it right. An important bug that requires a huge restructuring to fix is very different from a slew of minor bugs that each take 10 minutes when it comes to scheduling work.

    I agree. I knew I was leaving something out!



  • @blakeyrat said:

    and less waiting for web servers in Idaho to load.

    Just make sure it's not built in .NET and not served by IIS, and you should be fine


  • Discourse touched me in a no-no place

    @cdosrun1 said:

    Instead, ever few years we redefine what "Broadband" means, and they get the same tax breaks by upgrading the same rich, densely populated areas again.

    It also means the rest of the world gets to tsk about how the US is behind in broadband coverage.


  • Discourse touched me in a no-no place

    @blakeyrat said:

    another possibility is to scrap the web interfaces

    Crazy talk! Everything must be a web app no matter how complex it is!



  • @TimeBandit said:

    Just make sure it's not built in .NET and not served by IIS, and you should be fine

    Not sure if trolling.........oh wait, totally sure.



  • @accalia said:

    IPv4

    This is a problem long solved, even if we have "run out " of IPv4 addresses.


  • sockdevs

    yes. the solution is IPv6.

    no NAT does not work if you want more than ~2 billion unique globally addressable computers. ;-)


  • BINNED

    @loopback0 said:

    This is a problem long solved, even if we have "run out " of IPv4 addresses.

    If you mean IPv6, yes.
    If you mean using NAT, I invite you to ping my router if you can, I'll provide the IP.

    Note to self: send the public dynamic IP request form on Monday.



  • @accalia said:

    more than ~2 billion unique globally addressable computers

    Those computers can get the fuck off my lawn.

    :do not want:


Log in to reply
 

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