>I’ve been thinking about a variety of things lately, so this will be a bit of what’s jostling around inside my head. One thing I have found about blogging, is that it does let me get some thoughts jotted down and get some feedback. The nice thing is that in most cases it doesn’t take a lot of time to get something written. Anyways, here is what is rattling around in the old coconut now.
This is something that I think that we as developers need to pay a bit more attention to when we develop. As it stands right now, in most cases we put this off until the very end, which means due to deadlines and other bug fixes, we never actually get around to performance tuning. I’m not one of those that thinks that performance tuning needs to happen every time you write code, it just doesn’t make sense to do it. However, with that said, I think there should be at least one middle iteration during the development process where performance is addressed. In some cases, we need to make sure that we are testing with some real world scenarios not the small test cases we use everyday. What may work great for the simple cases, gets bogged down when you try to use it in a typical real world scenario. So, my dream would be to have people devote some more time to performance in the middle and at the end of the development. The faster we make the code for the tough cases, the better it will be over all in most cases.
I’m really becoming a fan of refactoring. This in some ways goes against the performance tuning but when refactoring is applied correctly, it can help with performance in unexpected beneficial ways. Anytime that we can make it easier to maintain code, and also reduce the overall footprint size of the programs we have to maintain it is a good thing. Like Performance tuning, it seems to be one of those things that gets pushed to the side as unneeded busy work. In some cases this is because there aren’t enough unit tests to make sure that the refactoring doesn’t break existing functionality. If the unit tests aren’t there, write them first, and then refactor. It’ll help the person that comes behind you, and maybe yourself later on.
This is something that’s a pain point for projects that have multiple dependencies on a variety of plugins or common utility jars. There seems to be two approaches that people take:
- Build everything every time something changes whether it needs to be rebuilt or not.
- Have a snapshot of a set of dependencies, and then periodically rebuild the whole project.
Both have disadvantages. The first causes unnecessary wait times for continuous integration scenarios, especially when a full build may take 8 hours or more. The later can introduce errors late in the development cycle, because you aren’t continuously integrating with the code base as it changes. I’d be interested in hearing how people have addressed the build dependencies issue.
One thing I have noticed in the various standards work that I have done and the groups that I have participated, is that there is a tendency to join the group for the name recognition. However, when it comes to the participation and helping move the organization along, this seems to fall to a very few core people that do 90% of the work. The problem here is that the work that the 10% or so of the membership does, affects the overall direction as a whole. This doesn’t necessarily make for a good standards process. If you are a member of any organization, please take the time to participate and more importantly, voice your opinions at the meetings. Communication is the thing that drives change, speaking privately or in side conversations doesn’t change anything unless the people that are elected know that something isn’t working. Also, take the time to work on any groups or committees that the orginization may have. We are all busy, but in most cases, the time committment isn’t as great as one may think. A little bit of feedback and elbow grease can go a long way to helping make an organization successful and beneficial for it’s entire user community, not just the few that are currently doing 90% of the work.
Well, I think that’s it for now. Thoughts and feedback are always appreciated.