Monthly Archives: November 2015

Turkey Responds to Russia: “No”

As I mentioned when Russian airstrikes in Syria began, the airstrikes have nothing to do with Assad and everything to do with keeping Washington distracted, maintaining the status quo in Syria (that is, prolonging the conflict), and pressuring Turkey (as an expansion on the already decades-old play of keeping Armenia at odds with Turkey and Azerbaijan).

The Russians did what militaries so often do when they want to present a pressuring posture and forced the issue by violating a political target’s airspace while in the course of some other operation (consider the US Navy’s recently deliberate disregard of what the Chinese claim are their “territorial waters” in the South China Sea — though the issue there is almost exactly reversed: the Chinese are the aggressors in the sense that they are laying claim to broad swathes of ocean over which Beijing has never had any practical control). Turkey decided to take the opportunity to send a message to both Moscow and Washington by shooting down a Russian jet.

The important message Ankara is sending is that they will not cooperate on any terms with Moscow, that Ankara still considers itself a Western-ally, and — perhaps most interestingly — forcing the public dialog to become, at least temporarily, about the geopolitical game that is going on instead of the incidental and petty distraction of Assad and ISIS that has been filling the news. ISIS has used terror tactics to get in the news lately (Paris made a big splash, after all), and now Turkey has used a similar technique, though not terrorism by any stretch, to change the focus of public reporting for at least a few days.

If Washington was waiting for a green light in the region before surprising everyone with a sudden shift from Arab to Persian support, this was it. The best move right now would be for Obama to show up in Tehran tomorrow, and Washington to flip sides overnight, both with regard to Tehran/Riyadh and ISIS/Assad. By getting on the Persian side of things Russia has nowhere to go, loses its lever in Iran, and has to (for the first time in two decades) react to Washington instead of being the initiator. The Israelis and Egyptians will play ball — they have before and they will again (and judging by Bibi’s deft use of hyperbolic rhetoric over the last few years, he’s ready to make a deal that let’s Tel Aviv relax), and Turkey is all but shouting out loud in plain language that its time to pinch the destabilizing issues at their source.

Whether anyone who is allowed to make a decision is paying attention is anyone’s guess — the last several years of American policy make me wonder if anyone is paying any attention at all… which is probably why Ankara is trying its hardest to force a focus on the strategic issues that underlie the future-changing alignment shifts in the region instead of letting the public dialog remain purely about peripheral issues like ISIS and Assad.

Methodologies in open source development

Prompted by an article on opensource.com about scrum in foss projects. This is an incomplete, impulsive rough draft and requires some major revisions.

Nothing makes me facepalm faster than when I get hired to work on a project and the first thing anyone tells me is “This project is going to be great because we are using the best methodologies, you know, like TDD and Scrum and everything. Totally perfect.”

WTF!? How about telling me about the problem the project solves or why it will be an improvement over whatever came before or talking about the architecture or something? There are only three conclusions I can draw from seeing that the only thing someone can think to say when I first enter a project is a word about methodology:

  1. They have no clue what the project actually does.
  2. There are no project goals.
  3. They are hiring me specifically because they have not yet encountered any other competent developers and they know it, yet (amazingly) they feel confident in dictating whatever they decided are “best practices” to me.

AHHHHHH!

Often this results in me backing out of a job, or leaving if I had tentatively agreed to it already — unless they are just going to pay enough to make watching a project tie itself in knots worth my time.

(Incidentally, I was talking with a guy from Klarna the other day and had the exact opposite experience. They know what problem their platform tackles and why it is a really good idea. So its not hopeless everywhere, just most places. What is really amazing is the guy I was speaking to wasn’t even a developer but understood what their main product is all about. That’s almost a reason to have actual hope for the future of that particular company. I don’t think I’ve written the word “hope” without prefacing it with a word like “unreasonable”, “false”, “sad” or “vain” in an article about software development.)

Today there is a problem with methodologies infecting and then blinding software projects (foss and otherwise). Its like competing flavors of ISIS taking over the ethos of various management and teams while sapping the reason from their adherents. Its not that Scrum or Agile or TDD are necessarily bad — there are a lot of good ideas that can be pulled from them — it is problematic that things like Scrum have become religions. Let’s put that in the big letters:

The problem isn’t this or that particular practice, it is the religion part.
— Me, just now

When it is absolutely unacceptable to question the utility of a methodology or specific coding practice you have a major problem. Selecting a particular set of practices without any regard to the context within which the methods or techniques are to be applied you are simply making uncritical, faith-based decisions. That is like hoping that a man who lives in the clouds will make everything better for you because you move a wooden block back and forth three times a day or kiss the ground a lot.

No, nevermind, actually it is worse than that, because you’ll only lose a few moments of your day moving a little block of wood around and kissing the ground is pretty quick. Neither has to bother anyone else who is trying to be productive right then. It is when you schedule daily or weekly meetings about block-moving techniques, force everyone to take a “vacation/working retreat” (oxymoron much?) to the tune of hundreds of thousands of dollars in company money to attend seminars given by charlatans about ground-kissing, and schedule weekend work time and “fun events” like 24-hour “hackathons” and “weekend sprints” to make up for the time lost in coordinating all the above activities. That’s way worse.

