http://action.fooddemocracynow.org/cms/sign/stop_the_sneak_attack

UPDATE(April, 23 2010: 12:11 CDT): added link to the documentary I am referring to below (Food, Inc.)

(GMO and OSS - depending on who you are and how you got here, one of these acronyms might not mean much to you, while the other one is very familiar. My goal here is to show that you actually know more about both of them than you realize)

This started as an attempt to understand what I was feeling after watching the documentary Food, Inc. last night - particularly how the issues it raised are similar to software and techology issues (though a lot scarier and much less talked about).

One of these is Genetically Modified Organisms or GMO's. To show the parallels, I've written the following fairy tale (set in the not-to-distant-future) and I'd like you to imagine yourself as our protagonist:

You control a moderately large and successful software security company. One day, you develop a game-changing product, Knock Out Pro ("don't discriminate... eliminate!") that permanently disables any computer it is used against. You successfully market it to governments and big companies ("wipes out botnets, zombie pc's, illegal content servers and all manner of subversive and undesirable computers on contact!") as well as individuals (for "household use only") and it gets widely deployed and used world-wide.

Yay. You're rich. Undesirable computers are being wiped out. You're a hero... and the only game in town: you scored a US patent for your product's innovative ability to do what it does and new cooperative trade agreements have you covered across the globe.

Except - there's this nagging potential for collateral damage when customers actually use Knock Out Pro. (most of) Your customers would prefer to wipe out only bad computers. Problem is, your product is effective precisely because it doesn't discriminate, it eliminates, remember? Your unique, patented genius is precisely that you left all that pesky target evaluation to the customer and focused on removing the target effectively. However customers are spending a lot of time, effort (and money) to ensure they don't target good computers (at least ones they care about) when they use your product and so they're not entirely satisfied.

That's big money being wasted (so far). Wouldn't it be great if they gave that money to you too? Wouldn't it be great if you could just target a whole network, and only knock out the bad computers? But you've been in this industry for a while. You already *have* products that selectively disable computers and they work... kinda. Trouble is, it is really hard to spot a bad computer in a general way: The R&D is prohibitively expensive, the bad computers keep evolving and there's just so damn many different types of undesirable computers out there, that its a much less attractive market (look at how the anti-virus market is going).

Then it hits you: You'll start your own computer company and build computers that are immune to your product! Then your customers (your not worried about anyone else here) will be protected from... well you. But where to start? Well, how about an existing computer design - you could buy one, but that'd be expensive. Besides, computers have been around for a long time now, and there are all these open (i.e. publicly available) system designs and indeed implementations (Open Source Software and hardware and what not) all over the place. You never really got why anyone would freely share something so valuable (bunch of stupid commies) but hey their loss, your gain right? You grab one of those and get to work.

What your R & D team determines is that all it'll take is a relatively, small and easy change. I mean compared to building an entire working modern computer system - all you'll have to do is add in the bit that counters your other product and unfortunately, there's already a fair bit of research available out there for that (in fact you're already engaged in lawsuits trying to supress that information from getting out... thank god for the DMCA).

Wow, in no time, you'll have a whole array of computer products that meet an increasing number of you biggest clients' "good computer" needs. You thought you were rich before? This is going to be Microsoft money, baby.

But wait, now you have a new problem: the change is relatively small and easy, right? The system you're adapting is a publicly available design, those security "researchers" have already theorized about how to block your knock out punch, if you go and release a way to do it, you'll be screwed, right?

Luckily, you already employing a large (and growing) crack legal team and they offer a solution: Patent the countermeasure too! Not one for half measures, you tell them, that's all well and good, but you'd like it better if they just went ahead and patented the whole computer...

(...crickets...)

..."well," the lawyers reply, "That's gonna be kinda tricky. See there's this thing called the 'GNU Public License' and the countermeasure well, its a modification to this computer operating system called Linux, and the license does not permit you to patent Linux (umm, because you didn't create it). The hardware specs have a similar restriction."

You reply that you don't care about tricky, you care about results. And so they go to work as do your lobbyists, and lo and behold you get a shiny new patent on your original computer. Granted, there's still this GPL license to deal with, but with the patent, you figure that you might even be able sue those who wrote it in the first place. And so you build the computer, your customers eat them up like hotcakes, and you step out into grandeur beyond your wildest expectations...

