On being a lucky bastard

This afternoon, I went to a session called “The Lego XP Game”.

Yes, that’s what it sounds like: I got to play with LEGOs all afternoon.

Now, it’s a weekday. Normally I would be at work today. So that means I got paid to play with LEGOs all afternoon.

It doesn’t stop there. My company paid for my airfare, lodging, and food, so I could get paid to play with LEGOs.

And it turns out that, even though the convention provides lunch, my meal allowance is still $46 a day. So let’s break that down: I got

  • paid-for airfare and lodging,
  • so I could eat out at a teppanyaki grill,
  • so I could get paid,
  • to play with LEGOs.

I am, in fact, a lucky bastard.

(Hey, I’m getting out of debt. These days I eat out maybe once a month. I’m enjoying this while it lasts.)

It’s a three-way tie, though. I got to play with LEGOs, Sam got to make paper airplanes all afternoon, and Brian, despite registering for basically the same hotel room as both of us, wound up getting put in a room with a whirlpool.

Lucky bastard.

Agile 2006: Engaging the Customer

This morning, I went to “Engaging the Customer: Empowering and Engaging Customers and End-users”, which turned out to be another discovery session. We spent a lot of time moving around and doing stuff in small groups, much like Is Agile Development Still Agile? yesterday (in fact, it had one of the same co-presenters). Writing stuff on sticky notes and putting it up on the wall, with the promise that the wall will eventually appear on the Agile 2006 conference wiki.

The question: How do you engage real live end-users in the agile process?

I won’t talk too much about what we came up with, since it’s all going to be on the wiki eventually. But a couple of good ideas that came out of our table:

  • Make the retrospective relevant to the whole team, including the customers. Don’t just geek out; find another venue for the geekspeak. The retrospective should be about which stories we promised to finish and didn’t, which stories went better than we expected, stuff like that. Keep it relevant.
  • Do a demo at the end of the week, and have the retrospective immediately after. The demo will get the customers into the room, at which point you’ll have a better shot at getting them to stay for the retro.

Wow. I took two pages of notes, and all the interesting stuff boils down to two bullet points. Ah well. Those two bullet points will be things worth talking about when we get back home.

Agile 2006 Keynote: Beyond the Manifesto: Readings for the Agile Developer

At the keynote, with a tenuous hold on Internet access.

1111 attendees (and still trickling in) from 29 countries. 60% growth over last year. Sold out.

So what’s this “Open Space” thing? Opening today at 11:00. Description on page 7 of the schedule. Room for 150-200 people.

Peter Coffee’s keynote: Beyond the Manifesto: Readings for the Agile Developer

Talking about books that, if he couldn’t find his copy, he would go buy a new one (the oldest and most well-worn on his bookshelf).

  • Information is that which consumes attention (if it doesn’t change your perceptions, it’s background music)
  • If it’s between hard covers, is it already out of date? (Some books change the questions you ask.)
  • Some books, I don’t trust to Gutenberg or Amazon

Let’s use the Manifesto as our outline.

  • Favor individuals and interactions
    • Robert Townsend, “Up the Organization”
  • Favor working software (as opposed to…?)
    • John Gall, “Systemantics”
  • Favor customer collaboration
    • Tom Friedman, “The World is Flat”
  • Favor response to change
    • Tom Peters, “Thriving on Chaos”

