This post originated from an RSS feed registered with Java Buzz by Michael Cote. Original Post: Wasted Thug-time, Lean, That 12 Hour Sleep Feelin' Feed Title: Cote's Weblog: Coding, Austin, etc. Feed URL: https://cote.io/feed/ Feed Description: Using Java to get to the ideal state. Latest Java Buzz Posts Latest Java Buzz Posts by Michael Cote Latest Posts From Cote's Weblog: Coding, Austin, etc.

I watched Yojimbo the other night and, among many other things, one of the "Bosses" said something along the lines of, "look, we need to start this turf battle. It costs a lot of money to have all these mercenaries just sitting around not fighting."

My most recent "book full of useful ideas that will never see the light of day" (as I called it in the padded elevator a couple days ago) is Lean Software Development. It promises to build a process around eliminating waste. Moving away from the turf war analogies of Yojimbo, waste is anything that doesn't contribute to "customer value." Nevermind that last part being a vague phrase in itself: just assume "value" means something along the lines of useful, desired, functional, and marketable.

I've only read the first 20-25 pages, so I'm not sure how waste-cutting will fit well to something as imprecise as software development; when creating software, it's hard to know what will be of value in the end. But, I'd wager most of the waste is in undeeded process, for example:

In 1970 Winston Royce wrote that the fundamental steps of all software development are analysis and coding. "[W]hile many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs." With our definition of waste [anything that does not create value for the customer], we can interpret Royce's comment to indicate that every step in the waterfall process except analysis and coding is waste.

Or, to steal a TLA from another source, if you can lump design and coding together, "A-B-C. A-Always. B-Be. C-Coding. Always Be Coding."

Coincidently, one of the free trade rags I get, Industry Week has an article about Lean Manufacturing. It's most interesting point is that the exact implementation (the practices) of lean manufacturing aren't as important as the ideas behind it (the methodology). While that abstract idea applies naturally to some things, I'd think it wouldn't be such a straight jacket in the auto manufactoring world. But, that world is (or can be) more dynamic than my initial assumptions:

[W]ork within Toyota's factories is performed in what amounts to a tightly controlled experiment that tests the assumptions embedded in the work's design. By testing the work as it's being done, problems are recognized when and where they occur, which prevents them from propagating.

The "tightly controlled experiments" evaluate the worth of the practices: as they become less useful, new ones are developed. Perhaps their failure is due to the practices never having worked in the first place, or, due to the context and needs changing. Given the fact that the "value" of a practice can degrade, you can't simply adopt a set of practices and expect success.

"If you look at Toyota's history, the tools and artifacts were developed to deal with very particular problems that were affecting people in very particular circumstances," he says. Beyond those situations, "the situations from which the tools were first created and embedded, tested, developed and refined, the tools have less and less applicability." Working under different circumstances presents different problems, which requires different tools and different thinking.

Indeed, it seems like you often have to come up with a whole new way of doing things for each context switch. But, as one of my other favorite software development authors always points out, you can still use the same methodology for coming up with and continually evaluating the use of the new practices.

Also, I recently came across a Boehm paper (which provides a quick, updated overview of the spiral process) that has another good example of software development waste:

[T]he amount of initial calendar time it takes to work out a complete set of detailed requirements that are likely to change several times downstream is not a good investment of the scarce time to market available to develop an initial operational capability.

And, on that note, how about cutting from my rambling into some sublime rambling from the above TLA source:

All train compartments smell vaguely of shit. It gets so you don't mind it. That's the worst thing that I can confess. You know how long it took me to get there? A long time. When you die you're going to regret the things you don't do. You think you're queer? I'm going to tell you something: we're all queer. You think you're a thief? So what? You get befuddled by a middle-class morality? Get shut of it. Shut it out. You cheated on your wife? You did it, live with it. You fuck little girls, so be it. There's an absolute morality? Maybe. And then what? If you think there is, then be that thing. Bad people go to hell? I don't think so. If you think that, act that way. A hell exists on earth? Yes. I won't live in it. That's me. You ever take a dump made you feel like you'd just slept for twelve hours?

Just going along, making some sort of sense and then -- BAAM! -- "did I ever take a...? 12 hours..? ...what?"