OpenCore/Split Licensing: You Can Do It Wrong

Tarus Balog comes out with another salvo against what he calls Open Core licensing, and I've called Split Licensing. His general statement this time comes down to:

• Hyperic has a feature that the open source community would like;
• They have that feature in the commercial version;
• It would be stupid for them to take that feature and make it part of the Open Source version.

Ergo, Open Core is fundamentally flawed.

Almost at the same time, Zack Urlocker (M7 Alumni In Da Hizzy Yo!) has a new post where he provides the most interesting clue as to why Tarus doesn't fully understand how you can do it right:

Find a way to distinguish between capabilities that businesses want and individual community members may not even care about. For example, Scott Dietzen mentioned e-mail features related to archiving and compliance issues are really only relevant to larger companies. And as he noted, community members will even support the the idea that if you need those features, you should pay.

My Open Source Cookies stream has hit on this before. Just because one firm chose the wrong feature to be part of their cookie doesn't mean that the whole concept is flawed. That's like saying "McDonalds sells disgusting hamburgers; therefore, all hamburgers are rubbish."

Again, to continue my statements on this:

• Pursuing Split Licensing means that you have to be very careful about what you put in the Open Source vs Commercial versions;
• More importantly, it's a case of constant refinement as you discover some features that you thought were commercial only but should be migrated to the Open Source version;
• Targetting features that are only of use to committed commercial users is the key.

It may be that you have a product which is so generic that you can't come up with something that satisfies the Cookie requirement. If it is, you shouldn't be trying Split Licensing at all. Not every business model suits every Open Source project. Choose the right one.

Calypso Acquires Fail

UPDATE 2009-04-23 at end of post

Calypso has acquired Galapagos. Wow. Where to begin here.

First of all, Galapagos was the premier product from CodeFarm, which was forced into administration recently (administration ~= UK Chapter 11). So you could easily rewrite the above headline as "Calypso acquires assets of failing technology vendor for super-cheap." But PR doesn't work on telling the truth.

But the real question is why acquire it at all? Want to know what Galapagos actually does? I know, as I've used it.

It's a genetic algorithm for automagically producing CDOs, whose primary claim to fame is that it has a license to run the Moodys models automatically. What a growth industry that is these days! And so many accretive customers that will come along with the deal!

So let's play a game. We'll call it Rewrite The Press Release

Calypso Technologies today acquired the assets of a bankrupt firm specializing in selling to a failed market relying on a discredited feature. In engaging in this transaction, Calypso found a way to acquire some developers it felt were talented in a market where it currently lacks an R&D facility, while allowing the original developers of the worthless software a face and reputation saving way out of their current predicament.

Man, I should be in PR and not in the actual engineering game!

UPDATE 2009-04-23
Apparently, they haven't realized this dog don't hunt. They're trying to hire sales engineers to sell it in NYC. Uhm, guys? The structured products market is pretty dead, and if it does recover, it's probably not going to want a genetic auto-structuring system.

Let A Million Brokers Bloom

To me, one of the most promising things about AMQP is that it actually has the potential to radically expand the amount of feature-based broker differentiation in the MOM space, by eliminating a lot of the "grunt" stuff that you have to go through in order to define a new broker model.

Right now, if you want to do something interesting (meaning not commercially supported) with asynchronous message-oriented communications, you have to:

• Define your basic messaging model
• Define the wire representation of that model
• Define your protocol
• Write up the server-side handling of the protocol
• Write up the client-side handling of the protocol for each programming language you need to support

Only when you're done with all that do you actually get to do "the fun stuff," which is to write up the unique piece of functionality that meant you wanted to start on the project in the first place.[1]

Consider a particularly germane example. In my current day job I'm working for a firm (and if you're reading this blog you've heard of the firm) that has a proprietary MOM system with (what I can see as) one USP.[2] Aside from that one USP (which I'm not going to identify), it's just a simple pubsub-based MOM broker. But nobody in the market has that feature, so they can't go with a commercial vendor. And there are facets of that USP that means that no commercial vendor is likely to add exactly that feature to their product.

But in order to get that one USP feature, they have to face every single other hurdle above, and constantly deal with refining every single bit over years and years of development. None of which is about that one USP feature, it's all just plumbing. Everything other than implementing that feature is a waste of valuable development effort.

The kicker? That USP is just a custom Exchange type in AMQP 0-X terminology. Nothing more, nothing less.