Five years later, and my how things have changed. Sure the big tech companies are still around, but you're in the catbird seat. Some licensed your patent right away. Some (including the linux community) fought back of course, but you've tied that up in the courts for years to come, and now that the founding partner of your favorite law firm was just appointed to the US supreme court, the outcome isn't really in doubt. And sure, people don't "have" to buy your computers, but the are increasingly few places where knock out isn't being run what with the passage of the bipartisan bill: OCTPPCFPA (Online Child, Terrorism, Porn, Piracy, Copywrite Freedom Protection Act) and you have a small army of private investigators working night and day to figure out how those few businesses that aren't licensing your patent are getting away with it.

In short, the general consensus (according to anyone who matters) is that technology is entering a golden age - there are almost no bad computers any more... at least in the US and even the movie and music industries are starting to think the worst might be over for the whole piracy thing. The Internet-wild-west days are finally coming to an end and everyone has you to thank for it. Granted, there are some 3rd world countries where things are still wide open (and worse your products have been pirated), but fortunately they are largely walled off from the networks used by the civilized world... for now. Granted, the threat from them is real, and must be dealt with..., but seeing as how you've got the inside track on becoming the new cyber security czar (after all you are the expert) the future is looking bright indeed...

Well, then reconsider our little fairy tale, but this time, instead of computers think plants and instead of "anti-botnet software" think herbicides, and instead of patented computers think patented genes.

That's right, plants that humanity has cultured and shaped for thousands of years (what's more open source than that?) have, in the last 20 years become proprietary and monoculture. Don't believe me? Watch the movie. It names, names. (I don't have that kind of legal budget). Or go read this: to see what's happening right now.

In short, the real harm I see in GMO's is not the health concerns, and other bugaboo disinformation that one generally hears in what little public discussion goes on about this stuff, but in the much broader and fundamental risks that what once was the Intellectual Property of the human race - the result of 10,000 years of cultivating crops - and all the value created by it, as well as the freedom of our farmers, and those who buy what they produce (i.e. ultimately all of us) has been taken right out from under noses, and those doing the taking are defending their actions on the grounds that it would harm their investments and bottom lines (when they bother to defend it at all, most of the time they just push everyone out of the way).

Frankly, until yesterday I would've thought my fairy tale was the more plausible scenario.

If this is your situation, here's what you can do:

1. Install MIT Scheme. Follow the install instructions here. If you try to run scheme from command line you should get an error saying that it can't find libmhash.so.2
2. Install get libs
3. Now use getlibs to install the ubuntu libmhash packages (e.g.):
   sudo getlibs -p libmhash-dev libmhash2
4. Type scheme at a command line. You should get a prompt

That's it, scheme should work now (or at least start - I haven't moved far beyond this yet). If you try this and run into an issue leave a comment, and I'll update the article and/or see if I can help.

Comparing the US primary and secondary computer curriculum to "shop class" is an insult to shop classes - not just because computer curriculums aren't any good at teaching a trade (though that's part of it), but also because "learning a trade" should not be the goal of teaching computers in school anyway.

Tellingly, the phrase that drew the most negative comments was the quote from Janis Cuny, program director from the NSF, stating that the goal is "to teach the magic of computing." That line is what gave me hope that curriculum planners might finally be getting it; because those who really know computing know that this stuff *is* magic - the kind you can actually do.

However a world with too much magic and not enough knowledge is very risky and dangerous - ask anyone who weighs the same as a duck.

This isn't specific to computers of course. As has been said before, Magic is simply craft from the perspective of the ignorant. The concept of magic can't exist without ignorance. That's why encountering something magical evokes two otherwise opposite reactions in us: A sense of newness and wonder and a sense of dread and fear. When you consider what technology is, both reactions seem so natural as to be almost biological.

Technology (craft/science/etc) is leverage - it is fundamentally the knowledge of how to do something that before was difficult or seemingly impossible. Its not the goal that's new, its the technique or the mechanism. We ate before fire, we moved before the wheel, we killed before we invented swords. But we ate better after harnessing fire, we moved faster with the wheel, and we killed... well we seem to always have been good at finding ways to kill, but nonetheless, its not the what: the eating, moving or killing that's new, but the how.

And doing things more efficiently (essentially what leverage is) confers a survival advantage for those who have it - they can do things better, faster, cheaper, etc. This makes it is easy to see how those ignorant of new technologies would find them magical and both terrifying and wondrous at the same time. "They do the impossible! Run! (But, wait I want one...)"

There is another sense where technology is leverage: It can result in a tool (talisman) or technique (incantation) that others can use to gain the benefit without requiring all of the knowledge needed to create it in the first place. This is efficient because many individuals in a population gain the benefit of a small number of individual's effort - and its been a key fuel in the rise of various cultures and societies. But there are limits to this second form of leverage: If the talisman (tool) breaks, or the incantation (technique) is used in a different context, the benefit is lost, and the user - not having the actual knowledge - is stuck.

