>Random Cramps

>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.

Performance Tuning

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.

Refactoring

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.

Build Dependencies

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.

Standards Participation

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.

Advertisements
This entry was posted in eclipse, standards. Bookmark the permalink.

2 Responses to >Random Cramps

  1. Ed Merks says:

    >Performance tuning often needs to be part of the design process itself; badly performing designs can be impossible to correct. The key is measurement, measurement, and more measurement; imagine how widely used a tool that’s fully integrated with Eclipse and as slick as the debug would be. Unfortunately differences in JVM performance can make it impossible to write code that’s tuned for all of them.Refactoring I imagine mostly helps with performance. Small methods can be JITed more easily. Less byte code runs faster because you don’t have to wait for it to load and JIT.No matter how fast builds are, they always get slower and just aren’t quite as fast as we like. Building the whole stack seems the only way. Automating the stack of dependencies helps, and given binary compatibility, you could always build and test against older versions of the stack.When it comes to standards, I feel a rant coming on. It seems wonderful to have standards, but anyone involved in the processes quickly realizes how much the process is driven as much by political interests as by the act of codifying technical best practices. Specifications that precede the full realization of best practices can act as a barrier to innovation by effectively acting as mediocrity by design.

  2. David Carver says:

    >Ed Merks said:When it comes to standards, I feel a rant coming on. It seems wonderful to have standards, but anyone involved in the processes quickly realizes how much the process is driven as much by political interests as by the act of codifying technical best practices. Specifications that precede the full realization of best practices can act as a barrier to innovation by effectively acting as mediocrity by design.Ed I agree with the above 100%, which is why we have found the most benefit from moving to an Agile Development methodology and project management philosophy based on Scrum. It helps cut down the amount of politics (you are always going to have that, but politics don’t have to be bad if they accomplish something). The key is making sure that you don’t get bogged down, which is why it’s also very important for people to participate in the development. Standards need to be more visible, and vetted more often in shorter iterations. Traditional waterfall approaches with large committees just lead to standards that take years to release, which aren’t useful by the time they are available.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s