Quote Originally Posted by Xianghua View Post
You are a huge Hypocrite though. Your advice to them is "Don't rush" yet you want them to rush out info to unfinished Projects and patches. They simply can not give out complete info to an uncompleted project, its impossible.
There is a difference between not wanting them to rush and wanting them to do things in the right order. I'm going to assume you aren't a programmer and have little to no experience coding. The debugging process works, roughly, in 4 simple steps that can also be applied to patching::
1) Identify the exact problem
2) Make a plan to fix it
3) Implement the changes
4) Repeat from step 1 until you have removed all bugs
Assuming you are a skilled programming team, by the team you have fully identified the bug you should have a good idea on how to fix it or at least how to break it down into parts that you can fix. When you finally start implementing the changes you know exactly what you're going to change.

Like it or not SE is in the debug phase of this game. There are problems with the game that they need to fix before they move onto other things. While they are trying to iron out kinks in the battle system, something the entire game relies on, they are also adding things to the game. That is a waste of time and everything they are adding that is based on the battle system, such as raids, is being rushed out. Why is it being rushed out? Because after they make an update to the battle system, they have to rebalance all the existing content. Adding new content delays core changes to the game that NEED to be released. Raids are nice but we don't NEED them yet, especially since they are delaying fixes to the game's core. If you have your priorities wrong, like SE currently appears to, you can rush out some things and be taking far too long on others. Lets say you're working on a program used by a bank. Now no program is perfect and you have to fix bugs and such but you primarily release new versions of the User Interface without addressing known bugs, some of which may be extremely problematic to anyone who uses it if left unfixed. You are rushing out the UI while you need to release bug fixes.

And to address your note on not being able to give complete info to an uncompleted project:: If the people making changes cannot give detailed explanations on ALL the changes they plan to make, then those people should be fired. They may have to make changes to their plan but before any programmer starts making changes they have a plan. They know that they are going to change X, Y, and Z and they know how they intend to do it. Stuff can happen that requires them to make different changes than the ones they first wanted to but when they start, they have a complete list of what they're doing and how they intend to do it. Its like constructing a building, they have a blueprint that shows EVERYTHING about the building. Or like baking a cake, you have a recipe that tells you how to do it. Or modern demolitions where after computer simulations, they have a PLAN on where to put the explosives and exactly how much they need at that spot. They don't just throw up beams and hope the building looks like the Empire State Building or throw random stuff in a bowl and hope they come out with cake batter or toss TNT in random places and hope they take down the building without collateral damage. Programming works the EXACT same way, you don't code blindly, you plan it out as best you can then make changes to your plan as you progress if they are needed.