So, as long as there has been technology, there has been those who can create it and those who can only use it. And as this is an inherent benefit of technology, it is not something to be done away with, but to be balanced. We in the US are woefully out of balance.

Which brings me back to the article. Computer technology is a lever that allows us to accomplish goals that were previously very expensive, difficult or seemingly impossible. To those ignorant of how it works (all of us at some point), it is truly magical and that either frightens us or fills us with wonder (or both).

The time has come to stop quietly accepting the mistaken - yet popular - notion that education is primarly about getting jobs. The purpose of education is to make us better at using the collective knowledge of the human race in all areas of life. Yes, this includes our jobs, but it also includes raising our children, being informed citizens, managing our households, enjoying our leisure time, and just being good neighbors. Education should be to make us more effective at life. And as a powerful, new and poorly understood technology, computer education should be central to our learning experience, not relegated to some goofy-ass 'business education' electives that look like rehashed typing classes or arcane math electives that only nerds would sign up for.

Instead, we should be nurturing that sense of wonder - and lowering the fear. Explaining the basics (its what BASIC was created for in the first place) so that computers aren't mysteries but tools. To do this, the direct goal of primary computer education can not be seen as preparation for an IT-related job, but lowering the average amount of ignorance regarding how computers work so that in every facet of life where the talismans and incantations of computers are present (most everywhere) there is less mystery and more knowledge of how they work. The result is more appreciation for their capabilities (and their limitations) so that everyone can use the technology to do whatever task they are doing more efficiently.

That some will get the bug and want to create those talismans and incantations themselves is certainly a worthy secondary goal, but (and in this I speak from experience) we don't need to make that an explicit goal. For those who are willing to put forth the effort, the lure of working magic is its own goal - it doesn't need to be imposed on them. That's not to say that teaching computing (esp. programming) as tradecraft is a bad idea, but it shouldn't be the focus of general primary and secondary computer curriculums. *Everyone* needs to learn the fundamentals, right in the core curriculum along with math, science, reading and history.

We remain a culture of ignorance at our own peril. History shows us what happens when knowledge retreats and we become content to simply use the magic: first the few begin to control the many; then the many begin to first fear and then hate the magic and those that understand it; fewer and fewer know the technology and so it is lost as the talismans break and the incantations are forgotten. We have a term for this process: its called entering a Dark Age. Here's to hoping that in 2010 we move toward the light.

UPDATE: (This article on being action oriented in startups mentions its better to hire a lot (recognizing and letting the bad ones go quickly) than to analyze carefully and only choose the good. On the face of it, this seems to be counter what I'm saying here. However, the reason why hiring those talented, but motivated primarily by their desire to see their tech vision realized (rather than your business plan) is that it is really hard for non-technical people to recognize such people as bad hires until they've failed to deliver on the plan. They'll seem like they're really doing good. They'll tell you all about the great plan, and how it uses the best solutions that [insert hot tech company here] used to win, and so forth -- you just won't see your plan move forward while they find the best way to integrate cool scripting language du-jour into their system. The solution is in the article: force them to deliver results quickly and fail fast. The truly good ones will welcome the iterative nature of your business plan, the others will fight against such accountability. Boot them.)

A recent tweet led me to this article by Daniel Tenner from a couple of years ago. It outlines some things people (particularly non-technical people) should look for in order to hire really good programmers.

I think the list is dangerously misleading, because the items in question while possibly* necessary are definitely not sufficient. Worse, a non-technical person who follows this list - and chooses the wrong person - will hire someone who, not only will fail to deliver value to the project or company, but also someone with the capacity to do the endeavour massive harm; far more damage than what an average, or even poor programmer could cause.

Why? Because the list may enable one to identify smart technology enthusiasts, but it will not help with finding someone who delivers great results. To get that, you need someone who won't put gratifying their ego ahead of team and business goals - and unfortunately the list Daniel provides not only describes good programmers who deliver results, but also smart, self-centered egotistical ones too.

To summarize the list Daniel feels that "good" programmers are ones who are smart, passionate about technology, love to program and learn on their own, would (and have) done so outside of work, are knowledgeable about many disparate technologies and uncomfortable using technology he/she does not feel to be "right."

See the problem? What's missing: Will care if your project succeeds. What's present: Does this for his own ends. So what happens when the business plan calls for the "wrong" solution (e.g. because the "right" will take too long, a common problem in start ups - particularly when a less-than-optimal solution was proposed early on and will take too long to change). Without the humility and emotional maturity to compromise his perfect vision the good programmer that Daniel describes might well decide that the business plan is less important than his design vision - and wreck a project that was only somewhat sub-optimal.

