Welcome to Keen Software House Forums! Log in or Sign up to interact with the KSH community.
  1. You are currently browsing our forum as a guest. Create your own forum account to access all forum functionality.

Cost of bugfixing

Discussion in 'General' started by AtlantisThief, Feb 13, 2015.

Thread Status:
This last post in this thread was made more than 31 days old.
  1. AtlantisThief Apprentice Engineer

    Messages:
    300
    Hello everyone,
    I have to annoy with a similar type of thread which are going on, but I don't feel that my post would gain the attention I want to, nor that the responses there would actually hit I am hoping to recieve from you:

    I am currently a IT-Student and had last year some lectures about software development and risks and costs. One thing that actually burned into my mind has been: Fix bugs as early as possible, as they will cost you more the later you do. I was trying to regard most people comments that bug fixing will be done in beta state, but this is something that I couldn't get.

    Since SE is not following the standard procedure how I learned about software development, I could probably be wrong, but until now I have not found any sign of that beside comments in this forum.
    I refer to graphs that show up for me when I google images about "software development cost of bugs fix"
    [​IMG]
    This is one of those similar graphs that I could find on the search. For me it tells me, that longer we wait for a bug to be fixed, the more it costs. But I have to consider, that the actual process of "Coding, Unit Test, Function Test, etc..." is not giving by the current development type of this game.
    In the last half year, I had a project at my university where I had the chance to develop with 8 other students a small game using the Microsoft Kinect in Java (main language we have learned and used so far). Our development type was somewhat "agile", we had bi-weekly iterations that has been shown to the tutors, so our way is actually somewhat comparable to the development of SE (in a far larger and easier scale), but after finishing the project I would say our development had these "steps" for each iteration: "Collect Idea, Code the feature, debug it, repeat for next iteration". So to speak, as soon as one feature was complete and we found a bug, we killed it right away. We also had some changes to named features and yet, when we encountered a new bug, we fixed it right away. Later, in the last phase we had a so called "polish" phase, in which we increased performance and balanced the game a bit further to be more enjoyable.

    So what is this thread now about? I want to ask you, developers of SE aswell as hobby or working programmer, after what kind of "decision" you claim to push bug fixing later (in beta).
     
  2. soat7ch Junior Engineer

    Messages:
    605
    Developement speed.
    They don't want to risk falling out of the gamer's focus by not releasing new features.
     
  3. merak Apprentice Engineer

    Messages:
    149
    I am not a coder so this is not for me to answer.. but i will give you my idea anyway..


    lets state your example that you did with programming java
    "Collect Idea, Code the feature, debug it, repeat for next iteration".

    what if when you moved on to the next iteration you broke the first iteration or you broke a feature that you made 4 iterations ago? but doees not know it untill 5 iterations later and fixing this made something else brake?


    so adding all the stuf you want and the fixing and polishing would make sence as you dont ad more that can brake other stuff

    (Imho)
     
  4. AtlantisThief Apprentice Engineer

    Messages:
    300
    @merak: We had some bugs with features that has once been bug free in later iterations, but actually those bugs occured rather from an error in the code that combined those features/modules with each other. But I start to get the point, our stuff wasn't that complex, so such bugs that caused our first feature to be completly rewritten hasn't occured to us.
     
  5. Anathor Trainee Engineer

    Messages:
    9
    I think this graphic is for V-model than agile model.
    However, i'm too a student and we don't have enough experience in IT enterprise, we only have theory. Indeed sooner the bug is fixed bette rit is in theory, but in gaming devellopment, E&E test are commonly done by the player in alpha/beta phase so each report we do will be fixed in appropiate time.
    Moreover, like merak say most of the bug occur after the add of a functionality / ect, the time for fixed bug will be more efficient when all the functionality will be added.
     
  6. Valiance Apprentice Engineer

    Messages:
    217
    I think it should be noted that KSH uses two different engines to handle the game (Space Engineers); Keen's own built VRAGE, and Havok. It can make things extremely difficult when one engine can behave very differently to a change than the other. The Dev team made this clear to the community when they added procedural generation. There were complications expanding the world to what it is in it's near infinite state.

    If anyone was around before this was added, going beyond 10km from the starting zone; players experienced "vibrations". The further you went, the more noticeable & violent it became. From what I understand (correct me if I'm wrong), it had to do with how both engines calculated positioning.

    The point I'm trying to raise is that when they squish one major bug, it can cause a few other smaller ones just so it could function. The engines themselves don't account for all the issues, just an example. If it were as easy as "fixing them right away" I'm quite confident more of them would've been addressed already. Granted, some things could be looked at sooner, but some slip through the net and that's where the *it broke my game* part of the community (as i like to put it lol) comes in. They do take major issues seriously, but the gaming community at large is very inpatient and some problems take far longer than others to address unfortunately.

    The game is pretty young though. I'm always eager to see what happens next. I can say that i was around in the early days of Space Engineers, I wasn't for Minecraft. I wonder what it was like back then. :rolleyes:
     
    Last edited by a moderator: Feb 13, 2015
  7. mhalpern Senior Engineer

    Messages:
    2,117
    That chart is true for industrial/business software, the cost comes from the bugs causing equipment malfunction, and having to financially cover your ass and reinstall a new version of the software, in the game industry, it is cheaper to do it when all the features are ready and new features are less likely to break the fix, it is easier to modify code that hasn't been completely cleaned up yet, cause when you make any changes to it, you may cause a bit of a mess from time to time, these messes we call bugs, so once the majority of features are in, then cleaning it up makes sense
     
  8. AtlantisThief Apprentice Engineer

    Messages:
    300
    Thank you for your responses so far. I wasn't aware of that game and "industrila/buisness software" development would be so much different. So far I am pretty happy with these answers, thank you^^
     
  9. mega_newblar Trainee Engineer

    Messages:
    36
    What a nice conversation to follow! No yelling or whining or anything, just people sharing ideas and opinions

    @Variance,
    Also, wow. Had no idea this game uses 2 engines. I mean I guess I knew that keen had their own engine, AND I knew that they used Havok, but until you spelled it out for me I never really put it together. It makes so much sense now some of the errors they've been encountering... and it makes sense why they're taking so long to fix. I do not envy their job.
     
    Last edited by a moderator: Feb 13, 2015
  10. mhalpern Senior Engineer

    Messages:
    2,117
    Well they aren't very different, its just that the nature of the products are different, in most commercial/industrial/business software, the purpose is to help the user make an end product, in a game, the software IS the end product.
     
  11. Textor Junior Engineer

    Messages:
    775
    Here is an article on traditional software development costs vs. agile software development costs-- you'll see the graph looks very different for agile development models:

    http://www.agilemodeling.com/essays/costOfChange.htm

    One chart from the article:

    [​IMG]
     
    Last edited by a moderator: Feb 13, 2015
  12. TheQuixote Apprentice Engineer

    Messages:
    119
    I think this situation is probably a good example of how waiting to fix an issue might cost more money in the long run.

    Instead of fixing the issue early on they've continued to code workarounds to hide the underling problem. If they never go back and fix the underling issue, this might save money. If they discover they've reached a point where they can't avoid it fixing it, not only have they wasted a lot of time figuring out how to work around the problem, they've been coding to those workarounds and that will all need to all be rewritten as well.

    As for bugs, most of them are pretty benign and it's just a matter of x amount of time to find and fix them. But some uncover serious issues with design or performance that are best addressed early on. Leaving those around for long periods of time can be costly, especially if fixing requires a design change that effects a lot of other code that has been written since the bug was introduced.

    I've always been of the mind to fix as you go, and if you discover underling design problems or flaws, take the time to change it. Management, budget, and time constraints almost always dictate a quick and sloppy workarounds, mostly because they don't understand the serious issues that this approach creates with maintaining stable code over the long run.
     
  13. MegaMiner Junior Engineer

    Messages:
    625
    I'm calling bullshit on that graph, unit testing isn't a 'phase' its part of the coding process. And those graph lines look really suspiciously drawn.

    As for the workaround fix it later issue, I agree, I've had projects fail because management couldn't grasp the concept. Unfortunately it's a difficult sell when management has already cashed and spent the development budget and is borrowing agaisnt future sales. They think the problem is fixed because there is a workaround.
     
    Last edited by a moderator: Feb 14, 2015
  14. TheQuixote Apprentice Engineer

    Messages:
    119
    @textor
    I can't stop laughing at "Requirements defect found via traditional testing"

    Projects I tend to work on, that's half the budget right there. One of the points of Agile type development is to alleviate that, get the stakeholder involved early on and to get accurate requirements early on.
     
  15. a2457 Senior Engineer

    Messages:
    1,366
    testing the code for bugs costs money and time.
    back in the GOOD days development focused on releasing stuff only, that was tested properly.
    yet it still had some bugs.
    nowdays, the budget for testing is minimasied.
    automatic info collection on software crash via internet is getting pretty standard.

    i would say today, that the cost of finding a bug and fixing it is cheapest after release.
    as you do not have to search for the bug, it will be reported by the users.
    if no more features are to be added to a software, and a bug is identified, a fix is less costly.
    as no new features are to be added, it is less likely it will break again.

    so today, buggy/unoptimised/broken software is released, then you get the O-day patch and so on.
    that is the cheapest in my opinion.
    and i do not like this.
     
  16. SenorZorros Master Engineer

    Messages:
    7,063
    a2457, (death to the quote trees)

    you might be forgetting possible negative publicity as well as the possibility that people end up waiting a couple months until the bugs are fixed and the price has dropped.
     
    Last edited by a moderator: Feb 15, 2015
  17. Me 10 Jin Apprentice Engineer

    Messages:
    463
    You're lucky; for some of us in the software development business, UAT is no laughing matter.


    @ AtlantisThief: are you going to school in India by chance?
     
  18. a2457 Senior Engineer

    Messages:
    1,366
    good point, but PNP solved it:
    "we listen to our customers" and fix bugs/add features accordingly.
    in fact, lately alfa/beta whatever releases of sotware comes with a huge amount of bugs,more than sub-optimal performance, and -1 day patches. endless amount of patches. it is so common that it is soon going to be considered the normal.
    and full oop is the devil begind it, enabling fast response to urgent bugs.
    (did i mention i absolutely hate full oop ? it has its place, where needed. other than that it is the devil)
     
  19. Textor Junior Engineer

    Messages:
    775
    Uh... I'm not seeing the issue here. You're saying that fast response to urgent bugs is a bad thing?
     
  20. TheQuixote Apprentice Engineer

    Messages:
    119
    I think the argument is OOP allows management to get away with not testing. Which isn't a problem with OOP, but a problem with how it's being used.
     
    Last edited by a moderator: Feb 15, 2015
Thread Status:
This last post in this thread was made more than 31 days old.