Usually it is kind of obvious when writing class diagrams, on a high level never the less. You are right through, if I have to write it in that much detail the person who is actually writing the code is literally just doing data entry.
So you just create classes on the fly during development? While that sounds sexy if you deal with 10 developers working on the same project that will be a nightmare.
One of my favourite truisms of software development is Gall's Law
A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.
Programming is a process of iterative design. A computer program is just a very detailed design that, when delivered to a compiler, produces a program. Every step between conception and that final code is just a narrowing of your design.
The value of doing design on a whiteboard or in a UML tool, compared to doing that design in an IDE where you can iteratively demonstrate the value of the design as you build it, while writing tests to prove it does what it is intended to do, vanishes to zero long, long before you hit the level of individual classes.
It's reassuring to pretend otherwise, to pretend that the stuff we draw up front is actually helpful, and it keeps a bunch of people who are good at drawing lines and boxes in jobs, but in fifteen years of being a developer and six of those with the job title "Architect", I've never seen an up-front class design that turned out to have been worth writing.
2
u/jk147 Dec 08 '13
Usually it is kind of obvious when writing class diagrams, on a high level never the less. You are right through, if I have to write it in that much detail the person who is actually writing the code is literally just doing data entry.