And that's the beauty of AMQP.

Once we reach the promised land, someone like my current cash money provider could have just grabbed an existing framework (all the AMQP client work and server-side protocol handling in its language of preference), and implemented the custom exchange (or broken existing ones, or got freaky with queue implementations, or whatever it wanted): no need to reinvent the wheel. AMQP acts as the standardization of all the bits that you don't want or need to care about to provide custom message broking behavior, allowing you to focus all your time and attention to the parts that you really need to implement yourself.

This makes the barrier to entry for unique MOM functionality only the cost to implement the unique functionality itself; you don't have to face the hurdle of implementing everything else required for asynchronous message-oriented communications to showcase or provide one single feature.

I consider this to be the messaging version of the story behind the Eigenbase project: a framework for writing custom brokers. A few people I know (big shout out to my homies John Sichi and Julian Hyde[3]) are excellent at writing "interesting" databases (with special sauce for special contexts). However, doing that from scratch each time means that you're constantly reinventing/rewriting the same old tired stuff: a SQL parser, a transactional data store, a wire protocol, blah blah blah. So they started the Eigenbase project as a way of taking care of all that cruft that you just Have To Have so that they could focus on the stuff that's special about Their Database.

Are there equivalently architected Framework Brokers yet for AMQP? Not that I'm aware of (please pipe up in the comments if you think I'm wrong). If nothing else, in the message broker/routing space, there are a lot of things that you might want to do to speed up adhering-to-standards mode that break the general programming model you'd want from a framework-based system. That leads me to believe that just as MySQL didn't go framework-based to become Eigenbase, we'll probably see a set of AMQP brokers focusing on ease of programming custom variants, just like Eigenbase is designed specifically around programming custom variants in the database space.

And at that point, I think we'll start to see a lot of new and interesting implementations, some in-house and some exposed to the world.

Footnotes

[1] Alternatively, you can horribly abuse an open source project, but that's going to do nothing but confuse everybody involved (including yourself) and leave you liable to abandonware if you rip out the insides of a system that you're replacing key components on (so if your open source basis isn't designed as a framework, and you replace some of the key message handling parts, the moment the developers change the internal processes you're effectively stuck).

[2] Unique Selling Proposition. But you knew that of course.

[3] Broadbase In Da Hizzy!

TechCrunch Reply: VCs Shouldn't Only Fly To Emerging Markets...

(Context: TechCrunch saying the US is played out in VC funding.)

First off, allow me to correct one thing, about the confusion between high growth and high tech. Yes, VC funding is about high growth. But more than that, it's about exponential growth triggered by a capital infusion, which is what technology investment is all about: pay money down to write software, and you can sell infinite numbers of copies for only the cost of sale, which is lower (hopefully) than the cost of writing it in the first place. Otherwise, you're in Private Equity land, which is completely different.

But let's take the analogy farther. Why do you think that investment is going into China, India, and Israel? China and India are growing middle classes and have indigenous growth markets, as well as a hinterland (SE Asia for China, Pakistan/Bangladesh for India). What about Israel? That's the one that teaches you something illustrative, because I don't think anybody would really assume that Israel is very well able to effectively do business with its local hinterlands (for a variety of reasons I don't think I need to spell out here).

Israel tells the whole story of why the others are there: lots of skilled engineers who can't/won't migrate to Silicon Valley, and a culture of entrepreneurship.

Hmmmmm.....that sounds familiar..... Oh, wait, now I remember why!

So taking the TechCrunch approach, here's why London is somewhere else you should consider:

• Growth Industries. Remember, London is able to service as a financial and technology centre all of the expanded EU. You think Romania isn't a potential target for growing in transport, consumer goods, all that?
• Immigration Issues. Again, London draws from all over the EU already, and we also can't make it to the US.
• Stable Regulatory/Legal Framework. Okay, so this is a little different than it used to be given regulatory chaos everywhere, but we have an excellent legal framework and strong property rights and laws that understand and can defend against violations of intellectual property.
  
• Bonus: You like London. Okay, let's face it. You're a rich VC. London's very very suited to taking money from super-rich people. Why do you think we have so many Arabs and Russians and other assorted billionaires here? Because we're good at providing avenues for you and your significant others to spend money on a regular basis. Bangalore? Not so much from what I hear. [1]
  

