If there's one thing that seems to be a constant source of issues, it's people constructing SQL queries through string concatenation. Even if you're using parameters in the query, I'm opposed to handling raw SQL as strings in my programs. My solution is always "use a builder"- an API that constructs a syntax tree that it can then render to SQL as needed. (Yes, a builder, not an ORM, that's a whole other discussion, I'm not dogmatically anti-ORM, but it's a leaky abstraction at best.)

Many languages have such a thing, Java included. Lukasz's team was using Java, and they had a rule: "don't do SQL strings, use a builder". Unfortunately for Lukasz's team, their guideline didn't specify what kind of builder.

    StringBuilder builder = new StringBuilder();

    builder.append("where ID_BSNGP = ? ");
    builder.append("and ID_ITM = ? ");
    builder.append("for update");

    SQLQuery query = new SQLQuery();

    query.setQueryString(builder.toString());

A StringBuilder is a kind of builder. Technically correct and all that. It's just concatenation with extra steps, but it's a builder. Of course, the bonus point here is that this built query is… just wrong? SELECT FOR UPDATE field FROM table WHERE condition would make sense, but we're missing most of that syntax here.

That this code was running in production without anyone noticing means that whatever errors this was triggering were getting swallowed or ignored, and the fact that no good output ever came from it ended up not mattering. The real WTF is less the malicious compliance and more the fact that this obviously broken code wasn't so broken as to be noticed.

[Advertisement] Utilize BuildMaster to release your software with confidence, at the pace your business demands. Download today!