Ever since the new technical director has joined the company, UML design become the compulsary milestone for those projects which are bigger than certain size. He was working at Rational Software before the company acquired by IBM and now, he's working remotely from US and occasionally in our KL office. I'm glad that we have such practice advocated by a top player like him, otherwise no one will actually spend efforts on UML design. He did teach us on every single type of UML diagram and I believe every employee (the attendance of the UML workshop was compulsary) has already get familiar with most of the notations. It short, we all now can interpret most UML diagrams.
But, one of the project manager asked me the other day "Does class diagram really helps our development? If it doesn't, I'm OK if you want to skip it"
Of course I wouldn't want to skip it, if I do this time, I know I'm going to skip it forever.
Fortunately I finally managed to convince her that having UML diagrams could literally shorten the development time and we're not drawing out the diagrams for the sake of showing it to people.
Usually, before I write the first line of code, I design the class in my mind, I just don't draw it out. It's not that I like to do design so much, it is because I couldn't start any coding without having a rough picture of all the objects I can think of. Therefore, by drawing it out, I'm actually forcing myself to think of the objects (and the relationships of them) a lot further. Besides that, diagrams help bringing our design to a more consistent level, though conflicting is still avoidable.
Perhaps our technical director would still have to work harder on pushing UML design because while it's hard to tell people how to do certain things, justify to people for doing certain things is a lot more harder.
During the discussion of gathering essential features for a project which I'll be working on soon, one of the developers posted a question asking why so many people like to put all sort of configuration data into the properties file (similar to config file or more well-known ini file) instead of storing them into database, as he claimed that by doing that no server restart would be required and we can see immediate effect of configuration changes.
My answer to him was the database is meant for, obviously, keeping business data. By saying this I mean the database should be shared by various kind of applications, such as web application, rich desktop client and even mobile application. Any specific kind of data which is only applicable to a limited set of database clients is somewhat discouraged to be stored in the database.
In contrast, application-specific configuration data should be packaged together with the application itself in order to make the deployment process easier. But somehow, I forgot to tell him that by using properties file, rebooting of server isn't necessarily required, it all depends on how you want your application to consume the changes.
