Java Performance Tuning News April 2013: Engineering

News April 2013: "If engineers could build a bridge, and for not very much cost could test it to destruction by driving something heavy over it but with no casualties and leaving no debris; and, finding that it didn't handle the heavy vehicle, could just work on buttressing some aspect of the bridge, and for not very much cost a couple of days later put the next version of the bridge up for testing, it wouldn't surprise me to see bridges developed in just that way. And finally I realised that software engineering differs from most other types of engineering in a very specific way. We have a cost model that mostly encourages us to build incomplete constructs, because it's relatively cheap to fix. Where this doesn't apply (nuclear power plant management, aircraft fly-by-wire systems, etc), development times are much longer and much more expensive (for the equivalent amount of software).

Is this good or bad? I make no judgement. But I will observe that in the last 20 years the way people live in large chunks of the world has dramatically changed from all the half built continually buttressed software engineering projects that make up the web, the world of apps, and all that we can find in cyberspace, on our laptops, desktops and phones."

Interfaces: balancing debugging vs. customization

What are the cost vs. benefits of creating interfaces and how to balance them. I am only considering cases where interfaces are optional and aren’t needed.

Benefits:
1. Simplify interaction: Easier to see how to use a List than an ArrayList
2. Make testing easier because replacement implementations can be used
3. Can make future changes easier

Costs:
1. Harder to understand what the code is doing
2. When you need to look at the implementing class, it can take a lot of work to find it.

According to SOLID, "one should “Depend upon Abstractions. Do not depend upon concretions.” "

The citation says: “, as much as is feasible, the principle should be followed. The reason is simple, concrete things change alot, abstract things change much less frequently. Morevoer, abstractions are “hinge points”, they represent the places where the design can bend or be extended, without themselves being modified (OCP).”

I don’t see that all or even most concrete things change a lot (at least in their public interface). If the public interface needs to change then doesn’t that mean that the interface class probably would need to change also?

How would that work with a Swing program? Would all GUI elements need to be passed in as interfaces?

Can documentation be a "bad smell"?

How much code documentation is a symptom of bad coding (i.e. poor method or variables names, poor class or package structure, missing logging, etc)?

Management: Enemy of Enterprise - Doug French - Mises Daily

Management: Enemy of Enterprise - Doug French - Mises Daily: "Once you have the business going, interruptions must be avoided; they are productivity killers, as are meetings. Get some sleep, get some quick wins and remember that good enough is fine and nobody can estimate worth a darn."

Crowd-Sourced Call Identification and Suppression | FTC Robocall Challenge

Crowd-Sourced Call Identification and Suppression | FTC Robocall Challenge: "We recommend the creation of a system that allows users to report, to an online database system, the originating telephone number of unwanted solicitations, advertisements or robotically placed calls (henceforth called “spammers”). We also recommend that users’ telephones or external hardware may automatically query the database about the telephone number of an incoming call (before the call is answered, or even before the telephone rings) to determine if the caller has been flagged as a spammer by other users, and optionally block the call or otherwise handle it differently from a non-spam call."