Individuals and Interactions

  • Robert Townsend, former CEO of Avis (at a time when Avis had never made a profit)
  • There for invention of phrase “We’re #2, we try harder”
    • Thinks you should fire your advertising department. They’ll never understand your business, but you’ll never understand theirs. Made this deal with the advertising agency: they’ll only bring advertising they recommend running, and you will either reject it, correct factual errors, or say “Okay, we go with it.”
  • Big successful operations aren’t successful because of the way they operate, but in spite of it. Don’t look at a big successful company and imitate their symptoms. Don’t try to learn to become an opera singer by gaining weight.
  • Each level of management lowers communication effectiveness by 25%. Organizations exist that have 11 levels of organization between the coder and the architect (aack!). How many policies can tolerate losing 90+% of their effectiveness as to what’s being done and why?
  • Disaster potential goes up with the square of communication time. Both inefficiencies and delays. Time constant of successful software development has gone down.
    • Merrill Lynch said “Let’s let individual investors have the same overnight money-market parking operations that we offer corporations. Let’s make it a retail product.” (Money-market accounts?) Algorithms already exist, just a question of scale. How many billions of dollars moved from other brokerage firms into Merrill Lynch in the 6-9 months before the rest of the industry said, “Oops, we need to respond?” And when they did, the money didn’t go back. Ratchet effect.
  • Computers just speed up the mess. Computer people like to create new reports, new ways to slice and dice. Would ask managers, “How did you make this decision before computers?” You can’t use certain types of information; you can’t optimize hour-by-hour. Are we being business-process driven instead of data-capability driven?

Working Software

  • John Gall, retired pediatrician
  • Became head of a research institute. After 6 months, he had completely lost touch with current research. Grant writer, professional schmoozer, manager.
  • Wrote “Systemantics”, now revised as “Systems Bible”.
  • Systems in general work poorly or not at all. Many systems are proposed which either work or do not work, but most systems spend most of their time in some sort of failure mode: not working as they were intended to, most of their time. Imperfections — working when things are not perfect — have to be part of the spec.
    • Uncertainty analysis in spreadsheets. Hypothetical new product that would make the company $1M in the first year. Throw in some uncertainties, and find a 2/3 probability of loss. Not surprising, but think of the difference in the conversation in the boardroom. Comparing scenario 1, $1M first-year with 2/3 probability of loss, vs. scenario 2, $2M first-year with 90% probability of loss. Totally different conversation!
    • Complicated systems seldom exceed 5% efficiency.
    • A complex system designed from scratch never works.
    • Any large system spends most of its time in failure mode. This does not mean it’s failing, just that some piece is failing, and the rest of the system is having to compensate. Has to incorporate areas where correct operation can’t be assumed.
  • Systems develop goals of their own. (Among them, preserving their existence.)
    • People in systems don’t do what the system says they’re doing. Go to a shipyard, you won’t find a boat-builder. You’ll find welders, electricians, accountants. The system is a boat-builder. You can find a good welder, but is he building good boats? You have to ask this disembodied thing. Once you get over about 15 people, there is no person who does what the system is supposed to produce.
    • Need to be able to identify people who are part of the system, not laser-focused on one task.
    • It’s not “feedback” until the system changes course. Need a way to put that information back into the system and make changes; otherwise it’s just backchatter.
    • Do it with a small system if you can. (Even the book grew.)

Customer Collaboration

  • Carrying the book starts conversations in airports.
    • “So, what’s that about?”
    • “So, what do you think of it?”
    • Everyone he asks, “Have you read it?” has
  • Author has been in the call centers in India where they teach people to speak with a Canadian accent.
  • Not always correct on technical details. Political analyst or economist or something. Corrections:
    • Y2K was about data structures, not PC clocks.
    • Excess optical fiber doesn’t light up by itself.
  • Nonetheless, key points in the book are correct.
    • Co-create with the customer. If you get nothing else out of this talk, the whole conference will have been worth it. Sending developers into their cave doesn’t work anymore. Involve customers with original concept, feedback that actually matters. Use “stakeholder” as more than just a word.
    • Establish trust relationships. (Look back at the “trust your ad agency” above.) Data security. Who are you? What do you do? What do you have reasons to want to know? Difficult to do technically, no obvious payback. But not only do we not have secure systems, we don’t have securable systems. How many apps (on a certain platform) won’t run unless you’re an admin?
    • Don’t use new technology to cut costs. Example: foreign currency trading. Expert system made correct decisions most of the time, much more quickly. Trained it as time went on. Successful. Fast-forward a year: all foreign-currency-trading firms are using expert systems. Zero-sum game (hey, what happened to ratchet systems?) Nobody cut their costs; they just stayed in the game. In the long run, you can’t expect a sustainable profit advantage. Never present technology as a way to get more profit; you’ll be wrong in the long run.
  • More code is now worth writing. Apps are easier to produce (compare VB to the olden days of coding to the API). Apps that used to be “it’s not worth what it would take to write that” are practical now. But you need to rapidly identify the opportunity, get rapid feedback, rapidly get something out there that’s good enough for people to start using, even if they want more later.

