In this episode, on the way to the airport, Coté starts by telling the worst re-telling of a movie moment event, we sing several “work songs,” talk about test driven development and refactoring, and then sort out how to dress while you travel.
(This episode edited by Charles.)
Thanks to the valiant efforts of Mr. Steve O’Grady, the RedMonk blogs will be up-ish tomorrow. I say “up-ish” because, as most you know, dear readers, switching domain names around on the internet is not a speedy science. Indeed, I’m often taken aback at how controlled and yet how chaotic the ‘net seems.
Then again, I’d be willing to be that there are teams of jack-booted thugs with hex screw-drivers and Cisco certifications ready to keep the network up. I mean, how terrible would that be if it went down?
While we wait for The Switchover, I still have this scrappy old thing. In the world of SaaS, High Availability means having two blogs.
I used to work at a company. Let’s call it WXYZ, Inc. One of the class clowns there made this joke one day:
High Availability? Baby, if you wanna get high…WXYZ is available!
Remarks like this were often followed by, “Waitress! Another Dewar’s!”
I started reading The Wealth of Networks last night. It’s nice, dense yet concise, academic talk about how content-producers controlling the means of production and distribution changes things. Information Marxism? Sure, sign me up as long as I can have a swanky Paris flat to go with it.
I’ve read a scant 20-30 pages, and there’s already a great conclusion: the physical distribution constraints of the “industrial information age” (pre-net) were the requirements driver of all that nasty, hegemony friendly IP law we created and now have.
Now, of course:
The removal of the physical constraints on effective information production has made human creativity and the economics of information itself the core structuring facts in the new networked information economy.
At least, that’s my understanding of those pages.
As I read it, I keep thinking about the other 4-5 billion people who aren’t on the network. I had the pleasure of hanging out with Mr. Koranteng Ofosu-Amaah last week while he was in town. We had some Ruby’s BBQ and then some coffee (well, he had tea) at Spider House.
Somehow we got to talking about the $10040 laptop. He had two interesting things to say (side-note: a longer post on the hangin’ out is much over-due):
Which was interesting, because we talked with Nokia this morning. Now there’s a mega-platform for you: cellphones. The strange thing about The Wealth of Networks thinking (my 20-30 pages understanding of it) is that the people who run and own the networks seem a few successful startups away from being PanAm and TWA to the analogous Southwests. I mean: telcos! Come on!
In America, we always wave off madness in the telco world — Korea is light years ahead of us, I hear, and they have some sort of crazy cool network in Europe — as regulation and FUD. Really, it’s probably just 50-100 well paid people who’re waiting to retire until they screw with the golden goose.
And there we have one of my new pet-theories. (Inquire within for more pet-theories.) Technological change is generational. You have to wait for one generation to hand over the reins before real change can happen. Excited about Agile Software Development? Keep your eye on the retire date of all those managers and “decision makers.” Want better cellphone networks in America? Wait for “insiders” to retire.
If good software takes 10 years, seachanges in software take 30-40. As the man said, “get used to it.”
Of course, firing people works too, but it feels so nasty. And really, wouldn’t you just be sticking it to yourself in that case?
The problem for us youngin’s is that retirement is soon to retire itself as a concept. Aside from all the fretting about not being able to live out The Golden Years in an RV or finally getting to writing That Novel, the generations in the tech world need to make a pact. A sort of realpolitik:
OK, we’re all going to keep our minds flexible and updated, right? I mean, if you’re going to stay in the work force forever, you’ll voraciously take on new ideas throughout your term, not just in the first 10 years. Maybe in exchange we’ll slow down a bit and focus on creating technology that allows you to work just 40 hours a week instead of 60. And we won’t say “no” next time you suggest Luby’s…. Okey-okey, and we’ll be less — just a little — snarky if you’re letting us play in your lawn.
Of course, we should probably be lining up to thank the generation ahead of us for working to pay the bills instead of bankrupting society. So, let me be the first: Thanks! …but now can we get on with some badly needed changes in core thinking?
Disclaimer: I actually like Luby’s. One word: okra. Bonus words: tarter sauce, deviled eggs.
Waterfall is plan driven — fixed requirements, estimated time and resources.
Agile is value driven — fixed time and resources, prioritized features.
“Would you rather have 100% of your features 80% complete or 80% of your features 100% complete?”
An unbending tenant of eXtreme Programming is YAGNI, “you aren’t gonna need it.” As Ron Jeffries says:
YAGNI says, it never makes sense for a developer to implement things that aren’t asked for. It is always an explicit waste of the company’s money. It does not save money over doing the same thing later: the cost is the same, just spent later, which is a good thing. Making the marketing guys grin will not put money in the company’s pocket.
Much of Chapman’s In Search of Stupidity is an extended proof of why you’d want to use YAGNI to keep developers (and fame-crazed execs) from running wild with features. Any developer who’s suffered through hours long design meetings and protracted “debates” about how baroque to make a system become fast adherents to YAGNI as well. See KISS and Good Enough Software.
On the other hand, we have flickr. And del.icio.us.* And, oh yeah, Mr. $434.26, the GOOG.
Cauvin linked to a set of interesting notes on Google’s product and project management taken in Jan. 2003 by Evelyn Rodriguez. On the topic at hand were these tidbits:
- Employees (called Googlers) are best source for ideas at Google — also some of
the most intense users of Google with well-formed opinions.- We get a lot of our ideas from our users (including customer support queue)
- Next iteration [of Google News]: Didn’t make it to user studies because Googlers hated it.
While these notes are from 2003, that was obviously a critical time for Mr. $434.26, so the software development approach they were taking at the time is obviously of interest.
And what’s interesting is how involved the “Googlers” (man, I’d kill myself if I had to go by that moniker) themselves are in playing the role of customer. In the world of Agile, that’d be a big poop-on-that no-no: in most Agile implementations, the product owner is the mouth-piece of the God of Features, The Customer.
At the other end of the spectrum are developers who are writing and using the software: those “intense users” at Google.
In software, we call this “eating your own dog food.” While I obviously have infinite respect for everything else good product managers do, the eating your own dog food principle is the most important one to follow, and yet the one least used.
If you’re working on some big, complex piece of enterprise software, for example, ask yourself, “would I want to install this and configure it?” Chances are, the answer is no: in an enterprise software shop, one of the hardest things to do is to find a running copy of your software (dev instances don’t count). No one wants to go through the hassle of installing that beast, which usually involves several hours, cryptic error codes, and dedicating a whole machine.
Never mind the ever insulting “my mother/aunt/some clueless old lady” test; a product manager I know has a real answer for this problem: “The CEO should be required to install every piece of software their company makes.” In other words, the CEO would have such a terrible time installing most pieces of software that they’d use their bully-pulpit to make install easy.
Install is just the first part of your software (and as the first impression a customer gets, ask yourself, “how much time do we spend assuring that the install makes the best impression?”). The next step, of course, would be to require the CEO to use the application weekly, if not daily, with the same hopefully result.
The flip-side is that as a buyer of software, one of your first questions should be, “tell me how your company uses this software. Give me details.” If a company — esp. a large company that has all the same IT concerns as any other company — doesn’t use it’s own software, they’re sales people better be ready to dance up a storm to explain why.
Charles and I have talked about the lack of dog food eating in Agile quite a lot in the podcast (esp. in the first two episodes: 1 and 2). We’ve never come to a good conclusion, except that there’s something missing.
As the Google notes above indicate, employees are often one of the best sources for features, esp. if they’re users of the system. There’s certainly some shuckin’ and jivin’ that can be done to say that Agile thinking addresses this (we listen to customers, programmers could be customers, ergo we listen to programmers). But, as of yet, figuring out how to harness the innovative abilities of the developers is something that most Agile software development methodologies as practiced don’t do well. Of course, you could knock out the word “Agile” from that sentence, and it’d be even more true.
* My gut tells me that flickr and del.icio.us “allow” their developers to drive features. A couple of quick searches didn’t find anything to confirm it, so for now my proof is simply my instincts. For Google, on the other hand, I have the above “proof.”
I’m pretty much burned out on reading about Agile software development. I spent 2-3 years rabidly reading about it, and now that we’ve been applying it at The Day Job, I’m more interested in solutions and improvements to specific problems and processes I encounter. So the generalized stuff and platitudes you find out there gets to be repetitive and not immediately applicable.
That aside, I liked this post entitled “Application Integration and Agility (1): Understanding Agility” because it wove together Agile think very tightly with Lean think, e.g.:
[T]he core of waste in software comes from the traditional approaches to project management.
…
[As one example:] Tighter scope controls convert the “change control boards” into change prevention boards. And oftentimes teams deliver “to the scope” and not to the real business need, producing useless products that need substantial time to be augmented with functionality that is actually needed.
That is, adding extra process to slow down change can be wasteful because it produced software that (a.) the customer doesn’t want and, worse, (b.) that requires lots of work to make worthwhile.
The first items is the core of what it means to be Lean: you produce only what the customer wants. While the second is a consequence of what you might call The Grand Mistake of Agile Software Development Practitioners: the sense of immediacy and minimalism in delivering “only what the customer wants” often causes you to create software that is not flexible, nor easy to change.
That is, despite what the phrase “deliver only what the customer wants” seems to imply, you do need to think of the future: customers always want more, and they want their software to be quickly modifiable to get that more. They just don’t know they want that until it’s too late. Part of being a good software developer — or any service job — is giving the customer what they don’t know they want. Put another way: the customer is rarely 100% right or complete, where “complete” means “can give you a list of every single thing they want.”
At the moment, my cure-all for all woes of applying Agile boils down to the well-worn Agile precept: small groups of people, all jammed into one room have the best chance, out of all project management strategies, of creating great software. Really, this practice is what you might call a “theory grandchild” of my favorite project management “law,” Conway’s Law, the conclusions of which point towards having as little hierarchy and lines of communication as possible…assuming you want to produce simple, elegant software. (As an aside, those two things are easy to loose track of when you focus on the naive understanding of “deliver only what the customer wants.”)
Sadly, the legacy world of plan-driven, people-heavy, product-based/shrink-wrap software we exist in is effectively anathema to small groups of people in one room. It’s an odd thing that.
As an industry, our prime hope is that The People Who Decide start looking to Google as a successful, new way of doing software development. If old GOOG can stay in the $100′s long enough, it just might stick. Otherwise, it’ll just be a flash in the pan, and we’ll stick with the boring, wasteful ways of developing software. Customers will continue to be “happy” because nothing better exists. The bears will dance!
(With Yahoo!’s last few acquisitions and partnerships with small software development shops, the old Y! might be a beacon of project management hope as well. We’ll have to see.)
So, yes, check the post, it has a refreshing interlacing of Lean and Agile.
And if you figure out how to disrupt the boring, legacy way of doing things, drop us a comment below.
In this episode, we talk about how Coté’s group in BMC has been using Agile/SCRUM over the past year and half. Special guest star Chip Holden fills in the gaps too.
(This episode edited by Charles.)
In this episode we talk about The Mouth of the South, more about Charles’s expierience with Agile, and electing the first Slim Jim President.
(This episode edited by Charles.)
(Click here to download/listen to the podcast.)
There’s (above) the second episode for the old podcast. It’s the rest of Charles and I talking about Agile, software stuff, all girded by his time at ThoughtWorks. I think there’s some more StarControl sounds too…and dog barking.
You know you’ve been hittin’ reload on this page just waiting for this second episode!
(Click Here to Download the Podcast)
I’ve finally put together the first Drunk and Retired podcast. This is part one of some back porch-chattin’ with my good friend, Charles Lowell about his time at ThoughtWorks, agile thinking, Star Control, and a few other things. It’s about 1/2 an hour, and you know you’ll love it!
Update: also, of course, the RSS feed contains an enclosure for this episode. So, you can just add the URL http://feeds.feedburner.com/cote to iPodder, or whatever podcast aggregator you use.
