I think this is a false dichotomy -- developing a masterful understanding of what things cost must be coupled with a masterful understanding of what makes things valuable.
It might be a false dichotomy in theory ("well, no reason why these two concept should not be orthogonal") but it sure is a real dichotomy for very many developers.
People lost in the details of coding, best practices, new fancy languages, monads et al, while not producing anything of substance for real users -- or getting lost in the process and not getting anything released.
There's even a kind of term for these people "architecture astronauts" (coind by Joel Spolsky IIRC). And the even older, "worse is better" notion is also related to the same issue.
There's an even worse kind of architecture astronaut, almost the opposite of this article. It's the architects who don't even know about encapsulation, loose coupling/tight cohesion or even not to duplicate data anywhere without rules for resolving mismatches.
They've never written a line of code and yet somehow are dictating spaghetti enterprise architecture. Their business requirements are things like "must comply with all applicable standards" (isn't it your job to at least work out which ones, or are you above that?) and they never actually stop to think whether any of this will actually work.
I'll take a language hipster and a clueless business user who just wants it done any day.
I was saying much better advice to programmers is "remember to think about what makes software valuable" rather than "you don't want to think like a programmer"
Comments
It might be a false dichotomy in theory ("well, no reason why these two concept should not be orthogonal") but it sure is a real dichotomy for very many developers.
People lost in the details of coding, best practices, new fancy languages, monads et al, while not producing anything of substance for real users -- or getting lost in the process and not getting anything released.
There's even a kind of term for these people "architecture astronauts" (coind by Joel Spolsky IIRC). And the even older, "worse is better" notion is also related to the same issue.
There's an even worse kind of architecture astronaut, almost the opposite of this article. It's the architects who don't even know about encapsulation, loose coupling/tight cohesion or even not to duplicate data anywhere without rules for resolving mismatches.
They've never written a line of code and yet somehow are dictating spaghetti enterprise architecture. Their business requirements are things like "must comply with all applicable standards" (isn't it your job to at least work out which ones, or are you above that?) and they never actually stop to think whether any of this will actually work.
I'll take a language hipster and a clueless business user who just wants it done any day.
I agree it's a real problem.
I was saying much better advice to programmers is "remember to think about what makes software valuable" rather than "you don't want to think like a programmer"