Response to Change

  • The book Tom Peters didn’t retract
  • There are no companies that do The One Right Thing and keep doing it forever, and succeed as a result
  • Must adapt to change
  • The rate of change demanded and the boldness of the goals are unfailingly new — and frightening. If you present goals and people nod and say, “Yeah, we can do that,” you’re being too timid.
  • The Japanese word for “large” is literally “not delicately crafted”. Big OSes don’t ship. Huge applications get abandoned. No one wants to talk about project abandonment. Bigness used to be a necessary evil, but it may not be necessary anymore. Go lightweight.
  • America can keep high wages only by producing goods with large components of specialized services. Future of mass production in quantities of one. Opportunity to infuse things you know about the business. If you’re IT and you don’t infuse business knowledge, it’s suicide, because you can get outsourced. If you’re business and you don’t do it, it’s business suicide.
    • How do people make money on open source? Response: Do lawyers make money? The law is open source. Lawyers make money because they master a body of knowledge, and then they make it work for you. That’s what open source does. We can make it the right thing for you when you need it.
  • Americans still see automation as a tool to reduce labor, not as a tool to aid labor in adding value. If you go back 15 years and look at development tools, and compare to anything free today, you’d say, “How can this still be hard?” Many problems (prototyping, deployment, the list keeps going) have gone away; why is this still so hard? Because you thought you were developers, but you’re really personal counselors.
  • Tom Peters’ “Prescriptions”
    • Obsession with responsiveness. If you contacted a vendor and got an answer back in an hour that said “we can’t fix that today, but we’ll get you a fix in a week,” would you prefer that over waiting four days and getting the fix?
    • Constant innovation in all areas
    • Partnership among all connected with organization (“stakeholders” again)
    • Leadership that loves change. Most people in charge like the Way Things Have Been because it’s been good to them. Work on them. Be an example. Never treat the technology you bought into a few years ago as an important aspect of you as a developer. Dijkstra: “Never treat your code base as valuable just because it cost a lot to produce it.” What can we do right now?
    • Control by means of simple support systems aimed at measuring the “right stuff” for today’s environment. Don’t make a list of approved PCs; instead appoint someone to find the right solutions for what people need. Make recommendations, not mandates. Not “do this or you will be punished”; instead “do this and you will be rewarded”. The former drives away people without creativity; the latter attracts and retains good talent. Nervousness is the enemy of innovation. Make people feel that you understand what they need. Build systems that support doing the right thing, instead of punishing doing the wrong thing.

Just in the last ten days (breaking news / agility)

  • July 14: “Software security provider McAfee fixed a serious flaw in January 2005 with a regular update and didn’t even realize it.” How can you do something as significant as fixing a security hole and not notice? Six months later they realized, “Oh, we fixed that bug.”
  • July 17: “The White House has set an early August deadline for government agencies to encrypt sensitive data… slipshod handling, poor training and slow moving bureaucracy are seen as the main causes of vulnerability.” Massive deployment of encryption and authentication across government systems in 45 days. But main causes aren’t that data isn’t encrypted: it’s lack of training, lack of caring.
  • July 18: “Symantec researchers reported finding three different types of potential flaws in Vista’s underlying software code…” Brand-new untested code. Security, stability.
  • July 18: “Database and server giant Oracle on July 17 shipped a quarterly critical patch update with fixes for a whopping 65 security vulnerabilities.”

The idea that bugs are inevitable in shipped code has to go away. Wants “bug” in software to become as obsolete as “bloodletting” in medicine.

