Oh yeah... today I wanted to introduce to you a new paradigm for Software Development, one that seems as radical now as Agile did back in the day, but that fits in so well with the way that we really want to do software development that you'll wonder why it took someone so long to write it down. (I'm wondering the same thing myself right now.) In fact, you may already be engaging in some of the practices without ever having really bothered to think about it.
Before introducing Indolent, I need to give credit where credit is due. I'd be more than remiss if I didn't acknowledge the work of important innovators in this transformative approach. I'm speaking of course of Ken Laidback, and his LaZy-Ass Programming approach. For those who haven't been keeping up with the hot trends in software methodologies for the last couple of years, well, you've got the right idea. Just keep being who you are. But most of us need a point in the right direction -- a formula of some kind -- and that's what Ken and his merry band of hacksters has given us. In a nutshell, LaZy-Ass Programming -- later referred to without that cute capitalization in a failed bid to satisfy those uptight "Suits", the people who are always looking around for shallow opportunities to make "money" -- was an attempt to solidify and round out a set of behaviors that the initial practitioners had found made them happiest. Rather than a set of "Processes", or even "Practices", Lazy-Ass was at heart a set of "Excuses" and "Rationalizations" for behavior that fit in with the way programmers really wanted to do things anyway. But the real beauty of Lazy-Ass was not the Rationalizations themselves, but they way they all fit together into an absolutely water-tight container capable of keeping the practitioners warm, dry and responsibility free, happily doing "Cool Stuff" -- defined as "what you want to do" as opposed to "what the Suits think you should do" -- for years to come.
A couple of examples should give you a flavor for how these interlocking rationalizations work in real life. "Task Shuffle" invites practitioners to take on unrelated random tasks and then swap them with others at random intervals so that the Suits are never really able to identify who is responsible for what. "Goat" gets (almost) everyone together in an effort to identify one or two people on the team who will take on responsibility for those few unavoidable cases where "Task Shuffle" fails -- by concentrating blame, the rest of the team is able to focus on "Whatever the Hell I Want", thus doing Cool Stuff. "Welcome to the Team, Let Me Buy You Lunch" ensures a steady supply of new recruits to take on the Goat role.
Most of us are familiar with the rest of the history. Lazy-Ass managed to establish itself in a number of key domains, most notably government contracting and systems integration. Here, the interests of the programmers and the rest of the stakeholders (excluding the "Customer", whose role is largely secondary, and some would argue purely mythical) strongly coincided. But it never caught on in the mainstream. I'm going to say something a bit controversial here. I think the real reason for this was mostly packaging. Yes folks, how you present things matters! Lazy-Ass Programming got a bad rap because of its name and the over-enthusiasm of early practitioners. "Lazy-Ass" was simply to* cute and -- let's face it -- provided a little too much of a clue about the deeper methodological agenda for those executives concerned with external appearances and shallow concerns like "income". Later innovations like "Rats and Ships" and "Bigger-Better-Deal" convinced some junior execs to buy in, but it was a matter of too little, too late. And yes...let's admit that some of the early practitioners were just a little too dogmatic. Let's be realistic, you've got to throw the dog a bone once in a while. Still, even if not in name, the spirit of Lazy-Ass lives on in all sorts of efforts and at all sorts of organizations, big and small.
Some of you may be aware that as of this writing, the Eclipse Project Indigo Release just shipped. This project involved the simultaneous release of 62 separate projects and...um, a bunch of lines of code but I'm too lazy to look it up, and LOC is a lousy metric anyway...all at once. This sets a terrible precedent for those of us who simply want to do "Cool Stuff" and who are above caring whether people can or will actually use it. In fact, I can't think of a more colossal failure for the Lazy-Ass approach. That's why I've chosen to introduce my new methodology now. If it takes hold, perhaps we can prevent a worse atrocity next year.
My new methodology is called "Indolent Development", and I own the trademark so don't even think of borrowing it without giving me attribution and a nice cut of the action. I'm going to replace Agile -- everyone knows that that's totally broken anyway -- and in the process make a million dollars. Yes, that's right, training courses are in development right now, and soon you'll be able to get personalized coaching from a highly-trained, experienced network of Indolent Masters. The major thrust of Indolent is to be much more "CIO friendly". Even the term "Indolent" was carefully chosen to fly under the corporate radar while amusing those of us "in the know". (You'd be surprised at how obtuse many corporate leaders are.) Indolent Development involves just ten core principals. These principals* are designed to maximize Cool Stuff, allow plenty of Slack, and reduce or eliminate exposure to Downside Risk for the practitioner.
- YNKWYMNI "You Never Know When You Might Need It": If it seems kind of cool, put it in! You can always take it back out later.
- YBIYFI "You Broke It, You Fix It": This one is all about Shared Bug Ownership. Example dialog: "It worked fine when I wrote it. I've moved on to something much cooler now. YBIYFI!"
- The Random Walk If you're really thinking outside of the box, a plan only gets in the way. In fact, thinking ahead at all is a sure way to kill innovation.
- Interrupted Integration Example dialog: Hey, this worked last month. WTF?! Look, just give me a couple of weeks to sort this out, and it will probably be working great for the next build. Unless someone breaks something else in the meantime.
- Refutzing Let's take everything apart and put it back together. Maybe it will work this time.
- Users Lie They don't know what they really want. Why waste time asking them?
- Test Later Why bother fixing it if you don't know its* broken? Real programmers have confidence. (It's important to note that testing does serve a purpose. "Test Weenies" make good "Goats", because you can always point out their failed tests.) An advanced form of this practice is Test Never.
- Eight, eight, I forget what eight was for.
- Self-Expression You're special. Why shouldn't your code reflect that? When you die, won't it feel good knowing that somewhere buried in that nuclear reactor code there is a special little nugget that only you can really appreciate?
- No Best Practices When a good idea becomes dogma, anti-dogma becomes a good idea.
And actually, if you take nothing away from this article, that last point is it. In fact, you could say that it is the only point that really matters.
*Hey Mr. Suit, programmers can't spell and frequently confuse homophones. Get over it.
Update: I added a bunch of cool pictures so that my blog is just like Ed Merks'. Except I was too lazy to take my own pictures. So I stole some off the internet when I was supposed to be working on software builds. Also, because I'm working on builds yet again, god-damn-fuck-it-all-to-hell, I'm kind of in a bad mood, so they're all pretty depressing and uninspiring. Sorry. I hope your day is going better, sincerely.
- Guy who is almost as cool as I am, but someday will also be just like COBOL guy, Wiros
- Nose Picker, Millicent Bystander
- Lazy Sign, Jef Godesky
- The Most Depressing Place on Earth, After Fire, Kevin Dooley
- Meeting Interessante, Antonio Furno
- Just like my EclipseCon talk, Out.Of.Focus (Why do Flickr people not have real names?)