If you're looking at Israel, you should be looking at London.

Footnotes:
[1] Yes, I know I'm incredibly oversimplifying. My point here is that London caters to literally hundreds of dollar billionaires on a daily basis; Bangalore, Tel Aviv and Guangzhou don't. They're getting better, but London's been a billionaire plaything (to a point that makes it impossible for those of us not in that level to live well) for at least a hundred years, and it shows. Trust me, you don't want to have those problems.

Tervela Joins AMQP Working Group

The Press Release. No, it's not on the formal AMQP Working Group web site yet as of my writing this.

I think this is really promising, as it's the first hardware vendor to have formally signed up to join the AMQP Working Group (despite my prodding of Solace to do so). I hope they manage to produce a full hardware implementation of the spec!

It also continues the industry's relentless march to where I believe is its destiny:

• Open Source
• Cheap Appliances
• Custom Hardware
• Cloud Provision
• IBM

If you're not one of those 5, figure out how you can be, because otherwise you're in the downward spiral. If you're paying someone not one of those five, start working on your exit strategy before it's too late and you're paying ground rent until the end of time for a second-rate solution. Don't migrate yet, but have your plan in place.

Update: Here's the Official Tervela site press release.

Designed for Deployment Reliability

I was reading an interesting article on Designed for Reliability on The Daily WTF [1]. And then I started reading the comments. I think a lot of people don't get it.

The real story here (at least to me) is that because the system is so reliable, deployment rules are never done and enforced assuming that it might not be. It's a classic problem, because good deployment rules are hard. If you can keep things up and running, you're better off treating the problem as just maintaining the system, but eventually that just plain old fails. It always will. [2]

Ultimately, any system that hasn't had constant redeployment baked in is going to face this exact problem: the machine exploded, OMFG, how do I get it up and running? For one of your larger distributed systems, could you do that particularly easily? More importantly, have you actually tried?

My contention is this: if you don't design your processes such that you always have a reliable deployment story, your super-expensive hardware/system is worthless. Things always, eventually fail. You have to be ready for it.

Annual Power Down

One practice that I think is useful in a variety of ways is the annual power-down. In some areas of London (and in this I don't know whether it's a requirement all the time, but it's happened to me at two different locations, one in the City and one in Westminster Council, so it appears to be widespread), you have to switch off all electrical power to your office block once a year so that it can be tested and inspected. And that's absolute: no UPS, no diesel generators, you really do have to switch the machines off.

Luckily for all, this is scheduled. Beforehand, everybody who maintains a system that's run in the affected data centre scrambles to make sure that the stuff they support is likely to get up and running again without them doing any work. Mostly this is because the power's gonna come back on early Sunday morning, and if they want to party the previous night, they better make damn sure they're not getting woken up at 9:00 am Sunday morning. Startup scripts are checked, internal consistency of the system is checked, checklists are updated, everybody does their part.

It still won't work of course, which is why there are so many people on call and ready to help nudge their particular part of the world back into operation (if nothing else, hardware that runs full-bore 364 days of the year often picks power-up as a time to fail, so make sure you've got a lot of spare disks and power supplies at hand), but the discipline forces you to, at least once a year, make sure that you can get up and running before Monday morning.