Is Your Firm Agility-Impaired?

  • Digital Focus survey released today
  • Reasons for not adopting agile techniques
    • “Lack experience” = “We don’t invest in skills”
    • “Requires too much business involvement” = “We don’t care, just write the code”
    • “Code maintenance” = “We don’t treat code as an asset”
  • Other canaries in the coal mine
    • “Projects are too big for agile” = “too big”
    • “Projects are too complex for agile” = “too complex”
    • “Don’t trust agile for mission-critical projects” = “Our mission-critical systems can’t quickly evolve”. So don’t worry about it, because in five years it won’t be a problem anymore.

Innovation that excels

  • Sixth annual eWEEK Excellence honorees
    • Personal productivity
      • ThinkFree Office Server Edition
      • NetworkStreaming SupportDesk
    • Enterprise Collaboration
      • Antepo OPN System XT (instant messaging)
      • Intuit QuickBase for Corporations (hosted/managed)
      • Salesforce.com AppExchange and Sandbox
    • Storage
      • SANscreen Replication Assurance
      • XOsoft Assured Recovery
  • Services and meta-services
  • Compliance and trust management

Escape plans from exclusive choice

  • Platform commitments avoidable
    • Microsoft upgrade juggernaut slowed
    • Web browser interoperability improved
    • Cross-platform application interfaces emerging
  • Acceptability of external services on the rise
    • Bandwidth and reliability still increasing
    • Confidence in technologies of trust growing
    • Outsoucing better understood as affirmative strategy: increase competitiveness
    • Costs of failure to evolve are getting better recognized. No company is too big to fail.
  • Tom Friedman (2005): “On day 2, you’re multinational”
  • Norbert Wiener (1948): shun “mediocre attainments”. There’s no wage at which a pick and shovel can compete with a bulldozer. In this day and age, nobody mediocre will be able to sell anything that anyone will want to buy. Don’t have the best e-mail system in the industry, unless that’s what you do. Do the things that make your company a leader in what it does, and apply technology to that goal.
  • Robert Townsend: There are too many organizational orthodoxies imposed on people, and I don’t want to help the walking dead impose another one.
    • Not an orthodoxy. Focus on goals, and add support processes.
  • C. Northcote Parkinson: Leadership is the art of so indicating a distant goal as to make all else seem trivial.

Agile 2006: Is Agile Development Still Agile?

Okay, so I’m a day behind. My excuse is that my room’s Net access was broken again last night, but that’s pretty flimsy, since I didn’t call support to fix it again, or go down to the lobby for wireless.

But yeah. Yesterday afternoon, Brian and I went to the “Is Agile Development Still Agile?” discovery session (well, part of it — we missed the first half hour). They had divided everyone into 20 tables of about 5 or 6 people each, and then each table brainstormed and prioritized answers to four questions:

  • The 3 things that first attracted me to Agile development were…
  • The 3 things I like most about doing Agile development are…
  • My 3 biggest disappointments about Agile development are…
  • 3 things that surprised me about Agile development are…

Each table wrote their top 3 answers on index-card-sized sticky notes, and then we stuck them up on the wall, clustered more-or-less by topic. They’re going to put pictures on the Agile 2006 conference wiki, though at this point they haven’t yet.

Since everyone’s answers will end up on the wiki, I’m not going to talk about all the answers we came up with, just the ones that interested me the most:

Interesting “first attracted me to” answer: Humanism. It’s not just about results, it’s about the people too. (This one came from Michael Bolton, who is also presenting at the conference. We’ll have to make sure we swing by some of his sessions.)

Interesting “things I like” answers:

  • Stopping mechanism: at the end of an iteration, if you’re not done, you stop anyway.
  • Fail fast.
  • Visible progress on working software.

Interesting “disappointment” answer: having agile sold to management as a “silver bullet” that will solve everything.

My favorite, though, was an answer to “things that surprised me”: Practices are easy, principles are hard. It’s easy to do things like planning and pair-programming and test-driven development. But to have the deeper understanding of why you do them, what goes into them, is hard. (This one also came from Michael Bolton. He’s an interesting character, and I’ll look forward to hearing from him again.)

Arrived at Agile 2006

I haven’t blogged about how I’m going to the Agile 2006 conference this year. Shame on me.

