Bounty Hunter Archive
Thread: Who we have to thank for 15k jedi missions
I
While you're correct that Sony is large enough that they could hvae pushed back the release date of this game without it adversely effecting their bottom line, what it appears to me you may be failing to see is that the marketing guru's didn't feel this was a viable solution. I imagine the conversation went something like this:
While you're correct that Sony is large enough that they could hvae pushed back the release date of this game without it adversely effecting their bottom line, what it appears to me you may be failing to see is that the marketing guru's didn't feel this was a viable solution. I imagine the conversation went something like this:
I see all to well that this is often the case. It is not a matter of getting more time, as you have pointed out this is often not even a possibility. However, there is a matter or prioritization. When a deadline is approaching it is often necassary to cut certian features to ensure that others receive the attention needed to assure that they are released relatively bugfree. I would be the first to agree that theyrelease the productwether or not they feltconfident in its preformance.
However, when time approaches it is necassary to make the hard decicion of what to cut and what to include to ensure a working product. Having seen the release I would not hesitate to say that this was not done properly. Nothing alinatescustomers worse than hundreds of buggy, non-working features.
However, the initial release aside it still leaves the matter ofpatches. Recently we have seen the release of two new major projects, the Death Watch Bunker and the Corvette. Development on these projects whenbugs exist within the game is inexcusable.
I realize that often the developementteam is a seperate animal from those who work on bugfixes and other maintence work, however I have just as often seen those people drug into work in another area when a matter was pressing. Fixing base functinality of content within the project superceeds the need for new content. And I would be willing to say that bugs which effect a large portion of the player base every day are indeed interfering with base functionality of the project.
KaratonCha wrote:
coder_01/ desginer: well i could redesgin the base of the building allowing it not to topple but im to lazy and snice no one here really cares execpt for our clients, WHICH IS US, ill just ad a few T beams here and here and that SHOULD hold it.
I've been codor_01, and I assure you it's not laziness. While you don't see any contrition on SOE's part when a change wasn't thought through, I assure you the coder that made the change gets a nice talking to. He's then told to make 5 other dumb changes by the end of the week, each of which will take 2-1/2 weeks to do properly. When one of them goes bad, he gets another talking to.
The general problem in software design is that they almost never treat it like architecture. When you're building a RL building, everything is worked out beforehand, down to the size of the screws used to install the drywall. They do this for the obvious reason: It's the only way to make sure everything works out in the end.
Software companies need to do this too for the same reason. They are building a large, interconnected system where lots of pieces lean on other pieces. They need the same degree planning to make sure the 'virtual building' doesn't fall down. But that kind of planning takes time. Your average PHB doesn't understand the need for planning, so he tells the coders to 'just start coding'. That worked just fine when building a 'virtual lean-to', so many in the industry fall back on that. However with the large and complex systems being developed today you end up with something that looks like someone told you to 'just start building' a skyscraper.
Slowly, software engineering professionals are getting the point across that their dicipline needs to be handled like every other kind of engineering. However, we're nowhere near now.