A game is a system, and good systems engineering practices, when applied in the early design phase, lead to strong balanceability. The three core ideas that translate well from systems engineering to game balance are: game element modularity, consistency of design motivation and complexity control. When used in combination early on, they can save designers enormous amounts of time in the alpha and beta testing stages.
Game Element Modularity
Game element modularity boils down to an idea that each game mechanic should exist for a specific purpose, and if possible, a singular purpose. When this principle is adhered to, tweaking a mechanic only changes one aspect of the gameplay, rather than several aspects.
A good example of where this caused a developer unnecessary pain was during the beta testing of Starcraft. Blizzard (the developer of Starcraft) had a fairly straightforward damage system in which each unit did one of three types of damage, explosive, normal or concussive. Each of these damage types had a different damage multiplier against various unit sizes --explosive was good against large targets, concussive was good against small targets, and normal was good against everything. One unit, the Mutalisk, ended up being a constant hassle to balance in part because there were a lot more than three different types of units (i.e. large/med/small didn’t really cut it) in terms of desired functionality. Setting the Mutalisk to the “medium” unit type classification made it far too resistant to explosive weapon-type units, while making it large made it too vulnerable to the same units (which were sometimes, but not always, its theoretical counters). Blizzard couldn’t just change the coefficients of explosive vs. large or explosive vs. medium though, because that could’ve upset a bunch of other unit matchups that were not comparable to the Mutalisk vs. explosive damage-type unit matchup. They couldn’t really change the attack values of the units using explosive weapons either, since that threw off other things as well!
This was further confounded by the fact that the Mutalisk had two strong roles - anti-air and anti-infantry (ground units without air attack), all with the same base damage, while other units similar to it (scout, wraith) had separate weapon systems, which could be balanced for their specific roles.
Due to this a lack of modularity in the damage system and the Mutalisk, Blizzard didn’t manage to balance the Mutalisk until five months after the commercial release of the game. It wasn’t that a fix was impossible, but rather that the fix was difficult to ascertain because of a lack of system modularity. The Mutalisk had a somewhat unique purpose in Starcraft, and if Blizzard had isolated its balance parameters from other unrelated units, they would’ve had a much easier time balancing it. The easiest solution would’ve been to simply add a unit type to hold the Mutalisk (Along with any similar units) with its own resistance to various types of damage. Had the designers made the Mutalisks air and ground attacks different, they would’ve also had an easier time.
Of course, for the most part, Starcraft did have a reasonable amount of modularity. One example of this, is the Spellcaster units, which tended to have a crisp definition of purpose, and relatively specialized roles. The fact that many spells, including Broodling and EMP Blast, had super-specialized roles, made balance much easier to achieve with these units.
Good system modularity isn’t just preventative medicine for play balance, its actually a proactive step towards a solution. A system with strong modularity will have all the knobs and levers necessary to tweak very specific problems with exactly what is needed without side effects.