[exelius]

Completely agree. If you're building a forecasting module for an ERP system, you're probably not going to be able to hire CS grads out of MIT or Stanford to staff on it. You're likely going to get some dudes from India with little experience outside the other Dilbert-esque ERP systems they've worked on. But these guys can still be productive if given the right structured environment, and that's what coding patterns give you.

Furthermore, "rockstar" developers are often a hinderance on these kinds of projects: they take workarounds that are technically sound, but harder to maintain. Use of consistent design patterns makes maintenance a hell of a lot easier (especially when using less-talented developers). Rockstar developers are great in a startup when you need your developer to be a systems architect as well, but they're less useful in rigid functional projects like big enterprise software projects where developer and architect roles are rigidly separated.

But the example OP listed still makes sense: wrapping the example trig in a function makes sense if you plan to modify that function later and it's used in several places across the project.