To be fair, Daniel is replying to this article by Paul Graham and is attempting to distill his experience with finding good programmers. Paul has his own agenda (as Giles Bowkett points out** here) but both are trying to answer the question: How does a business person find good programmers. In this case, I think Paul's closer to the answer (he feels they can't). Daniel's list seems obvious to him (and to me) - but then we are both programmers. Daniel's answer to this is that he has been on the business side too. So have I - I've managed technical and non-technical projects and people (both well and poorly) and in doing so, I learned an important lesson: Non-technical people not only don't understand the difference between say Java and C#, they don't even understand whether they are comparable - and more importantly they don't care! What they want is someone to implement their business plan. They often want the best (or think they do, which is the same thing for our purposes now), but they assume that best means "best at implementing the plan" - Daniel's list will give them "the best at using the technology." That disconnect carries in it a huge risk; one bigger than hiring mediocre programmers: Because they are smart and so good at using technolgy these guys can and will greatly influence the course of the effort. If they are more interested in feeding their technology passion than implementing your business plan, they are in a position to drive your effort off a cliff, like no mediocre, passionless programmer ever could.

So the programmers business people really want are those really good at shipping technological solutions that implement business plans. How do you find those guys?

In my opinion, there's only two ways to find such talent: Know them already or get lucky. And there is only one reliable way to know them: You or someone you trust needs to have seen them succeed (in business terms) and they need to do it a lot - I'd say at least 90% of the time. You know one of these guys? Hire them - and their network of colleagues, now. Complement them with some junior programmers that know how to learn and want to (i.e. Daniel's list is much less risky for junior programmers, but you're better off finding those that have a track-record of shipping and let them hire the junior programmers).

If you don't know one, you're going to have to roll the dice. But you can still reduce your risk somewhat. And yes, Daniel's list will help you narrow the field. But you still need a sense if they'll care about your business plan. To do that add the following to your interview of Daniel's ideal candidate - it still won't be a sure thing, but it should help: Ask them how their projects went. Did the project ship? How late? How much money did it make? If they were part of a start-up, ask them how it did. If it failed, why did it fail? Then, listen carefully to their answers. If they don't seem interested in such questions, its a red flag. If they only talk about technology its a red-flag. Either way, they are likely to say they built (or intended to build) the ultimate solution. The ones you want to remove from consideration will tell you how all the 'others' got in the way. How management blew the opportunity, how the stupid (they might not use that word, but don't be surprised if they do) programmers who got there before them made all the wrong choices. If they shipped it will have been only because they were able to silence the nay-sayers and take control. The ones you want will mostly have found a way to ship anyway. They'll be focused less on how the others got in their way, and more on how they stayed focused on the business goal and made it a success. The ones you don't want will tell you about how others (almost) ruined it. You may even hear how they finally outmanuevered them and got hold of the reins - but ultimately the stupidity of others will be why he couldn't pull it out and so the product/project/start-up didn't make it. The ones you want will tell you how those things are just a part of shipping software and how the team/company/business (not just them!) found a way to win anyway.

In short: Daniel's list will point you at the technologically talented, but be sure to establish that they also care about your business' success, the risk if they don't is much too high.

----
*I say possibly because I am increasingly of the opinion that when programmers say "good programmer" it means "someone like me." For the record, I agree with Daniel's list - but then I started out on the Commodore 64, will talk endlessly about coding, make a habit of learning about anything and everthing and so on - i.e. that Daniel and I have a similar list may well be because we have a similar background and not because we know anything about being a good programmer.

**I find this post by Giles very uncomfortably true. Which means, you should be looking for my personal agenda in this blog entry, and not for any truth. I'd like to dub this Giles' Rake - because it's easier to see the point in Giles' blog entry than by reading the 700 or so pages of Stephenson's Anathem to get the reference to Diax's Rake

In reading the interesting discussion between Julian Birch and Ryan Svihla here, here and here on Bob Martin's SOLID principles in dynamic languages. I had many thoughts; variously agreeing and disagreeing with what I was reading, till eventually I realized that I couldn't characterize my take on the discussion in those terms. Rather, I felt like Julian and Ryan were using a different language than me that happened to use the same words.

So I decided to explore the idea myself to see if I could get at why I feel that way. I'm going to focus on only one of the SOLID principles they discuss: ISP or Interface Segregation Principle as they discuss it quite a bit (if this SOLID stuff is new to you take a couple seconds to read Bob's definition then come back... OK? Moving on...).

