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.

America Can Compete

"There is no reason that America can't compete in a global economy." Alan Mulally, CEO of Ford

Its good to see that manufacturing companies are realizing that competing doesn't mean look everywhere but America.  Now if we can just get corporate IT departments to realize that concept.

I also find it fascinating that Mulally believes that not having any problems is a problem.  It seems obvious to me, but I've never encountered a corporate culture that understands that if you're going to make progress, you're going to have a few problems.   You can't make an omlette without breaking a few eggs.

GameStop is On Sale

GameStop shares have dropped 10% in the last month, 8% just today on a couple downgrades and the departure of their CFO.  Both downgrades include analysis showing GameStop is poised for their best profit year ever, but both analysts believe the packaged video game market will disappear long term.  I'm not one to bet against a company that is printing cash.  Short sellers are piling on trying to make a quick dollar, but the higher they push that short-ratio the harder it will be for them to unwind their positions without a big bounce.  In the meantime, longs like me are taking a beating.

Interview Mistake 101: How would you do something you should never do?

I never know what to expect in an interview.  Either when I'm interviewing someone or being interviewed by someone else.  A young former coworker of mine used to see interviews more as his chance to look smart than as a chance to hire a competent coworker.  He'd always show up with trick questions and act shocked when the applicant couldn't answer the questions.  I was embarrassed to say the least, but despite his youth and eagerness, I don't think his philosophy is too far from the norm.

The daily job of most people in software development involves understanding the product and the process and translating those into results.  Why is it then that in software interview questions like how would you write a string reverser using recursion get asked? The proper response to this questions is no thank you.  The last thing a company needs is to hire someone who needs a string reversed and uses recursion because it would be fun to do it that way.

Despite the attempts over and over again by the well intentioned, the secret to most software is tedious work.  In other words you actually have to write programs.  Frameworks and patterns can and do add value, but they don't replace actually wiring and coding the application.  Making the round trip from a web page to a relational database is done over and over and over again.  From a coding perspective its largely the same if you ignore the data, but ignoring the data is the last thing any company wants the developer to do.  The data is the value.  Getting it from point A to point B is the commodity service that the programmer provides.  Being able to do that using recursion or bit by bit is not a special skill, being able to understand and ensure the data is handled properly is a special skill.

Bad Interviewing

Went on an interview recently that went poorly.  Here is my assessment.

1. I was not enthusiastic about the job.  I have no enthusiasm for the business model.
2. I interviewed on the day after Christmas and one of the guys interviewing me was on speaker phone from his home.  I was interrupting his time off with his family.
3. The manager spent an hour telling me about the details of the business and the application using company specific terms.  I've seen this mistake over and over again.  As much as every IT shop has similarities, they also have many differences.  Either terms mean slightly different things or the company uses completely different terminology.  I need a ten minute overview.  I don't go on interviews to start remembering the IP addresses of servers.
4. The manager told me that they work on 12 to 15 projects a year and then come crunch time they throw away all but 2 or 3 of them.  In my head I'm thinking that sounds awfully incompetent, but I can give no reaction to a statement like that.
5. They used Hibernate and were proud of it.  How many times do I have to fight this battle in my career?  JDBC and SQL is easier and faster than Hibernate.  IBatis is also pretty good.  Database access is one of the top impacts to performance.  I don't understand why architects always want to turn over fine grained control to get database portability in return.  In enterprise Java I've seen performance problems over and over again in my career.  I've never seen a critical application switched from using one database to using a new database.
6. The architect interviewing me believed Scala was going to replace Java.  I couldn't even remember Scala's name at the interview.  I've read about it, but I don't care deeply about it.  It is not going to replace Java, despite what you or he thinks.
7. The architect interviewing me wanted to know if I knew what closures were.  I did not off the top of my head.  I had read about them before, but I didn't find them important.  There are many ways in Java to do what closures offer and despite 3 requests, it appears like they didn't make it into Java 7.  He thought they were important.  I do not.
8. The architect interviewing me wanted to talk about MongoDB.  MongoDB is a documented-oriented database system or a key value store.  Now, I don't know much about taxes, but I would think you'd want to understand the data well enough to put them into a traditional relational database.  A key-value store seems to me like it would have serious memory demands.  I'm open on this point because tax laws are constantly changing, but even with that the key data stays the same.

Illogical Argument 2: Now is a bad time.

Another interesting argument, this time from Pete Davis at Capital Gains and Games.  Mr. Davis is talking about the economy and government spending.  He wisely states that congress needs to get serious about reducing spending, but then throws in the same argument that Washington has used over and over again---just not now.

If it is the right thing to do a year from now, its likely the right thing to do right now.

Illogical Argument 1: It would have happened anyway.

According to Bret Stephens in a Wall Street Journal opinion piece, the fifth of seven incorrect beliefs about Iran is that "The Iranian regime is headed for the ash heap of history. The best policy is to do as little as possible until it crumbles from within." Although Bret Stephens argues against its validity, I find it a very powerful argument.  The most compelling part is its results.  The world or lets face it, the United States no longer has any need to waste resources on containing Iran.  Its current dangerous regime will be destroyed without one loss of life or one more penny being spent.

When I read that about Iran, I realized that I had recently read that about the Civil War.  According to Webb Garrison's book The Lincoln No One Knows, there were a couple similar arguments in the middle of the 19th century.  There was the theory that the South could not sustain itself and would eventually rejoin the union without the need for war and there was the theory that prevailed for most of the Civil War that slavery was a dying institution.  The idea that slavery would eventually end apparently goes back to before the Declaration of Independence.  It was wither Webb or Garry Wills in his book on James Madison that believes the founders wrote the Declaration envisioning that the country would one day be slave free.  Is this revisionist history?  I'm not sure, but now we now that slavery did not end until a war was fought.

I've heard the similar argument made in hindsight about World War II, Vietnam, Korea, and both Iraq wars.  It is an argument that can be made on just about any topic, big or small.  Is it ever true?  Maybe, but I'm having trouble giving it any credibility right now.  Even if it has some truth, it certainly delays the event in question.  That delay has to have some costs associated with them.

Passwords

It is extremely annoying when websites enforce overly strict password requirements.  If I want to use "abc" for password or nothing at all, I should be allowed to do so in most situations.

Getters and Setters

Every so often I run into an article that preaches against the use of getter and setter methods.  I always read it, think to myself that looks novel, and then go right back to using getters and setters.  Getters and setters, while often obnoxious and mostly boilerplate code, are JavaBean standards relied upon by most all useful tools used for real development.  Database abstractions. Check. JSTL. Check.  Property editors.  Check.

If a tree falls in the forest

Blogging has two very real risks.  Number one is that nobody will read a word I write.  Number two is that someone will actually read this blog.  It is a lose-lose undertaking.  It means I should write every entry with the expectation that no one will read it, but with the understanding that someone might.  That juxtaposition is exactly why I have been thinking about taking up blogging.  I do not intend to make money, create a following, or even change anyone's mind.  My goals are more selfish.  By blogging, i'd like to:

1. Improve my writing skills.
2. Improve my argumentative skills.
3. Learn something.
4. Challenge my thoughts.

I welcome all criticism on my view points.