Thus if something catastrophic happens, your scripts are on average 6 months behind (and we all know that's worst case: everybody pays attention to the lessons learned for 3 months after the power down, and everybody starts to get ready 3 months before hand, so worst case is you get caught right in the middle well of apathy), but you should still be able to get up and running with a minimum of fuss.

In this case, the annual power down is part of your methodology to ensure that you have a reproducible deployment system.

Can The System Help You?

So let's say you have a system that is designed to make it extremely easy to make runtime changes that would affect your ability to bring the system up and running again in the case of catastrophic failure. What might you do to help fight against this tendency? I think the only solution here is one of two cases:

• Run every change through an external system that keeps track of what is done and potentially allows replay. Note that for this to work, every change (no matter how minor) must go through The System; this essentially prevents developers or support staff from being able to log into the box at all, because everything has to be tracked (though you could maybe get around this these days by just having some type of logging SSH shell or something).
• Have the system self-maintain. In this case, the system maintains in some stable form (backed up disk for example) the exact configuration that it currently has, as well as perhaps the last N changes, so that it can be brought back to a consistent state quickly in the case of catastrophe.
  

The former has the advantage that the system doesn't have to know what's going on, the latter has the advantage that the system can be written to handle just this situation and not have to log unnecessary trivia.

The latter is actually easier than you might think:

• Your VM (in the case of Erlang/OTP) might write out the state of all directly launched processes (as opposed to software launched ones) so that it knows the location and state of all code used to kick off the system;
• Your container (like OSGi) might silently copy all bundles to a WORM location when loading so that there's an accurate record of what was running at any given point of time;
• Your OS (ZFS FTW) might snapshot the state of the system any time something interesting happens so that you can go back and recover gracefully.
  

The Cloud/Utility Computing Take

So given that I think most systems are ultimately moving to Utility Computing (in-house or out in teh Cloudz), does that help you or hurt you in this case? Help, majorly.

Here's a good test: If You're Ready To Run On EC2, You're Done. Whether or not you're going to deploy on EC2, surviving the semantics of EC2 means you're ready.

The rationale here is simple: the semantics of EC2 require that your system be able to deploy at any time. Sure, you can log into a machine and poke around with it, but you're designing for N-way scalability, remember? If you do that, and you don't fork a new AMI with your changes, you're screwed.

Now that means that you have to spend a lot of time working on your AMIs to make sure that for any given production iteration you've got a reproducibly deployable set that represents the state of the universe for that iteration. This is a problem, and I know that it's caused some people trying to integrate with EC2 no end of woe, because it adds a lot of troublesome, time-consuming grunt-work that they're not used to and can't be made to go faster easily. [3]

But by going through that effort, you know that your system is always ready to handle any given node getting cycled at any time. You know that you're consistently ready to deploy.

Think of it as the deployment equivalent of a test-infected culture:

• Testing and Cloud Deployment both institute costs (development costs and configuration costs accordingly)
• Testing lets you develop faster by making sure you're confident that your system is always working
• Cloud Deployment lets you support faster by making sure you can always bring the system up consistently in a crisis

See the parallels here? Up-front costs (development and configuration) lead to long-term reduction in those same costs by making the process consistent and reproducible.

So even if you're not going to deploy on anything other than your local hardware in a non-virtualized environment, pretending that you are can still reap some benefits. [4]

Conclusion

Design your systems and processes for reproducible deployment. If you don't, I guarantee you that the time you discover that your system can't come up without 3 days of hacking will be less than 24 hours before a major regulatory driven deadline.

Footnotes and Tangents

[1] Yes, this is an old article, but I started writing this a long time ago and am only now finishing my writeup. Yes, I have a whole lot of stuff that I think of a take on and never get around to finishing.
[2] In the Erlang/OTP community, this is definitely seen as an advantage: OTP makes it really easy to replace existing code in a running VM without taking anything down, so you can conceivably have a particular VM that's running for years. Read this post on Vinoski's blog for some classic Erlang insight.
[3] Systems like ElasticServer (from CohesiveFT) can help a lot here, because you can do your round-trip testing on VMWare on your workstation, and then just dump out the resulting images in AMI format rather than VMWare format when you're done.
[4] This isn't something that I've actually run a proper evaluation on, aside from designing distributed systems designed to come up and go down hundreds of times at a go for continuous-integration-driven testing. I'd want to run a formal evaluation of the benefits of virtualization configuration as opposed to test-driven rapid configuration to make this more concrete than just a rant.

Powered By Cloud Rundown

I had the privilege of chairing the Powered By Cloud Privacy, Regulation, and Security in Cloud Computing session last week.

While the snow shut down all of London, and the entire schedule had to be juggled to handle the complete failure of London's transport system, Tim Jackson and the rest of the crew did an amazing job putting together a two-day conference over the two worst weather days of the year.

I had the privilege of chairing the session with:

• Miranda Mowbray of HP Bristol
• Paul Massey of K&L Gates
• Brian Reale of Colosa, and
• Richard Sykes of Intellect

We each had our own take on the subject (Paul talked about regulation and international boundaries, Miranda talked about general concerns, Brian talked about licensing, Richard gave some general comments), and I think it was a pretty great conversation for all involved. I could tell by some of the questions at the end from the audience that this particular subject really is critical to the Cloud adoption community, and hopefully we shed some light on the concerns and the state of the art in the space.

My talk in particular was about how regulations, particularly in financial services, don't explicitly state that you can't use any particular Cloud-Sourced service, but, rather, that interpretations of principles-based regulation cause your internal or external auditor to disallow things that you really should be able to do. Basically, you can use Cloud Computing in IT, if you're willing to stand up to the auditors who are just focused on bureaucratic box-checking.

Slides (short, as we each had 10-15 minutes on our own):

Powered By Cloud 2009-02-03

View more presentations from KirkWylie.

Blaine Cook, Northern Ireland, and London Tech Scene

(Context: Blaine Cook talks to some Times hack about the Northern Irish tech scene).

The Delaware Thing

First of all, allow me to correct the conception that people incorporate in Delaware because it has no corporation tax. This is fallacious, though it has a basis in history. It used to be the case that a corporation's state of incorporation did affect its taxes in a meaningful way. At that time, Delaware attracted a lot of incorporations due to tax arbitrage.

More importantly today, there is a lot of law that depends on your state of incorporation, because of the Federal system in the USA. Therefore, since there used to be so many firms that incorporated in Delaware for tax reasons, there are a lot of judges and precedents and case law in Delaware, so lawyers in other states all know Delaware law on those matters more than their local law. Therefore they recommend their companies to incorporate there, because it makes the playing ground far more level and understood.

Nothing to do with taxes these days, which are based on your legal nexus and primary business sites.

Sorry, every time I read something like that it makes me want to smack the urban myth out of people.

"Does Nothing Work In This Country?"

I feel like I perpetually channel the spirit of Darcy's fiance in the original Bridget Jones Diary film by saying to myself "Does nothing work in this country?" The UK is the country in which nothing works.

Case in point:

That was the view from my back window on Monday. That's a good 4 inches of snow. That effectively shut down the entire London transport system for over 24 hours, and led to at least 2 days of severe system-wide delays.

4 inches of snow. That were fully expected (BBC was reporting it was going to happen at least 12 hours in advance, yet no road gritting/salting was done in advance). That shut down everything.

I showed this photo to my sister living in Chicago. Quoth the sibling: "NOT IMPRESSED!!!!!"

Another case in point: Broadband/cable. There's now one cable operator in this country. Who refuses to lay any new cables anywhere (you don't have cable in your neighborhood? Too bad).