Here's a summary of Julian and Ryan's take on the ISP in dynamic languages:

Ryan:

Ryan seems to see ISP as an implementation design tool that we apply when programming - at least in non-dynamic languages, because we get 'it' for free in dynamic languages - to better understand our code and reduce our work in implementing Interfaces (note the big 'I').

Julian seems to agree in that ISP is something that we can't avoid doing (for better or worse) in dynamic languages:

Julian:

Now, one thing that struck me is that neither of them described the problem. SOLID (and so ISP) are design principles, so presumably there is a design problem that we're trying to avoid by adhering to it. Julian and Ryan seem very familiar with SOLID so I assume that's why they leave it unstated (though Ryan implies that its related to defining and understand interfaces), but I think its key to understanding why I feel we have different understandings of ISP's applicability.

So let's look at what Bob says the problem is (from the Engineering Notebook article linked to above):

Get that? According to Bob we are trying to reduce "spooky action at a distance" type dependency problems in our code-base. If ISP does this, then according to Ryan and Julian when I work in Ruby (as I am now) I should not have code dependency issues related to multiple clients using the same code (as I did when writing C++ or C# code) because each client inherently gets its own custom interface via the magic of duck typing.

I.e.: Duck Typing makes it unnecessary and even unmeaningful to think about ISP when writing code in dynamic languages as we get its benefits (easier to understand and maintain interfaces) for free.

Now, I'm pretty sure I disagree with this and for two reasons: 1) Nowhere is it established that we get the true benefit of ISP - dependency management - for free, and 2) I'm not convinced duck typing absolves me of having to worry about how multiple clients interact with a single piece of code.

[this is going to take longer than one blog entry to explore, so I may return to these two items in follow-on posts]

But in a larger sense I think the fundamental disconnect lies in how I view the importance of the (necessary) context of Uncle Bob's examples. OO and these principles evolved in statically typed languages, so the thinking about how to apply them evolved that way too. As such, Interfaces (i.e. language constructs) are used in examples and solutions and testing via them has over the past 10 years become the most concrete way of showing improvement.

However, I believe that ISP doesn't only apply to Interfaces as language constructs, but also to interfaces as definitions of interaction. If I'm correct than ISP is applicable not only to Big 'I' Interfaces, but also to public method definitions, protocols, even data interchange, schemas and log files.

And this makes sense if you recall that in the SOLID article Bob starts out talking about Structured Programming and OO - and why those two movements began in the first place: to manage code growth. Code written in dynamic languages has to manage these forces as well. That they take on different character is not to say the principles no longer apply, but that the implementation patterns don't. Perhaps in the end that's really what I disagree with, for both Ryan and Julian seem to be saying something like dyamic languages have their own dependency issues (Ryan proposes SELL for example) but I don't see ISP as an implementation tool, its a way of thinking about code. And this I believe is the heart of the disconnect. So I'll stop there for now.

In short: The ISP means that we as software designers think about segregating client demands on our code as those demands shear in different directions lest we find ourselves in situations where changes to meet one demand negatively impact the quality of solutions to other demands. This type of thinking is needed in dynamic languages as well as in static languages, though the manifestation of problem and solution may look very different. I plan to follow this with additional posts to dive into the distinction.

Thanks to Mike Roberts for noting the comments were out - I actually became aware of it this weekend, and am working to fix it. There's some stuff out of date that I need to upgrade before I can fix it, so stay tuned...

Until then, go read Mike's response to my death of agile post, and comment there if you like (sorry Mike).

Agile is Dead, Long Live... what? I'll get to that in a moment (and to spare you the drama I don't have the answer), but first I want to clarify that this post will not cover the entirety of why I believe Agile is Dead, but why I disagree with Joshua Kerievsky and the Gilb's is part of my belief in the death of Agile, so I'm going to start here.

