If it is stupid and it works, it is not stupid.
I learned the above in the military, and I have seen no reason to unlearn it in 32 years working as an IT professional... Yeah, I'm no longer a programmer, but I still reach for my favorite hammer when I see a nail. Two years ago, I embedded Assembly Code into something that operated on Terabytes of transaction data. It wasn't stupid.
Define "work". I've seen reports that prints the correct numbers but that are built (I shit you not) with cartesian joints executed in loops, over and over, per row.
A more extreme example (I'm not making this shit up) - a reports server that makes a web service call to a "reports composer" service, one call per page, and for each page, the "reports composer" service makes multiple database queries per row (like not one of the a-holes who created this knew how to make SELECT SUM(somefield) FROM table GROUP BY whatever).
Or how about this (truly, I'm not making this shit) - an internal web app A that used JMS to call another internal app B so that it makes a database query on its behalf. But internal app B instead would delegate that to internal app C to talk to the database - internal app C would do all the sins of people who don't know how to use proper SQL and batch statements, like iterating over a relation with a fucking for-loop, each iteration a database call to get a value, to be added to a counter (again, complete ignorance of SQL aggregate functions.)
Then after internal app C shitted on the poor database (who btw, lacked indexes and had tables with fields named tmp1, tmp2 and tmp3), internal app C would return its payload to internal app B in free-form, totally flat, malformed xml, returned btw via JMS because it's enterprisey and hard-core and loosely-coupled (beasts who wrote this system wouldn't know what coupling meant anyways.)
Are you still with me (trust me, I'm truly not making this shit up), finally internal app B would take the shit-flat malformed xml and parse it (it was so bad you couldn't even use xlst to massage it), so it had to traverse the fucking DOM... to produce untyped hash tables of lists containing hash tables and more lists - hash tables and lists all the ways, like turtles in ancient cosmologies.
Then the hashtables-of-lists-of-hashtables-and-lists would be passed, again, via JMS, to internal app A, which would then pass the monstrosity to JSP pages containing thousands and thousands of lines of Java code to render that shit into a pretty HTML page.
It worked... never mind that the company needed to run like, I don't remember, a dozen web servers to make that shit run when all that was truly required (if the system had been built properly) was one server for the application and one for the database.
So yeah, "work" is not enough. I needs to work efficiently and be built for maintainability in mind. The thing that breaks projects is not to print the wrong numbers, but to cost so fucking much in operations that a company is forced to pull the plug.