Bertil Muth and Chris thanks for stopping by :) You are both correct that some of the decision making stops by in developers’ hands, and of course I did not mean to deny that. I think I came on too strong headed, there is a good article in there.
But, in general, the scales are not balanced, at least in my experience. Technical reasons rarely counter business reasons. There is rarely mentioned in a business’ mission the idea of low technical debt for example, of reliability, of enabling. Business mission almost constantly discusses functionality, HOW, a lot of how will spawn a lot of features by default.
And since a mission is basically explaining how the vision becomes reality, the correct developer mindset is a lot of times overridden by a general feeling of necessity or, more often, emergency.
The dialogue should exist between developers and management and it is indeed in the interest of both parties, but my feeling is that in general there is a very very very low awareness of best practices of developing software on the other side of the table and when we as developers claim to be creating “impacts not software” there will be some resistance met because these are the words that should have been told from the business team. Truth is we’re supposed to make software, when we fire up our precious editors and tool chain, software is what comes out of it.
That our users should never even know there is software behind their leisurely experiences, that is another aspect. Architecture and management wise there are many implications of:
Nobody wants to use software
… I’m just saying that:
- in a world of “coders” churning scripts metaphors are poorly understood
- in a world of “managers” churning features metaphors are poorly used