They (the Gilb's and Joshua among others I presume) think that the Agile manifesto is wrong because it does not list maximizing stakeholder value as an explicit, fundamental principle. I think that to make that change would drive a stake through the movement's undead heart and hasten its relegation to software history.

Joshua summed up his position on a twitter response to Alan Francis this morning:

And Kai Gilb says in his emerging series on the ills of Agile:

Not long before this Kai takes issue with the developer-centric nature of the manifesto and correctly identifies that the items listed in the manifesto are not why we as programmers get paid by the stakeholders. But his conclusion (that its about the stakeholders stupid) doesn't follow from recognition of the developer-centric nature any more than saying that it must follow from the desire for owners and media moguls to make billions off of professional sports franchises that the motivation and drive of the players should be based on those stakeholders' willingness to pay them lots of money.

I had the good-fortune to work closely with some really gifted and visionary executives in my last position at Redbox, and I learned a lot about maximizing shareholder value -- and for those executives this was their motivator. But, it would've been a mistake for them to assume -- and to base their incentives -- on the notion that every employee is motivated directly by that same goal. I always felt uncomfortable with that goal because while I understood it and worked hard to achieve it, my intrinsic motivation was different. And recently -- now that I am back to programming and no longer with Redbox, I understand why:

What drives me to excel at software development has nothing to do with why I get paid to do it. However, long ago I learned the value of making sure my drivers were aligned and complimentary with those of the stakeholders so that we weren't at odds and they would love my results and continue to pay me to do what I loved to do. And it turns out -- at least according to those of us who bought-in to the XP (and later, Agile) value prop -- that maximizing quality can do wonders for stakeholder value, so it was a great way to achieve a win-win.

And it is this notion, namely enabling software craftsmanship is a better value proposition for stakeholders than having the programmers directly focused on delivering value that was the sellable message of XP and Agile.

But why Agile sells isn't why I liked it. I liked it *because* it put the programmer at the center of the effort of programming (crazy notion that), I didn't need the manifesto to tell me that I had to find ways to make the person paying the money delighted with my efforts, what I needed was a way to tell them that I would gladly do so, if they would just let me.

That the message of the XP and Agile community was once "professional programming is about the programmers and customers stupid" was what gave the movement teeth, and ever since then, the community has been trying to soften that blow, include all the specialist roles from CEO to janitor so that no one feels left out, or that their political interests aren't being served. The resultant watered-down drivel has resulted in Agile becoming synonymous with 'good' moved 'development practices' into a footnote in some Agile systems (I talking to you Ken Schwaber and the Scrum folks) and once again made software development about non-technical goals and practices. To once again quote Mister Stephenson I call bullshytt.

So Long, Live, what? Michael Feathers and I started to have this conversation at Agile 2009, and I hope to continue it some day soon. The conference by the way gave me feelings of being on Trantor in the first Foundation book. And like the foundation maybe the answer is that Agile's fall is inevitable, and we need to look at nurturing what was valuable and try to preserve it so that the dark period is shortened.

In the meantime, I've gone back to basics: I'm focusing on being the best programmer I can be and building the best software I can. That I also know to do that in the context of making sure I meet or exceed stakeholder's expectations is simply my way of upholding a symbiotic relationship, not my end goal. My end goal is to write beautiful, useful software. And if I choose to put my name on any other manifestos they won't be ones that subordinate that to anything.

There's been talk of late of once again resurrecting the idea of an Agile certification. Setting aside for a moment my feelings about where Agile has gone in the last six years, and repressing for another moment my urge to vehemently oppose the idea, I am going to instead offer a positive alternative: Gifts instead of certs for recognizing someone's ability to practice XP.

After reading this on social objects, and this on Kula rings I thought: Why not do something similar for Extreme Programming or individual programming practices? (I think its too late to save Agile, but if I'm wrong then the idea works there too)

In a nutshell:

1. Anyone can create and give a gift. In practice, gifts created by certain indivdiuals and organizations will carry more weight, much like different items in the Kula ring system seem to, so no need to limit them
2. Anyone can pass on a gift to another. Having the gift in one's possession is not necessary, simply having the ability to show you had it would be sufficent to carry prestige.
3. Gifts do not have to be physical, but do need to be unique. A digital signing type of operation could work here, or perhaps a website that serves as the gift exchange to show history of its travels.

Some things to note: scarcity and prestige of the gift giver will naturally increase its value. If Ward Cunningham creates just 5 gifts and gives one to you (or someone who has one feels you should have it) that will carry a lot more weight than if Bill Caputo LLC creates one for every new hire into its company and they pass them on to client programmers as a way to get gigs.

In effect, this would be a way to ritualize namedropping, but since lineage and reputation are what we seem to base decisions on anyway (I learned TDD from so-n-so, and I worked with that guy, and he gets it, etc) then formalizing it maybe scratches the itch that has some practitioners desiring certs.

This is obviously just a thought; there would be many technical hurdles to overcome and it may not work anyway, but I wanted to share it.

I am in short proposing that we don't try to certify the practices, but validate the people (people over process).

[Test]
public void ExplicitReturnStyle()
{
    Assert.That(someObject.Identity("foo"), Is.EqualTo("foo"));
}

[Test]

public void ContinuationPassingStyle()

{

    someObject.Identity("foo", s => Assert.That(s, Is.EqualTo("foo")));

}

Given these two overrides of Identity:

public T Identity<T>(T foo)
{
    return foo;
}

public void Identity<T>(T foo, Action<T> f)

{

    f(foo);

}

In the Continuation Passing Style Identity doesn't return a value. Return'ing is simulated by passing what comes after the function (the continuation) as a function object. In many functional languages continuations are so central to how things work that this is how you return values (and those languages are optimized for doing this). For those of you like me who grew up with the imperative children of pascal, this may be somewhat mind-bending at first. It will also likely have you saying "why would anyone do this?"

Rather than steal his entire article, go see Wes Dyer's article on the subject (where I got the identity example) for more about why one might do this outside of a language (like Scheme or Erlang) where this idiom is apparently the norm.

For even more details (including why this isn't quite CPS) see this by Don Box.

BTW, my answer to "Why do this?" is: "When it is the best way to solve the problem at hand." That I don't know when that will be yet, doesn't really concern me. I don't always learn things with a specific application in mind. Sometimes, I learn things so that when a problem arises, I have a lot of different tools in my toolbox. In other words, I am learning it because its interesting, a bunch of people smarter and more knowledgeable than me have found uses for it, and I might someday too (and I definitely won't if I don't know about it!)

Perhaps the best reason to learn this stuff is because Microsoft has put some sharp tools in the C# toolbox and I think its better to know how they work so that - even if I rarely ever take them out - I don't get cut on them while rummaging around in there.

UPDATE: For Wes's take on why it's important, see here (and really his whole series on the topic is worth the read!)

UPDATE2: If you want to take a deeper tour of these and many other functional concepts, this series of articles by Dustin Campbell goes far and wide if you follow all the links (and the links' links and so on...)

The first one comes from the wikipedia discussion of a "Sequence points":

[Test]

public void ThisIsNotIntuitive()

{

    int i = 0;

    i = i++;

    Assert.That(i, Is.EqualTo(0));

}

The second one is taking this a step further and incorporates a closure to show how really evil doing this sort of thing is:

[Test]

public void NeitherIsThis()

{

    int i = 0;

    Predicate<int> f = (x) => x != i;

    Assert.That(f(i++), Is.True);

}

Since there is a sequence point before function code is entered (again at least in C/C++) then at first glance, one might assume the test should assert IsFalse, but no - because i's value is placed into x *then* incremented, then the function body is entered so that by the time the evaluation occurs the numbers don't match.

This is visible in the disassembly of the expression call (I pulled it to a separate line). ebp-48h is "i" and ebp-4Ch is "x" (as an aside: notice how the value stuffed into "x" is retrieved and incremented and then mov'd to "i" rather than getting it from "i" in the first place. Works, but weird):

bool result = f(i++);

0000008d  mov         eax,dword ptr [ebp-48h] 

00000090  mov         eax,dword ptr [eax+4] 

00000093  mov         dword ptr [ebp-4Ch],eax 

00000096  mov         eax,dword ptr [ebp-4Ch] 

00000099  inc         eax  

0000009a  mov         edx,dword ptr [ebp-48h] 

0000009d  mov         dword ptr [edx+4],eax 

000000a0  mov         edx,dword ptr [ebp-4Ch] 

000000a3  mov         ecx,dword ptr [ebp-40h] 

000000a6  mov         eax,dword ptr [ecx+0Ch] 

000000a9  mov         ecx,dword ptr [ecx+4] 

000000ac  call        eax 

In addition to the two links above, this guy has more on this subject including (the hopefully unnecessary) "don't do this in your code."

If there is anyone still subscribing, then hello! You know you've been gone from your own site for a while when you have to use password recovery to log in.

The reasons for my silence over the past couple of years have been due to a combination of intense writer's block due to anxiety about discussing work-related matters on my blog (to date, the source of most topics discussed here) and -- for the past 1.5 years -- being away from software development in my work (though I still try to keep up with what's going on).

Lately, though I have been feeling the itch to write again - and resurrect this site. So, what I hope to do over the next couple of weeks is flush out any old material still lying around, and then start writing again when I feel I have something useful to say.

A Computer World article talks about business and IT alignment/integration:

As more CIOs move toward business and IT alignment over the next 
several years, the makeup and structure of IT will change. IT and business unit
employees will work more closely together -- and in some cases, 
interchangeably.

I speculated on the roots of this split, and the eventual convergence of business and IT last year.

I believe that it is through such closer interaction and blurring (but not elimination) of distinction between business and IT -- and not the application of Agile to large classic IT projects where they are doomed to become their opposite -- is where the principles and practices of XP and related methodologies will have their lasting impact on software development.

Via Bruce Schneier:

I've long said that the fundamental problems in computer security are no 
longer about technology; they're about applying technology. Workshops 
like WEIS are helping us understand why good security technologies fail 
and bad ones succeed, and that kind of insight is critical if we're going 
to improve security in the information age.

Bruce referring to a conference (WEIS) that looks at the relationship between economics and computer security.

I think this is a great point, but Bruce doesn't go far enough. I think this can be generalized to: The fundamental problems in professional computing are no longer about technology but applying technology.

I'm sure that people who are still pushing the boundaries in things like AI, nanotech, etc. would beg to differ, but for the vast majority of people who are involved with technology (i.e. those supplying and using computer-based systems in the business world), the problem has shifted.

Not that long ago (i.e. within my time as a professional programmer), hard drive size, memory size, bandwidth and processor speed were forefront concerns for any business application design, often requiring workarounds or selection (or anticipation) of new technlogies. Now the discussion has shifted to how we effectively apply the tools and technologies at our disposal (I haven't heard anyone say something along the lines of "well we can do that if we just get more memory" in a long time). Even my phone has more processing power now than some of the desktop machines used by companies 10 years ago.

This is not to say our work is done. But rather that its just getting started. Now the challenge is to understand how to use the things we have effectively and efficiently (arguably a bigger challenge).

It also might explain the growing sense that CS degrees are insufficient to prepare people for a career as a professional programmer. As the fundamentals become more commodotized, the application becomes more central to success.

As the number of people on a software team grows, it becomes harder to accomplish this goal, and so there becomes a need for people who are what I term knowledge nodes: these people seek to understand the entirety of the design and features being worked on, so they can communicate relevant bits of that information to others who then have partial (but presumably sufficient) knowledge to do their jobs. Further, it appears common (and a function of both culture and team-size) to break the two areas of knowledge (i.e. design and feature-set) from each other and create specialized nodes for each of them.

The name of role such a person plays on the team varies, but Project Manager, Analyst, Lead Developer, Lead Programmer and Architect are all commonly used. Each of these incline toward the design or the feature (i.e. technical and business) aspects of the information on a project-by-project basis.

What do the people who are good at these roles have in common? In my experience, they are good communicators: they are skilled at gathering, explain ing and sharing knowledge about the design and/or the features of a software system.

The interesting thing (or at the very least: the reason I started writing this today) is that even very small teams need at least one such person. Even on a team with a half-dozen people or so (such as the one I work with now), if the knowledge of the system fails to reach a knowledge node -- it is less likely to get shared with everyone.

Right or Wrong I have always seen myself in this role. I've also (right or wrong) had a tendency to feel like if I didn't know something about the design or features of the system I was working on it wasn't known.

(and so, yes this entire analysis may be nothing more than ego gratification of my self-perceived role on software projects)

So now that I've found yet another way to describe my role on a software project, so what? Well, for those of you who also find yourself in this (or working with someone playing this) role, I have some advice:

That while you may think that things are not known (objective) unless you know them (subjective) remember that's your ego talking (but it still may be true if your team has come to rely on it).

If you are not someone who likes to talk endlessly (I've heard the word 'pontificate' a few times in my career) about design and feature ideas, get your thoughts to someone who does -- they'll make the rounds for you.

On small teams, one or two such people are more than enough (too many, and there will be no work, just talk) -- but you do need at least one to forge a team (otherwise everyone will just work on their bit without knowing about the rest).

Don't confuse knowledge nodes with knowledge creators -- good teams have both, and often the same person isn't good at both.

Particularly (as in my case) people are rarely good at both at the same time. I find that I can share design and feature knowledge, or I can create it, but when I am doing a lot of one, I am doing very little of the other. (team-size, iterations and pairing help with this -- as does some self-discipline on my part to keep it balanced).

Finally, the (presumed) XP goal of everyone knowing everything is in pratice accomplishable by making sure the knowledge node(s) of the team know everything and then get it shared around. If you are playing this role, you have to gather *and* share. If you are disinclined to do so, you have a responsibility -- at least -- to get what you know to such a person, so they can share what you know about the system with everyone else. This use of knowledge nodes may be (I don't know I just musing here) the key to an effective software team.

The thought of firing a space-based railgun at an unsuspecting planet in order to observe the resulting "debris plume, looking for any evidence of life" sounds somewhat Onion-esque to me.