Yet another one: Every Monday the whole public transport system is delayed. Every single Monday, because the weekend engineering works always overruns.

The Bureaucracy Thing

The UK's bureaucratic culture doesn't appeal to Blaine. And it shouldn't. It's retarded in so many ways. Let me give you a few examples:

• For me to start my most recent job contract, I had to provide to 3 different parties the exact same documents, that they all had to individually verify and copy: my passport, my visa, a recent bank statement, and a recent utility bill. I had to run to 3 offices to do this, and it took more than a full day of my time.
• If you ever move to the UK, do not ever forget when you moved in to or out of a particular location. You'll be asked more times than you can imagine for 6 years of addresses, with month accuracy on moves.
• Like many USAmerican men, I use my middle name, exclusively. Don't even write out the first initial anymore. This is fine in the states; here, my first name must show up on everything: utility statements, bank accounts, credit cards, the lot (remember, they all have to match up perfectly, or you'll end up in a situation like I have now, where ING Direct refuses to link up with my HSBC account because the first initial isn't on my ING Direct account, and refuses to accept anything other than a Certified Copy of my passport as evidence, even though they already have a certified copy of my passport on file).
• To be able to drive here, I could have paid my money and exchanged my US driver's license for a UK one. Except that I would have been able to get an automatic only one, and nobody has automatic transmission cars here, which makes the license useless. So now I have to actually go through the whole process starting from provisional license from scratch.
• To get that provisional license, I had to mail my passport to the DVLA in Swansea. The original. There is no alternative to this if you're an American. I couldn't even get on a train there and show it to them in person. They refused to send it back any type of recorded delivery.
• When I moved here, I could put lots of money into my UK bank account, but not get a cheque book or debit card or anything else. All I could do was get small amounts of money out of my account at a Citibank ATM (no others). That's it. But I had to sign up for that so that I could sign up for anything else, because otherwise I wouldn't have a bank account statement going to my home to show everybody else to prove that I'm a Real Person. Finally getting a job allowed me to have a cheque book for the first time. For a year I mostly used my US credit cards (like Blaine).
• Grocery shopping after 4pm on a Sunday? It is to laugh.
• Evening/weekend opening hours for any type of call centre? Nope (and since they're in India, there's no reason for this other than spite).
• You want to do anything at all to your home's exterior? Be prepared to run the planning gauntlet, a system that appears to be explicitly designed to stop anybody from doing anything at all until the end of time.
• When moving into one borough, and attempting to get a parking permit just to be able to move in, we had to go to 3 different local government offices on the day we were moving. The best part? At the parking office, we were told we had to go to the local taxation office because we didn't have a piece of paper they wouldn't post until that day (because we hadn't moved in yet, and thus hadn't triggered the taxation), even though he could see the relevant information on his computer. Best part? He didn't do anything with the paper, he just had to check a box that he had seen it. The local taxation office has a special window just for this.

