Hard problems versus hard solutions
Many problems software developers are called on to solve are "hard problems". By hard problem I mean that the necessary compute power to solve the problem is high and there is no known solution that can reduce the overhead. An example of this sort of problem would a variation of the traveling salesman problem.
On the other hand, developers also called upon to solve what I would term simply "difficult problems". Difficult problems are different in that the solution is difficult for humans to comprehend, but they are know solutions that can be implemented easily at minimal cost and overhead. An example of something like this would be determining the latitude and longitude of an address in the United States. While this requires a large amount of data should you try and solve it on your own and it would be likely impossible for a human without a large reference library, there are FREE software solutions that do this very well and very rapidly.
The last and most problematic grouping is what I call "hard solutions". These are situations where someone has taken a difficult problem, treated it like a "hard" problem and (usually) through tremendous effort, built a hulking monstrosity of a quasi-solution that "is stupid, but it works". A shining example I routinely see in my line of work is software that uses the wrong paradigm to solve the problem it's supposed to be designed for.
For folks who don't write software for a living, this is the equivalent of using a hammer to pound screws. Yeah, you can do it (ask my son), but it's a hell of a lot easier to use a screwdriver. The challenge is being able to explain to someone furiously hammering on a screw that there is a better approach.
On the other hand, developers also called upon to solve what I would term simply "difficult problems". Difficult problems are different in that the solution is difficult for humans to comprehend, but they are know solutions that can be implemented easily at minimal cost and overhead. An example of something like this would be determining the latitude and longitude of an address in the United States. While this requires a large amount of data should you try and solve it on your own and it would be likely impossible for a human without a large reference library, there are FREE software solutions that do this very well and very rapidly.
The last and most problematic grouping is what I call "hard solutions". These are situations where someone has taken a difficult problem, treated it like a "hard" problem and (usually) through tremendous effort, built a hulking monstrosity of a quasi-solution that "is stupid, but it works". A shining example I routinely see in my line of work is software that uses the wrong paradigm to solve the problem it's supposed to be designed for.
For folks who don't write software for a living, this is the equivalent of using a hammer to pound screws. Yeah, you can do it (ask my son), but it's a hell of a lot easier to use a screwdriver. The challenge is being able to explain to someone furiously hammering on a screw that there is a better approach.
Comments