My solution is rarely optimal, sometimes clever, sometimes not, and often a hack. But it gets done quickly, it works, and it "does the job".
Quite frankly, I hate "solutions" like that. I have spent way too much time supporting code written by people who "get the job done," but do so inefficiently, and cause the system to keel over two months later. Or do so poorly, and so the system mysteriously breaks when the "hacks" don't quite work.
Penny-wise, dollar-foolish. Sure, you save some time up-front coming up with the hack, and "get the business up and running." In my experience, it never takes long for "the business" to come back and say "I thought you fixed this."
Yes, but on the other hand there's no point perfecting something until you know it's actually going to stick around.
There have been times at JTV where I've implemented some feature and put it into production, only to find it doesn't stick - nobody really wanted it. In cases like these a quick hack is definitely the right thing to do - there's no point worrying about a system keeling over in two months if that system won't even exist in two months.
In all fairness, though, this often has more to do with management than anything technical. No matter how much I teach my customers, sometimes they just don't learn.
The real world is often messy, and solutions that work in it are often messy. The best you can hope for is that someone uses a lookup table/config file instead of a tangled nest of hard-coded "if" statements. But seeking elegant algorithms to address real world problems is often a wild goose chase.
No one's looking for elegant algorithms for real world problems here.
The reality is that most real-world problems are not particularly complicated, yet most have exceedingly complicated solutions, and as a result, disproportionately large maintenance overhead -- and that maintenance is largely code archeology (wow, what idiot came up with this bit dumbass approach? Why does this framework require 6 new classes in order to add a simple pair of pages to the site?), not productive time.
In my experience, it never takes long for "the business" to come back and say "I thought you fixed this."
Yes. But the problem is that without the sub-optimal time-saving hack the business might not have come back at all.
A business that can afford to pay people to fix the hacks that kept it solvent last month is called successful. [1]
So, there's a balance. Inevitably, it's impossible to get the balance quite right, so even the optimal software engineering job involves spending half your time complaining about overengineered code and the other half complaining about underengineered code.
[1] Of course, many businesses just pay people to paper over last month's hacks with a new month's worth of hacks, ad infinitum. That is sort of like success... for as long as the house of cards stays up. But it is also hell.
Same here. Solutions like that are unfortunately the norm, which is leading to the deplorable state of software industry wide, and the general and growing malaise from the developers.
When I started out as a developer, I was one of the best. Over the years, I've gotten rusty because my work has been so mind-numbing that the last thing I've been wanting to do after work has been to look at more code.
Quite frankly, I hate "solutions" like that. I have spent way too much time supporting code written by people who "get the job done," but do so inefficiently, and cause the system to keel over two months later. Or do so poorly, and so the system mysteriously breaks when the "hacks" don't quite work.
Penny-wise, dollar-foolish. Sure, you save some time up-front coming up with the hack, and "get the business up and running." In my experience, it never takes long for "the business" to come back and say "I thought you fixed this."