Fresh Air

Fuzzy's take on AIR -- see my previous post on collaboration. I think AIR will play a *big* role in this.

Collaborative Systems

Tim O'Reilly re: an upcoming OSCON session...

I've been thinking lately just how much software developers take the existence of version control for granted, and how... web 2.0 applications don't offer much in the way of version control functionality...

The future we face is one of massive collaborative systems. How we design those systems, and how we build critical freedoms into them, shaping their architecture to support either participation or centralized control, is one of the great challenges facing the technology community today.

I worked on conferencing software for a couple two, three years in the early 1990s. There was a lot of expectation then that collaboration would find its way into every "single-user application" on the desktop. Then the web hit the scene and eventually evolved its own ideas about collaboration, or at least participation.

Other than a few notable examples there is still surprisingly little really good collaboration on the web. I'm not even sure what that is. Maybe it does exist and I could collaborate with you to find that out.

Wikis for me remain a great example, but still real collaboration is hard. Wikis have a way of devolving into conversation-like- and ownership-like-models for pages.

I expect by Web 2.5 or Web 3.0 we'll see collaborative systems more like where we were heading in the early 1990s but with a heavy dose of "the web" guiding everything for an even better multiplying effect.

Wii: At It Again

Nintendo keeps moving forward. No big red buttons. Mario Kart for the Wii will almost certainly be my new favorite.

The Big Bopper

Exploratory Coding

In a dynamic language I can modify a small bit of code and run just enough tests to try those changes. Then I can progressively run more tests and fix those that are broken because of my changes.

Is there a way in Haskell, or Scala for that matter, or OCaml, to "suspend" checking on things that are "already typed" in order to do something similar?

Another way of looking at this is it is "exploratory programming" -- I may break all kinds of things I don't care about as long as I can fix them incrementally as my explorations settle out.

i.e. I don't want to tell the type checker something should be typed ∀α.α. I just want the type checker to allow me to work on one small things even though I may have broken type checking for a lot of code I am not worried about at the moment.

Push The Big Red Button. Yes, *That* One.

From the Seattle Post-Intelligencer...

Microsoft Corp. is turning to an oversized red button in its latest bid to broaden the appeal of its Xbox 360 video-game console.

The company announced plans Tuesday to introduce an alternative Xbox 360 controller, featuring a large button in the style of a game-show buzzer, meant to be less intimidating to new gamers...

"It's super-easy to use," said Shane Kim, the corporate vice president in charge of Microsoft Game Studios...

The controller, dubbed the "Big Button Pad," won't be sold on its own initially, and it's not expected to supplant the regular Xbox 360 controller. But Microsoft hopes more game developers will make use of it. The company showed versions with large buttons in different colors, not just red...

"We're certainly not feeling any pressure to react to anything that Sony has done," Kim said.

Elementary

Some things the primary public education system in the U.S. hardly addresses but should, not to mention graduate and undergraduate business schools:

• System Dynamics
• Queueing Theory and Models
• Reasoning
• Organizational Communication and Cooperation

And some others I'll think of later. Oh, and memory tricks.

Seaside

Well I went to the beach for a few days, but that's not what this is about. Here's what this is about: Cincom is going to be emphasizing, supporting, contributing to, etc. Seaside for their Smalltalk. That's a great move, and right down the middle of how open source works.

Cycle Time, Value Streams, and Organizational Whitespace

I taught and coached agile software development a lot over the last many years. A common question was "What about metrics? I need an agile that supports metrics. Our organization does metrics. Or will." Often the people asking the question had little if any understanding of "metrics". Often they thought that "metrics" (the kind in "quotes") must be really complicated, and so this agile thing where you cheat and cut corners certainly must not "do metrics".

Often the people asking the question were asking because *their* managers, QA team, whoever were telling *them* or asking *them* about "metrics". Often neither group of people had much of an idea of what "metrics" are, not to mention which are valuable or how to collect them. But since the term is spelled "metrics" (the kind in "quotes") they must be really complicated, and so "important".

My response (after asking them what kind of "metrics" they are currently gathering, how do they use them, and have they seen improvement from that effort, *and* after finding out, no, there is little they collect, less they use, and zero improvement), my response after all that is that an "agile" approach to "metrics" is like an "agile" approach to *everything* -- try to make consious decisions, try to have an idea of what to expect, and try to do it in small, measurable(!) steps so as to have a hope of making any sense of it.

Elaborating, I would explain that "cycle time" to "get business value into production" is a really good measurement for an organization, but that cycle time is *the* most difficult to improve in any significant way. (Here is where we would spend less than an hour doing a *really* simple, quick-and-dirty "value stream map" in order to start thinking about how to measure cycle time.)

