Ah Pook wrote on Jul 28
th, 2015 at 11:15pm:
No, just worked on codebases larger than somebody's Crucible macro.
In any modern system, bugs are generally assigned to either a person or a group whose job it is to do the next step until it's resolved. When they're entered, they'll either be unassigned completely or set to somebody by default, but that's very rarely a developer in practice, and I'd be shocked if Turbine did that.
What that means is it's perfectly possible (and plausible) that Varg has a bunch of bugs assigned to him, but doesn't go looking at new shit, so until somebody says "hey, you can equip epic stuff by dragging it from the bank," he has no idea about it.
That's shitty bug wrangling, but that part wouldn't surprise me at all.
Honest question: how do you think they keep track of bugs?
TL : DRI think bug tracking is haphazard as evidenced by their approach in general. There are a number of clear indicators that bug tracking is not taken seriously (bugged online tool).I'm not a coder, but I used to look after several financial systems where the error tolerance was far less than DDO and my team was smaller than Turdbines. It was old, it was imperfect and I inherited it. Similar situation to the current dev team.
We had two environments - "production" and "test" for sandboxing.
Production changes had to be packaged and had limited time windows for updates. Test was available to us to make any changes and even had version history so we could select what version we wanted to Sandbox in.
All bugs reported came to a central DB. Bugs that weren't reported by users, but found by the team, were also added.
That list was characterised in a number of ways to identify risk - business impact (critical/urgent/moderate/low from memory), fix complexity/time (estimates or 0 for unknown), timing (for less urgent fixes, but ones that should be in the next prodn update), bug/error type, who reported, assigned to, linked to (other bugs), and a few other administrative ones.
This could drop out a priority list in any number of ways. Only had a small team with defined roles, so assignment wasn't such an issue.
But identifying, fixing and testing was important.
If a bug fix went into production and broke something else, there was always an investigation of the process of fixing and testing. If it was found that the process wasn't followed or not thorough enough, it was my head on a platter. Some fixes requires stress testing, and I would call in other super-users/users to help stress test the system in a test environment when required.
Why am I so hard on Turdbine?
Because they have fracking Lammania and don't use it to its potential.
Excuse 1 - Lamm code is different. Well fracking make the base code the same, except for the Lammania specific elements which should be in a separate module.
Excuse 2 - it's a preview server, not a test server so it is too late in development to make substantive changes. BS - what's the point of testing if you're aren't going to fix it?
There is no excuse why Turdbine should be pumping out the shit they do to Live, other than a lack of professionalism and lack of consequences.
No-one expects perfection, although if the bank loses your life savings to an "unfortunate bug", I think those Turdbine forums paladins might care a little bit.
This game has a loyal fan base more than willing to ensure the product's future and they don't use them or listen to them.
Having consequences really does change your view on what is acceptable to pass onto your customers. "It's just a game" doesn't cut it with me, since I pay for it.
To address your question: I don't think they track bugs other than in a haphazard fashion. I'm sure that there used to be a bug tracking system, but it was "someone else's" and has fallen into neglect.
Why do I think this:
1. The online bug reporting tool doesn't work. Why the frack not? how fracking hard can it be? If you cared for one moment about the quality of your product and addressing bugs, you would fix this. If anything, it just looks amateurish that your product's bug reporting tool is bugged. A convenient excuse to minimise bug reports that you have to read?
2. They rely on people going online to report bugs. Path of least resistance - good chance a very large proportion don't bother. If the online tool worked, you could capture much more information about instance/loc/server load etc while making it painless for the customer to type in their problem. Also, many times I've seen people complain on the forums about a bug that dozens reported and it never made it onto the official list. What is the criteria for the "official list"?
3. When they do fix bugs, they forget to mention it in the release notes sometimes. If they were serious about bugs, there would be more transparency and reporting. If they were fixing bugs and tracking them, they could easily roll out a list to quell the "whiners". Never seen it done.
4. Bugs are being fixed, but it is completely haphazard. eg. the Cannith Crafting Crude Vial fix. WTF? That trick has been around for years in a now dead crafting system and someone decided to fix that ahead of I dunno... anything else?? There is no logic to what bugs are fixed and when. Lots of small shit gets done, whilst much worse bugs that really piss players/customers off are left. This to me is a clear indication of a haphazard system where devs pick the low hanging fruit to fix to meet some arbitrary KPI.
5. Bugs re-appear over and over again. Poor code version control. There is no history of what a bug was, the cause and why & how it was fixed. If there is a structured system to bugs, then team turnover has less effect as the history is recorded and accessible rather than in someone's head.
6. The lack of professionalism displayed in the code itself. "I don't know what this does, but don't touch it!" We've discussed this previously and some think this is ok, but I believe your product is a representation of your approach. A sloppy code base, permits future sloppy work.
7. The timing of fixes. They know about features not working properly and yet they leave them for so long that players think they WAI. They then cries of nerf! The longer you leave it, the more people will build around it - thus affecting more of your customers adversely. If you don't like how something is working in the first few days/weeks, then fix it fast and explain it to the customers. Most will understand, some will not. That's life. Communication is there other great failing - they never explain anything, so people fill in the missing detail with the worst case scenario. And then Cordo mocks them for being tin foil hatters. Dickhead move.
Take Holy Sword for example, we know that they realise it is overpowered and plan to nerf it. Why haven't they? Why wait? Hoping to leave it to the next chair warmer (producer)?
If you alert players that something isn't working as you expected and we plan to make changes after some testing, then anyone who builds around that only has themselves to blame.
8. The manner of bug/exploit fixes. Look at the hamfisted way in which they try to address bugs. They don't fix the root cause, they apply an interface restriction or some other stupid mechanism that just ruins the immersion for 100% of customers to stop 5% who are exploiting. Many here on the vault would know a damn side more about the weaknesses in the system than the devs, because they keep finding exploits using the same methods. Yet the devs keep creating content with the same weaknesses - where is the learning cycle evident in anything Turdbine have done?
I could go on, but I'm out of time.
You outline the system they might use - who assigned, how it progresses and the bureaucratic risks of information flows in larger orgns. How big do you think the DDO team is? I don't think there is the role diversity that you believe.
Last count, it has 4 developers and 1 system engineer left + some other support types. Who do you think does the bug identification?
I think a Dev is primary bug identifier and the best placed to do root cause analysis. If it leads back into the code, then you involve the systems engineer. Depending on their backgrounds, the devs should be more than capable to investigate and fix some bugs.
In a team of 5-8 people in the same location, communication is not that hard, nor is a bug tracking tool. You could do it in a spreadsheet on a shared drive if you put a few hours into it.
The problem with assignation in DDO is how do you do it? Who do you assign to fix a Cannith Crafting bug when no-one know anything about it or wants to touch it? Their own stuff probably gets fixed first and old "shit" gets left to rot unless it is an exploit.
Summary: I reckon it's a complete mess.
Pages: 
U27 Release Notes (Read 18750 times)