(Note that in the ranty paragraph above I’m not calling all scrum/agile/whatever coaches charlatans. The real coaches I’ve met (who have themselves written successful software) would agree entirely with what I’m writing here and tend to say straight out that chosen practices must match the context of the project. I am calling the seminar circuit and “methodology certification” guys charlatans. Those shitbags have learned that they can make crazy money by telling sweet, long, loud lies to management in a culture desperate for something to point value-blind investors at as a reason to throw good money after bad. Of course, this also implies that quite a bit of tech management is incompetent and most tech investors are just shooting in the dark.)

Without the ability to question a practice it becomes impossible to evaluate its impact on your goals. For example, sometimes TDD makes a lot of sense, especially when the product is a library. Srsly, if you write libraries and you don’t do TDD then you had better have some other word for something that amounts to the same thing. But sometimes tests — especially when they are, by necessity, integration tests of a non-trivial, comprehensive nature — can be a massive distraction, totally unhelpful, and a noticeable net loss to a project (especially project components that are literally untestable before the heat death of the universe).

The choice of a methodology or technique has to be a goal-based decision. Very often this means a business decision but sometimes its a project-goals-and-ethos type decision. Business decisions are the easiest because they are the most straightforward and the goals are relatively simple. It is a bit different in a foss project where adherence to a particular practice might be an underlying goal or a core part of the social value system that surrounds it. But even in a foss project it isn’t so hard to pin down a goal and determine how a particular practice when imposed as a rule will either help, hinder, or confuse the goal.

There is a general incongruency  between the context scrum was designed around and the context within which most foss projects exist. Scrum (and agile in general) is about customer-facing code; specifically in the case where the customer is a paying entity that is inexpert in the software being developed, but the developers are inexpert in the problem domain being solved. That is the primary Agile use case. It works well there — but this does not describe the situation of most foss projects.

Most foss projects are intended to be used by other software developers or techie users (system operators, interface specialists, DBAs, etc.), and are especially focused around infrastructure. In this case Agile simply doesn’t fit. Some documentation policies don’t even fit: there is a lot of blending among the idea that “code should be documented”, “code should be commented”, “comments should adhere to a markup that generates documentation”, “the API documentation is the manual” and “there is a product manual”. These are not at all the same things in certain markets, but in the open source world there are shades of meaning there spanning “the code is the documentation” to “literate code” to “we have a separate documentation project”.

I use foss software almost exclusively for work, but my customers don’t. They have no idea the difference, really, and don’t care over the span of a purchasing decision whether they are getting foss software or proprietary software — they only care that it works to solve their immediate business problem (that closed source sometimes introduces a different, longer-term business problem is not something they are generally prepared to understand the arguments for). In this case I have non-developer users paying for my (incidentally foss) software — and scrum/agile/whatever works very well there as a set of guidelines and practices to draw from when outlining my group’s workflow.

But the infrastructure stuff we do that sits behind all that — scrum/agile/whatever is totally insane. There is no “sit in with the customer to develop use cases” and holding a scrum meeting daily when it comes to network protocols that underlie the whole system, or the crypto suites that render the whole thing safe, or the database schemas that decompose the raw data into meanings relevant on the back-end. That sort of stuff is generally core-competency for foss developers, but it doesn’t fit the scrum or agile methodologies at all.

Only when you are working on a wicker-castle of a web project where concerns are so totally interwoven and mishmashed together that front-end customer-facing concerns become backend concerns does agile make any sense — but in this case it only makes sense because you are shipping a giant ball of mud and your hair is on fire every single day because you’ll never catch up with breakages (welcome to the actual modern paradigm that rules 90% of software projects I’ve seen…).

I’ve poked at a few different sides of development. What I’m really getting at is that there are different worlds of software development, and each world is suited better or worse by different methodologies that have been developed over time. (As an extreme case, consider the lunacy of scrum in most embedded projects.) No methodology I’ve ever seen fits any given project very well, but all of them absolutely work against the interests of a project that exists outside the context from which they originated. That could be because of time constraints (consider the infamous “docs don’t pay” attitude — yet it shouldn’t be dismissed outright because it is actually a valid business concern sometimes), the context of use doesn’t fit, or whatever.

In the same way that we (should) try to pick the best tools (languages, data stores, data structures, network paradigms, etc.) for a given job based on the nature of the task, we should approach selection of development methodology and team workflow based on the nature and context of the project.

We got a different StarWars Trailer in Japan

I live in Japan. The new Japanese trailer for Star Wars that I saw today was not the same as the new English one that I was shown on a website. Huh?

Disney is apparently doing a striptease by varying what they show in different language versions. Sneaky — and probably a really good strategy. As immune as I generally am to trailers, this is still pretty badass. Its Star Wars after all:

In marketing as in sex, it seems, being teased is at least half the fun.

But…

I’m going to be enormously pissed if I actually go to the trouble to see this in the theater out here and it sucks. I don’t imagine it will suck, but that’s the problem with being teased too intensely — once the main event has begun all that teasing just leads to a huge letdown if she’s only as exciting as a pretty pillow (yeah that’s a real thing, with its own wikipedia page…). Too much anticipation can make an otherwise pretty good experience seem cheap.

I really hope this isn’t Episode I all over again.