On first look UML looks like the "proper" way of building software, but it really isn't because software changes way too much while it's built. It's like planni

On first look UML looks like the "proper" way of building software, but it really isn't because software changes way too much while it's built. It's like planning out a road-trip to the minute - it won't hold up. Some compare UML to how architects use blueprints to build brick-and-mortar stuff, but concrete walls and ceilings don't move midway like software does (figuratively speaking). IMO software process is all about controlling complexity. When the problem is small, our human mind can come up with ingenious solutions no computer can match. So it's better to break down the project into small, modular, and testable components rather than try to overcome the complexity with fancy plans that will start breaking down the moment you start implementing. UML could be useful for documentation purposes though, giving a bit more info than say Javadoc. But that will come after you write the software, not before. There are some tools that claim round-tripping (i.e., you write your UML, the tool magically generates code, you edit the code, and the tool magically updates the UML to stay in sync). I tried a few and found them too painful to use.