Agile Development

When did agile development become a code word for daily morning meetings?  I hear my friends at RPS have a daily status meeting every morning which includes a conference call with all their coworkers overseas.  Sounds like hell to me and even though its a stable company with open positions with people I know, the micromanagement and office politics was enough to keep me from going back.

Jar Dependencies

There is a small debate in the software community about whether or not it makes sense to check jar dependencies into the code repository.  Keeping them in the repository leads is a more traditional approach to managing dependencies and builds, but build tools like Maven store the jar files outside of the code repository in a jar repository.  This approach has the advantage of ever only needing one copy of any particular dependency on your machine.  The two alternative methods have me wondering what it looks like when one needs to go back and build a previous version of a project.  If the jars are stored in the repository, then its clear what jars are included in the build.  If the build relies on a pom file, is it as clear?  Are they the same jar files?  It seems like they should be as long as its a release,  but it also seems like snapshots would be impossible to be rebuilt.

Code Performance

It seems to me that some developers often give a shrug of the shoulders response to performance problems. The suggestion these developers make is that the slowness is just a price the users have to pay for the functionality. It is true that solving performance problems is often a tedious task without any obvious solutions.  For starters, the code works, so why muck with it? There are two very good reasons.  They usually are not that hard to fix and everyone thinks you're a genius when you do fix them.

The hardest part of fixing performance problems is identifying them.  This is where profiling and heap analysis tools come into play.  The rule of thumb is that 5% of the code will be 95% of the problem.  I'm sure people are making up the percentages, but the point is simply that fixing one or two small pieces of code will make the whole application faster.  Finding the cause is job one.  That seems like a simple statement, but more often than not developers will be quick to throw out solutions firsts.  "Let's get new servers", "We need to make it multi-threaded", "The network is slow", etc...

Plenty of open source profiling and heap analysis tools exist to help track down bottlenecks.  Not to mention simply dumping timestamps to the console can go a long way.  Many areas of the code are also natural places where a slow down could happen.  These include communication across the network, loops, object creation, and database access.  When you find these areas, try to avoid using gimmicks that likely will only moderately improve performance while making the code harder to read.

Instead, try one of the following top 7 ways to speed up your code.

1. Increase memory
2. Add caching
3. Write efficient SQL with joins and indexed columns
4. Do more in each step
1. Optimize loops (attributes, unrolling)
2. Chunks across the wire, database, etc
5. Choose the right collection
6. Add more threads, with care
7. Reduce object creation

Bad week for my stock picks

Bad week on earnings!  GME has dropped after industry numbers for April looked bad.  I don't see why this is a big deal and I was thinking about switching my SPU position back to GME before GME reports earnings on Thursday, but SPU has baffled me today.  They reported a Q1 blow out with plenty of cash on hand and they made it clear that they have an S-1 outstanding only if they can find suitable acquisitions to sustain their growth rate.  So why are they down 5 to 6%?.  Meanwhile DAAT reported a loss and blamed it on timing, but that seems like a poor excuse.

Juice, Anyone?

I have never invested in China before, but I recently took a look at the numbers being put out by Sky People Fruit Juice and I've changed my tune.  I just took 1/3 of my position in GME and moved it over to SPU.  At 6.67 cents, projected earnings per share of over a dollar and a growth rate of 50% with spare production capacity and plenty of market potential, it looks to be a 10 to 12 dollar stock sooner rather than later.  I still see GME moving to 28 or 30 by the end of summer, but SPU is looking like a great next move.

Java Interfaces

To my fellow programmers, if you design an interface that has exactly one implementation then you are wasting your time and making the code less readable for everyone that comes after you.  An interface is for code that will have MULTIPLE implementations.  A one to one relationship normally leads to a class that is not well encapsulated and a class that is not encapsulated leads to bugs.

Terminology Refresh

Let me be honest, I don't have the best memory in the world.  I forget things, especially names.  Names of people, places, movies, and on and on and on.    After 13 years of programming, admitting that I've forgotten the names of basic object oriented techniques might not be kosher, but I admit to my faults. Method overloading and polymorphism especially confuse me because they're so similar. 

Polymorphism is when the code decides at run time which method gets executed.  This is basically where objects can be subclasses or they can implement interfaces.  Which method gets called depends on the actual object being referenced.  Since one type of object or an interface can have multiple subclasses or implementations, methods that operate on interfaces, abstract classes, or simply super classes don't have the luxury of knowing which classes is going to implement the method being referenced.  This is quite different than method overloading even though as the name implies, method overloading has to do with multiple methods.


Method overloading is the ability to have multiple implementations of a method with different parameters.  Contrary to polymorphism its possible to know which method will be called before run time.  It will be the method with the parameters that match the passed in attributes. The benefits of method overloading aren't quite as obvious to me as polymorphism.  Polymorphism allows for some slick and simpler designs, but is dangerous in the wrong hands.  Method overloading isn't so dangerous and can be very convenient, but it can lead to developers scratching their heads figuring out the difference between multiple methods named the same.

Encapsulation is another term I often get confused, because it seems so simple. It means to hide stuff, right?  Just make some methods and attributes private or design an api and hide the implementation behind that, right?  Well, maybe not exactly.  I think those are acceptable answers, but it turns out that if I go back to my OO programming books from college, then encapsulation is a bit different from hiding implementations.  Encapsulation in OOP means to include behavior in the same container as the data.  This was an aha moment for me because I had forgotten that it was such a specific term and one that is regrettably (IMHO) seldom practiced in the enterprise world, but that could be another blog.