mike.mainguy

In the grand tradition of being difficult, I'm rediscovering an antipattern that has killed projects in the past. I'll call it "too specific requirements". The symptoms are stacks and reams of requirements that you MUST implement, even if there are better ways to solve the apparent problem. Case in point: We have a rock solid requirement to build a user preference management screen. Unfortunately, most of the preferences we need to collect are (IMHO) better collected and maintained in situ. As an example, one requirement is to "enable the user to select their default payment method". Of the hundreds of possible solutions, the requirement implies that we should have a special screen where users can find this option, select it, then never see it again when checking out their items. This sounds great on paper, but I'm struck by the notion that a user would EVER know or think to go to some other screen (preferences? My Profile? not sure what to call...

Questia has an interesting article about "how to think like a genius" http://www.questianewsletter.com/newsletter/volume-5-issue-5/index.htm?CRID=nullCRnull&OFFID=newsletter20091004l#bigidea . I'd have to say this is spot-on and a good Adding my own thoughts to the above, I've noticed that I rarely do new or innovative things by "trying", I'm more innovative when exploring interesting side effects. I would go further to say that lucky people are simply the ones who can creatively extract value from more situations than other people. I often hear people sharing their misfortunes with me and quite often they have a negative spin on things that happened to me that I thought where golden opportunities, but they simply saw as obstacles. Which reminds me of a story... A gentleman farmer at the turn of the century was being overrun by rabbits and went into town looking for an expert marksman to get rid of the pests. On his way, he passed a farm with doz...

I recently had lunch with my team and had the dubious fortune of sitting across the table from Mr Knowitall. As we recently installed SONAR, he mentioned his surprise at our "critical performance" issues, namely that we're using a + b to concatenate strings instead of StringBuilder in a few dozen places. I dismissed this as "not really a critical problem", which spawned a heated discussion about the merits of using StringBuilder over normal string concatenation in Java. He ended up issuing a direct challenge that Stringbuilder is 25% faster than string concatenation. He also stated that I could build a test harness and see for myself and bet that if he was right I would buy lunch... Aside from kicking myself for getting into a ridiculously pointless argument that I've had am million times before (he also tried to drag me into the "you better check .isdebugenabled() before calling .debug() in log4j because otherwise you're taking a performance hit, b...