basically i have yet to find a source control ecosystem that doesn't have massive suck somewhere along the line. take mercurial and bitbucket for example vs. github. in the latter, if you go into a branch and down into the source tree, you get decent urls that do not have anything like a particular revision hash in them. whereas in bitbucket, they force you into a given revision (presumably tip of tree when you start browsing) which just seems stupid to me.

"The problem is we build on the assumption that we should not fail, not the assumption that we are bound to fail, but with early detection and fast recovery/exploitation we can turn the situation to our advantage. That means organisational structures that are agile before the crisis, not bureaucratic. It means network connections built and sustained in advance, the ability to delegate power when needed without complex process."

Some nice food for thought about what software Kanban might be.

While I am not particularly a user of Facebook, nevertheless I am interested in how it might have come so far. The overall catch phrase of the presentation of People Times Process is certainly not something I'd take issue with.

Organizations - well, people, since orgs are just the people in them in some sense - seem to have a big problem realizing how fubar they are. An analogy I like to use is your local (at least in the USA) public transportation system.

Most likely, it frankly sucks. For example, the schedules suck, especially if you are doing any transfers in the system, and doubly especially if you are doing any transfers among systems.

Yet if you ever see the maintenance yard for the stuff, or the control room, or the computers, or whatever, it actually probably could almost seem impressive. We've got all these buses/trains/computers/whatever here! Surely they can zip out and cover the place well and lead to happy fun commute times! And yet obviously that possibly fancy looking infrastructure that seems so ripe with potential when seen in aggregate almost utterly fails to translate into something that really really really meets and oversatisfies the end user.

Sure, this is partially just a matter of not realizing how big the lay of the land to be serviced is. Sure, it is perhaps due to not thinking about all the real intricacies of multiple lines, lots of people, limited hardware, the need for overcapacity for fail-over, the damage of knock-on effects, yadda.

But the point is that if you aren't the end user and you are instead somebody looking at the infrastructure, you can easily totally underestimate just how much it totally freaking sucks to be the end user.

Agile vs. Waterfall, oy veh

People who aren't, for whatever reasons, already bought in to Agile will be asking you why they should do agile. One way of looking at it is, wouldn't Waterfall clearly suck? So at least go for the lesser of the two evils :-0

P.S. yes, I am using 'waterfall' in the colloquial pejorative sense vs. the actual sense (go see Leprechauns of Software).

Cognitive Dimensions

A good designer presumably knows how to talk about usability at a higher level. A particular attempt at codifying that higher level is Cognitive Dimensions, sort worth musing over.

Managing the Design Factory was, i thought, very good. It succinctly and clearly gives one the lay of the land. It starts by taking the perspective that everything costs money, and the Design Factory should be aware of this and should look at the bottom line as much as anything else. Then it goes through the ideas, models, metrics, systems, organizations, architectures, customer interactions, et. al. that the author sees as crucial to respecting that bottom line. Not just in the sense of making things on the cheap, but trying to make something terrific for the customer yet affordable and respectful of the people doing the work all along the way.

prediction is hard. you have to have some previous history, really. and even then we know past performance is no indicator of future returns. but, anyway, fun with predicting schedules is not going to go away any time soon, everybody wants to know dates for things.

"1. Agile is a software team focused method that can be scaled up to all parts of an organization with a software development component

2. Agile is a team based method that can be used anywhere there are teams – whether software is involved or not (yes, you can use this in your church meetings)

3. Agile should be expanded to include the entire organization, from business stakeholders to support folks. The intent should be enterprise agility."

Nice to hear about how some folks really aim for quality.

What do: CPM, DBR, CONWIP, JIT, etc. all have in common?

Security is hard. I mean, even understanding the terms and the limits of knowledge is hard to follow.

Usability, or the general lack thereof, kills me. I went to the gas station. The pump I pulled up to had a tiny note on it when I went to put in my credit card that said basically: broken, move to another pump, or pay inside. So I go inside and say I want to fill it up on my credit card - which I can do when the pump reader is not broken - but the person in the store said oh no you either have to give me a specific $ figure, or move to another pump.

So I told him I'd never give them my business ever again and drove away. Man.

Sure, models aren't the territory, but food for thought, nevertheless. I'd rather be working with a model even if I dislike it - maybe just a kind of riposte, something to egg on further thought.

"Scrum is three roles, four meetings, four artifacts, and two levels of commitment. What does it say about you or your organization if you’re not willing to try and follow a minimal process with just these four basic concepts? Picking and choosing from these minimal processes and practices devastates effectiveness for many reasons."

Of course, the devil is in the details.

I thought there was a long-running meme that security and usability are pretty much fundamentally at odds with one another. It is therefore refreshing to think about the possibility of security and usability being successfully blended together for an all-'round win.

Contracts might be a way to foster more agility. I've heard it said that the DoD is going to mandate agile or lean approaches from its contractors. I've seen discussions in the agile community about how to craft contracts that support collaboration and bonuses rather than defining delivery dates and penalties. Maybe we can re-frame the discussion up front.

Naive functional fibonacci is pretty sad performance-wise. Even if you are using a lazy, memoizing language it probably isn't as good as the imperative version that only has to keep track of the last 2 values as it moves on up towards the final n. How would we ever have a system that could look at something like fibonacci and transform it magically (which is of course in a lot of ways a really bad, dangerous, idea because it makes debugging even harder in the long run perhaps) into something sane from the perspective of loads and stores?

If somebody says to me, I want Agile Tools, I sort of think they are missing the point. The tools should come after the philosophy has really been learned and imbibed. Ideally, the tools should be pretty custom, should respect the fact that every situation is unique. On the other hand, it gets me thinking that maybe there are tools which could fit into that request: tools for quality. If you do, say, Scrum but don't have the engineering chops, you are going to - basically - suck at hitting your sprints. What are all the underlying, fundamental aspects of Quality that have to be met to really do Agile well? What tools can be made available there? QuickCheck, ADD, BDD, cloud-based concurrency tests suites, systems like IMVU's push-to-production-with-no-fear, what else?

If performance were not an issue, it seems like Declarative programming style is >> Functional is >> Imperative. Things like Prolog are great for their sweet spots. I wonder, wish that kind of usability could be extended and refined. I wonder if Attempto Controlled English would be a close-enough-to-natural-language approach to mix in with Declarative style. Dreams.