Code is the ultimate model for software, but it is like the trees of a forest. You can see a couple, but only few people can see the entire forest by just looking at the code. For the rest of us, diagrams are the way to see the forest, and UML is the standard for diagrams.
Not planning is for losers)
I think this happens because developers, like all people, are focused on what they can see and touch right now. It is easier to try to code a GUI interaction or tackle database update problems than it is to work at an abstract level through the interactions that are taking place from GUI to database
In particular, medium to large projects (>10,000 function points) are at a very high risk of failure if you don't consider the architectural issues. Considering only 3 out of 10 software projects are successful only a fool would skip planning the architecture (see Failed? You get what you deserve!)
If you are a good coder then you will make a quantum leap in your ability to tackle large problems by being able to work through abstractions at a higher level. How often do we find ourselves unable to implement simple features simply because the architecture doesn't support it?
Well the architecture doesn't support it because we spend very little time developing the blueprint for the architecture of the system.
UML diagrams need to be produced at two levels:
- the analysis or 'what' level
- the design or 'how' level
Analysis diagrams do not have implementation classes on them, i.e. no vendor specific classes. The goal is to identify how the high level concepts (user, warehouse, product, etc) relate to each other.
Once the analysis diagrams validate that the requirements are relatively complete and consistent, then you can create design diagrams with the implementation classes. In general the analysis diagrams are one to many to the design diagrams.
Since you have validated the architecture at the analysis level, you can now do the design level without worrying about compromising the architectural integrity. Once the design level is complete you can code without compromising the design level.
When well done the analysis UML, design UML, and code are all in sync. Good software is properly planned and executed from the top down. It is mentally tougher to create software this way, but the alternative is continuous patches and never ending bug-fix cycles.
The 7 Principles of Highly Effective People:
with a dull saw
UML is the tool to sharpen the saw, it does take time to learn and apply, but you will save yourself much more time and be much more successful.