Beyond, or even before, measuring cycle time in any detailed manner, just thinking for an hour about your "value stream" and roughly where time goes, and whether that time should be counted as "waste" or "value" is exceedingly useful for a team. In fact the activity can help a team understand who is (or should be, or could be) "on" the team, what changes are within the power of the currently defined team to make, what changes will be more difficult because they go beyond the purview of "the team" per se, and so on.

The other challenge is that measuring cycle time assumes the value being added is the highest-priority value (or as close to that as possible) for the organization. Before spending a lot of time measuring cycle time, or anything else for that matter, a useful excercise is to get a quick survey across the people and organizations in the value stream as to their awareness and consensus on value priorities and decisions. If these people and organizations are not "aligned" (and they typically are not) there will be mixed priorities, misunderstandings, and so delays and failures.

How do these organitions make decisions? If they actually do make decisions together, are they accountable (metrics?) in any way to uphold those decisions?

Surprisingly (or not if you've been around as long as I have in several organizations of various sizes), organizations are emphatically *not* designed for effectiveness if the measurement (!) is getting prioritized business value into production as soon as possible (and keep it there correctly). How is your organization "designed" if that term could be used at all?

I've participated in some significant "re-orgs" and I can say with certainty they are rarely "designed" for or from any such measurements. Based on the reasoning(?) and politic'ing I've seen in "re-org" meetings and smoke-filled back rooms and hallways, an argument could be made that the opposite is true: organizations are typically designed to *impede* progress.

Sorry, that's the way it is. If you're organization has figured out how to "manage the whitespace in the organization chart" you have a *keeper*. Organizations are "systems" and attention has to be paid to what are the goals of the organization and whether the organization is "aligned" to those goals and whether the "system" is designed to effectively address those goals and whether they have the fairly simple-yet-seemingly-impossible-to-apply tools (like simple "metrics") to continuously improve toward those goals.

It's a system. Apply the universal laws of systems or ignore them at your peril. I'm done.

Incremental Development

Bill Venner's asks...

Do you think type inference will change the dynamics of the static versus dynamic typing debate?

For some people, yes. But not (yet?) for me.

I do not see dynamic languages as only "saving key strokes". Dynamic languages for me also save the cycle time from a small idea to its incarnation as running code.

The languages like Scala and Haskell that I have tried, to the extent I have tried them, do save me key strokes. I have not crossed over the hurdle to where they save me cycle time to running code, for a few reasons:

• Running small snippets of code, especially code that I have changed out of a larger body, is easier for me in dynamic languages. Those type inferencers still want to infer everything and seem to have low tolerance for incomplete thoughts.
• Scenarios that are fairly easy for me to envision in a dynamic language, functional or imperative, tend to involve various type theories that I know little about. The literature is still not very good for programmers new to the modern type inferencing languages and modern type theory. My sense is picking this up by pairing with someone already imbued with "type-first" programming would be fairly easy, much easier than picking it up solo with the available beginner's books and web resources.
• Test-first programming has been done for a long time in dynamic language cultures. This pre-dates Kent Beck's Smalltalk sunit library by a couple of decades. The Lisp read-eval-print loop and the Smalltalk workspace have been the instruments for hypothesizing how some code should work, and then working it for a long time. xunit tools, Fit, etc. are somewhat more formal frameworks for the dynamic way or programming - writing a bit of code with a test, capturing the transcript, and repeating that every so often. Good testing is necessary to be successful with any programming language, and I can go fairly quickly with a simple language that stays out of my way, and a reasonable test framework for capturing and repeating many small theories of how the code should work.

If I had to make a prediction, I would not see type inference have much significance in programming over the next five years. Beyond that I think better analysis tools and more formal methods will have a greater influence over programming, but I am not the one to predict whether the current static inference tools will play much of a role in that evolution.

If anything I predict the current static inferencing tools to drive more programmers to dynamic languages *because* they want the simplicity of better languages than the Java-like ones but they suffer too much from type inferencing and various type theories for languages like Scala and Haskell.

Mono-a-Mono

(My creative titling really is suspect this time.)

Anyway, here's a quote from the Bonjour (Zeroconf) email list regarding the Mono Zeroconf libraries and the "official" dotnet...

I've seen the Mono Zeroconf implementation but since I'm not using mono, I'm using full-on .NET, I don't think licensing would allow me to mix and match that stuff without getting into trouble.

Huh? There is something in the "official" dotnet product license that prohibits the use of software developed for Mono???

If this is true, then how sad. If this is not true, then MSFT really goofed with their FUD to the point of causing this confusion. I suspect the former.

I'm not sure which is the more sad scenario!