anchor.diff:  
   == 5. Account for overconstrained planning
   
  -It can happen that there aren't enough resources to solve a planning problem without breaking hard constraints.
  +It can happen that there aren't enough resources to solve a planning problem without breaking a hard constraint.
   In that case, it's often better to leave some entities unassigned (as a little as possible of course).
   
   For example in employee rostering, when we need to assign 4 late shifts on the same day and we only have 3 employees,
   it's better to leave 1 shift unassigned than to assign an employee to 2 shifts at the same time.
   
   Going one step further, we can add virtual resources to indicate how many extra resources to buy/hire.
  -For example in the same employee rostering case, we could add 2 virtual employees. It will use only one of these
  -and tell us that we can make the schedule feasible again by hiring 1 extra employee.
  +For example in the same employee rostering case, we could add 2 virtual employees.
  +After solving, it will use one of these
  +which tell us that we can make the schedule feasible again by hiring 1 extra employee.
   
   Technically, we need to treat unassigned (or virtual assigned) entities differently in the constraints
   and add a medium score level (between hard and soft) to penalize the number of unassigned (or virtual assigned) entities.
  
positive.code: == 2. Implement all hard constraints
  
  *An optimal solution that takes only 99% of the hard constraints into account is 100% useless.*
  So implement at least all hard constraints.
  
  For example in Vehicle Routing, let's suppose we need to pickup nuclear cargo too,
  but forget to add a hard constraint to pick those up with a special vehicle:
  
negative.code: As you can see, taking that extra hard constraint into account can change the optimal solution entirely.
  
  Technically, OptaPlanner supports any type of constraint: unlike other solvers, it doesn't care if the constraint is linear, quadratic or worse.
  As long as it can compare the score of any 2 solutions, it finds the best one.
  The enables you to implement all constraints: none will be out reach.
  
  
  == 3. Don't hard code the score weights
  
  Most business people can't tell us the best score weights until they've seen the impact of those weights on their schedule.
  So allow to user to change the score weights at runtime and quickly see the effect of his/her changes on the solution.
  
  For example in Cloud Balancing: should we focus on load balancing or on cost reduction?
  
  image::parameterizeTheScoreWeightsSubset.png[]
  
  Some constraints work together, others work against each other.
  Especially for that last kind (as shown above), *different stakeholders within the same enterprise can disagree on the score weights*.
  Empower the project owner to settle those negotiations by directly changing the weights in the UI.
  
  Technically, simply add a singleton with the score weights in the dataset and use those weights in the constraints.
  Look for a `*Parametrization` class in some of the OptaPlanner examples.
  
  
  