July 21, 2016
In a moment of the industry where every day we have new frameworks and tools, is a good moment to remember old things.

While the **problem domain** defines the environment where the solution will come to work, the **solution domain** defines the abstract environment where the solution is developed.

The differences between those two domains are the cause for possible errors when the solution is planted into the **problem domain**.

*Problem domain* and *solution domain* are essentially the same? Looks problematic to me. Problem: “I have no money”. Solution: “I’ll rob a bank”. An ironic programmer.

In respect to a given problem (or set of problems), the solution domain (or solution space) covers all aspects of the solution product, including:

- The process by which the solution is arrived at.
- The environment in which it is constructed.
- The design, construction, testing, operation, and functions of the solution product itself.

Confusing the problem with the solution is **one of the great dangers of IT projects**, resulting in software that may be a very good solution to some problem, but not to the specific set of problems its users face. *(you can read waterfall model between lines and why agile development techniques arrived)*.

Another important variable is **time**.

How much time do you have for design the solution?
Do really need the best solution or could be just a great solution?
What is the balance between the cost of the time to find a enough good solution?

I always related it in a more visual way with the algorithm Hill Climbing algorithm that is part of algorithm intelligence division, used for search a good solution in a resonable fraction of time.

### References