Well, I’m going to the Agile 2006 conference this year. In fact, I’m already here, and so are Sam and Brian. I would’ve blogged earlier, but my (free) in-room Net connection wasn’t working. But the switch is now reset, and I have net. Happy!

I plan to blog the con like I did for previous BorCons (assuming the con has free wireless, which I certainly hope they will), so get on my case if I fall behind. (grin) I’ll blog more later — we’re about to head for registration, and then probably grab a bite before the afternoon session.

Googlebombing the mundane

I wanted to know what time Oak View Mall opens today, since I want to do some shopping today. So I Googled for oak view mall omaha hours, and I looked at the results, and I thought, “You’re kidding. You’re telling me one of the biggest malls in Omaha doesn’t have its own Web site?”

Then I scrolled, and there it was at #7. Still on the first page, but the mall apparently has a pretty poor Google rank. Somebody’s AOL homepage is at #2, for crying out loud. That ain’t right!

So, doing my part to increase the relevance of the Web, here’s my mundane Google-bomb for mall hours for Oak View Mall in Omaha. Pass the meme.

Dave Ramsey Live Event in Lincoln, NE, Aug 12

Russ Carroll, Dave’s lead financial coach, is going to be in Lincoln on August 12 doing a Dave Ramsey-branded Live Event, and Jennie and I are going to be there.

Not quite sure what it’s going to be like, especially since we’ve already taken Financial Peace University. But I do know that one of the best things about FPU was being around other people who were in the same boat as us (and willing to admit it). So even if the content turns out to be a repeat, I think it’ll be well spent.

And it’s cheap as things like this go ($27 per person). If you live within a couple hours’ drive, and if you’ve ever had, as Dave puts it, “too much month left at the end of the money”, I’ve got two words for you: Go.

Advanced Treeview for WinForms

Found a WinForms control called Advanced Treeview. It looks like it might be able to do most of what we currently do in Delphi with VirtualTree. It’s got multi-select, multi-columns, drag-and-drop, and something resembling owner-draw, among other things. And it looks like it’s entirely owner-data, which all by itself is reason to use it instead of the standard WinForms TreeView.

I am a little scared by what the author refers to as NodeControls (which represent everything drawable in the grid: the little plus sign, the checkboxes, the node text, etc.), but the fact that there’s a Draw method on the NodeControl class suggests that they don’t all have to be individual WinForms controls (but can be, e.g. in the case of an edit box or combo box).

I haven’t actually used this control yet, but it looks intriguing. It looks like it may have a steep learning curve, but if you actually needed some level of flexibility, it looks like it might be a winner.

If anyone has used both VirtualTreeView and Advanced TreeView, I’d be very interested in hearing how they compare.

Finding unused parameters in Delphi

Yesterday at work, I was looking at a method that had about fourteen parameters, and I wasn’t sure whether it used all of them. The compiler doesn’t warn on unused parameters (nor should it; just about every GUI event handler would warn about the unused Sender parameter!), and I didn’t want to manually search through the code to see if each parameter was used.

Then I got a bright idea: use SyncEdit. Highlight the entire method (including the declaration — everything from “procedure” to “end;”) and hit Ctrl+Shift+J. If an identifier shows up more than once in the selection, it now shows up with either an underline or a box around it (except for the one with the cursor in it).

Then just skim the parameter list. If there are any parameter names that don’t have an underline, a box, or a cursor, then those parameters are unused and can be deleted. Sweet!

Editing YAML in SciTE

I was editing a big YAML file in SciTE a couple of days ago, and I wanted to be able to collapse one of the sections. SciTE has folding support, but only for languages it recognizes. If it knows you’re editing C, it’ll fold based on where your braces are; if you’re editing Ruby, it’ll fold based on do..end and such.

Took me a minute, but I figured out how to get folding for YAML: you just select “Language > Python”. Like YAML, Python’s structure is defined by indentation, so it works like a charm: little “-” symbols appear in the gutter next to parent elements, and you can collapse away.

If you do a lot of YAML editing, you can tell SciTE to always use the Python highlighting/folding rules for *.yaml. Go to “Options > Open python.properties”, and add *.yaml to the file.patterns.py line. Mine now looks like this: