Trying to get the philosophy behind a software development culture, or around IT in general, right can be a balancing act between developers and business owners or in the case of service between support staff and users. There are such different priorities for the different stakeholders and work often has to be done to get the different communities to understand each other as much as to focus on the culture on one side or the other of the divide.
My general feeling is that UML focussed on the benefits of iteration which was the battle of the day and fortunately one that is now largely won, but it has the drawback of often using complex visual tools for the description of the software and as a result implies a heavy analysis and communication of the design. This is sometimes necessary but not always. In practice business owners, product managers and subject matter experts rarely got much benefit from even the most minimally technical looking diagrams. Which isn’t to say that they are not sometimes useful but it isn’t the basis of progress. Use cases seem to have wider benefits.
The Agile methodology suffers culturally from the same slant towards the interests of the technologist, even to a greater extent than ITIL does for IT service management. ITIL is a great reference model, but is often a description of an organization as if the IT service department ran the company, which it doesn’t, and shouldn’t. In the same way Agile is software development philosophy written as if software developers ruled the world. While we could probably debate to what extent they actually do, the ideal philosophy in practice is something that better balances the needs of business owners, and investors with those of the developer.
A balanced coding philosophy needs to be able to create great products which delight end customers as well as realizing that innovations during the design and development process can lead to unanticipated user benefits. The aim is to facilitate communication to achieve the common goal and deliver the best possible product rather than being driven by the battle for control of the project.
I have added the coding philosophy to a separate page here so that comments can be left below it.