Unlike Blaine, I've been here 5 years, and this stuff still makes me mad enough to scream at people.

None Of This Matters

Yes, as a USAmerican, it makes us want to rant and rant and rant. And that's a great topic whenever we expats get together and celebrate that most English of traditions: drinking yourself into oblivion on an empty stomach on a week-night.

And yes, every time I go back to visit San Francisco, I sit there and say to myself, "Self, what the fark are you doing living in London, where nothing works, where there's bureaucracy stifling you at every step, where due to the exchange rate you now earn less and where the weather is atrocious?" And then I realize that even if I didn't have family (like Blaine) keeping me here, I'd probably stay.

None of the bad things matter. London is still, no matter what:

• An insanely vibrant, multicultural, safe city (Daily Mail and Evening Standard: shut up; until you've been to a properly dangerous city, shut your pie holes);
• A city that draws talent from three of the best universities in the world (I mean, they're no Berkeley, but I guess Cambridge, Oxford and Imperial are okay for what they are);
• A city that draws talent from across the entire EU (Blaine: most of the best Polish engineers I've seen are in London at this point; the Polish-in-Poland firms are competing against India, not London), none of whom can move to the states anymore;
• A city with the best flight connections of anywhere in the world (there's virtually nowhere that's close enough that doesn't have at least one nonstop flight running from London to it);
• A city that, no matter how hard the Luftwaffe and 60s Architects and Maggie and Red Ken and everybody else has tried to kill it, just won't die.

After everything politicians have done to either actively destroy London, or to neglect it into oblivion, if this were America you'd have Europe's Detroit. You don't. You have London.

And that's why I think that if you can change the perceptions of the people who are already here, you can get a real tech industry going.

My advice to Blaine is:

• Keep ranting. Only way to stay sane.
• Do it down t' pub with other USAmericans when you come into London.
• Don't do it to the press. :-)
  

Big-Agile Is The New RUP

Some of you who follow Joel, even if only to comment that he's largely irrelevant these days, might have found this coming a bit out of the blue. Why would he make a blog post just to have a partial transcript of one of the StackOverflow podcasts?

And then I found this beauty. Wow.

Turns out the transcript on Joel was specifically because he believed that the Big Agile guys were (intentionally or deliberately) misquoting him. Some really exceptional bits from the article and comments:

Joel said that the SOLID principle aren’t “agile”. (sigh). Everybody and his uncle thinks he knows what the term “agile” means. But I’m the guy who called the meeting where the name “agile” was picked. I’ve been writing about Agile development since the term Agile development was created. I think I know what is Agile and what isn’t. And I think I have the authority to override Joel on this one. Joel, the SOLID principles are agile.

Wow. Appeal to Authority much? Oh, wait, then someone calls him out on it. Here's Uncle Bob's response:

“But I’m the guy who called the meeting where the name “agile” was picked.” Appeal to Authority is a fallacy.

Not in this case, since I am one of the authors.

Wow. It's as though he actually doesn't understand what "Appeal to Authority" actually means. He seems to quite legitimately believe that since he was one of the original people who coined the term "Agile" he can define precisely what that means for the end of time.

Let's look back at my original purity vs. pragmatism post. Now let's look at the comments on Uncle Bob's post. Remind you of anyone?

Agile Is The Anti-RUP
The original motivation of Agile Methodologies was to get away from the RUP and other similar staged-delivery software engineering/delivery methodologies. The RUP is a big, rigid waterfall model that pretty much guarantees that your project is going to be a late failure. Each step is rigorously enforced, and you can't move from one step to the other until you've completed all the requirements. Furthermore, all the outputs are rigorously defined so, for example, you must have UML Class Diagrams (and no other type of diagrams) before you can commence coding.

However, even though anyone these days could look at the RUP and instantly see that it had to be a great big failure, nobody had a Name for what all the effective techniques that weren't in the RUP (or were completely diametrically opposed to the RUP) were. So when people who are extremely respected started saying, "Hey, you can be more successful by ignoring the RUP and doing it this other way" people loved hearing that. People gave these new Agile Methodologies a try, and even bought into the ones that were packaged as a cohesive, brand-name entity (because the only way to compete with a single-named overarching methodology is with another one: RUP vs. BSDM, XP, Scrum).

The best part was that "agile" was just a set of generic techniques that you could pick and choose from and still get some credibility. You could easily define what you do to someone by saying "yeah, we're big on CI and unit testing, do 4 week spikes, and have 2 people sitting on the business desk" and someone would understand what you're doing, and say, "hey, that's pretty agile."

Big-Agile Is The New RUP
Nowadays, that's not true. Let's look at some of the problems I see with the Big-Agile community:

Arguments From Authority. I'm sickened by someone saying "I alone have the right to decide what is Agile and what is not Agile because I am The Authority." No, no you don't.

Argument from Authority only works with factual statements: "I was in the room when Martin Fowler's head exploded, therefore I am an authority on whether Martin Fowler's head exploded in that room." It doesn't work for an argument of opinion.

You definitely get some kudos for being in the Agile world for that long, being a generically smart guy and by really helping the community grow. But that doesn't give you a trump card you can just unzip and slap on the table.

Simple Becoming Rigorous. Let's take a very simple concept: write tests before you write the code. Sounds pretty simple, right? Apparently not. Apparently saying TDD means a whole lot of very particular things that if you don't like TDD, you apparently aren't doing. Go back to the Uncle Bob post. Look at the comments. They're conflating concepts (Uncle Bob conflating TDD with having a rigorous testing policy), and not responding when someone makes the most valid criticism of all:

If TDD and SOLID is too obscure that regular-intelligent people don’t get it, then the problem is with TDD and SOLID, not with the regular-intelligent people.

You see this as well with all the people who essentially say, "If you're not using BDSM/Scrum/XP, you can't be Agile."

You're Doing It Wrong. This is pretty similar to Simple Becoming Rigorous, but the basic concept comes back to all the old, original XP arguments: If XP Doesn't Work, It's Because You Did It Wrong. XP will always work by definition, therefore if it didn't work, you failed to do it correctly. Tautology. But you see this all the time whenever someone says "Yeah, I tried Agile Technique X, and it didn't work very well for me/my team," and the response is "that's because you didn't do it right." It's condescending, and it assumes that all developers are exactly the same, and all projects are exactly the same as the project that you've just been on.

Agile techniques are supposed to be so simple that you can't do them so wrong that they don't benefit you. TDD? As simple as "write tests before code." Standup meetings? As simple as "ensure meetings are short by not allowing people to sit down." How do you get those wrong?

One Right Answer.  You tried a particular little-agile technique that you don't like or that doesn't work for you? Obviously you're wrong. That technique is perfect and must be applied in all cases. It never doesn't apply.

Comment The First: "maintaining a system that wasn’t written with SOLID in mind is the opposite of enjoyable." Really? You can't handle working with any system that wasn't developed with your personal architectural concept in mind? They're all rubbish? Each and every one of them? I don't know what SOLID is except for what Joel said. Honestly, at this point, I don't care. If it will warp me and my systems so much that I will never be able to look without hostility at anybody who doesn't use it, it's a virus, and I choose not to be infected.

Comment The Second: "I have never met anyone that has honestly given it a fair trail (20 days or so) and not become addicted for life." Note the use of the term "honestly" to conjoin this with You're Doing It Wrong.

Here's someone who really seems to get it:

Some zealots are giving ahering strictly to dogmatic methodologies (not necesarily SOLID) a higher priority than delivering software and satisfying customers. If your code is incredibly clean, but doesn’t meet the user’s needs, it is useless. Of course, ideally, principles and methodolgies are used pragmatically in delivering software that does meet customer’s needs but I have seen developers forget the objective of the system they were working while obsessing on the details of the implementation.

At the end of the day, nobody cares how high your code coverage is, or how many interfaces your system has, or what mocking framework you use, or anything else. They only care about one thing: are you consistently delivering software of value?

Agile vs. Big-Agile: Game On
I fully expect the Big-Agile crowd will probably find this completely insulting, and rely on all of the above arguments:

• He hates Scrum because he only has a passing familiarity with it
• He doesn't purely rely on TDD because he honestly hasn't given it a fair trial
• He doesn't like Pair Programming because he never did it correctly
• His experience writing use cases down doesn't count because he didn't use the correct size of note cards and didn't use the correct pen colors

At this point, I don't care. Let me put a stake in the ground.

Big-Agile Zealots Are Killing The Name Of Agile Methodologies

I've interviewed with a lot of firms recently, and I actually have to completely qualify the fact that I believe in little-agile methodologies, because at this point, they see the word "Agile" on a CV, and they think that you're TI from the Purity vs. Pragmatism article. It turns them off, because you guys are viewed as ranting zealots.

And you know what, when I then explain what I find works well in the real world with the types of people I tend to work with, they do the same thing and like it. They like agile methodologies, they don't like Agile Methodologies. They just find the Big-Agile crowd all completely unbearable to listen to at this point.

So with that in mind, unless we can get the "little-a-agile" terminology spread, we're going to have to part company, so that Big-Agile can own the now tainted "Agile" terminology, and those of us who are far more pragmatic can have our own word to play with that you can't try to authority-away our rights to self define.

BarCap Standardizes On Solace For MOM

(via Hans Jesperson at Solace)

Usually I don't regurgitate press releases, but I think this one is particularly interesting to my fair readers: Solace To Supply Barclays Capital with Global Standard for Messaging Middleware.

Barclays Capital will use Solace 3260 Content Routers to integrate applications spanning the front, middle and back office. By consolidating all messaging needs onto the new platform Barclays Capital will simplify the current infrastructure while saving on development, datacenter and support costs.

Congratulations to Solace Systems for such a big win! Now if they can get content routing that's based on something less stupid than XML.........

I've said it before, but fundamentally I don't believe that existing commercial broker software has much of a future, as long as a hardware platform (e.g. Tervela, Solace) prices out to roughly the same as Tier-1 hardware with per-core licensing of any of the commercial players. Hardware will win by every metric as long as you're paying the Tibco/Progress/IBM/Fiorano licensing costs. If you're BarCap, why in the world would you pay to roll out Tibco EMS on Tier-1 hardware, when for the same price per node you get something far faster in every single metric, and without the OS maintenance overhead?

The world is going to come down to five major players:

• Hardware Vendors (Solace, Tervela, et. al)
• Open Source Software (RabbitMQ, qPid, et. al)
• Low-Cost Appliances (someone offer it for sale and you'll get customers I think)
• Middleware Services (Amazon SQS and future players)
• IBM (because large banks will never ever in a million years be able to move off of MQ Series, almost exclusively because of the Mainframe problem).

If you're not one of those, figure out how you can compete, because the buckets are pretty clear to me.

Appearing at qCon London 2009

In the event the insane snow (which has currently trapped me into the little bit of South Fulham I call home) is going to prevent you from seeing me at Powered By Cloud tomorrow, you've got another shot.

I'm giving a presentation called RESTful Approaches To Financial Systems Integration as part of the Architectures in Financial Applications track at qCon London 2009.

Presentation Abstract:

While RESTful architectures have attracted a significant amount of interest amongst the architecture community recently, they are particularly attractive in solving many financial services integration problems. Financial services firms have large silos, massive distributed development teams, and face constant pressure to integrate their systems faster and better. In addition, the unique regulatory and user management issues that financial firms face mean that they need to be careful about applying any technical architecture that's widely perceived to be of interest in web-tier systems.

Drawing on his experience from some of the projects he's led, Kirk will present the advantages of a RESTful architecture to develop integrate systems in the financial services arena, in particular how to leverage the types of infrastructure, skills, and systems that these firms are likely to already have. The talk will also cover precisely why a RESTful architecture fits so well in developing and integrating the systems financial firms use. He'll also address perhaps the most important problem financial services developers face: how to make their traders happy.

I hope you can make it!

Appearance Details:
Conference: qCon London 2009
Location: Queen Elizabeth II Conference Centre. (Map Reference)
Conference Dates: 11-13 March, 2009
Presentation Details: 15:45-16:45, 11 March, 2009 (Wednesday), Westminster Suite