Kanban development oversimplified: a simple explanation of how Kanban adds to the ever-growing Agile toolkit:

When you place focus on how quickly you can get functionality done, and have the ability to measure just that, then the estimates don’t much matter. In fact, many using a Kanban approach have simply stopped estimating at all. Yes story sizes vary, but being able to give a wait time plus or minus a few days is sufficient for many organizations’ concerns.

Some do still estimate stories. Then use those estimates in conjunction with cycle time. Using a spreadsheet we can calculate the average cycle time for stories with a given estimate. If you do this, consider placing a handy chart next to your Kanban board showing estimate in one column, and wait times in adjacent columns. With this you’re answering the real question stakeholders are asking for when they get estimates: “when am I going to see this functionality in the software?”

If your stakeholders are like mine, they don’t want to know when they’re going to get this functionality, the want to know when they’re going to get all this functionality. I find that if I place stories into a spreadsheet with start and end dates, and calculate cycle time, if I select an arbitrary time period — say a two or three week time period — I can see how many stories where completed during this time period. For instance I might see the team finished 22 stories in 3 weeks — that’s about 7.3 stories per week. Given a backlog of 100 stories I can reasonably infer that it’ll take between 13 and 14 weeks (100/7.3). That’s yesterday’s weather for Kanban — at least the way I calculate it.

If I know that during three week time period there where 15 working days and that 5 developers worked the entire time, that’s 75 developer days. Knowing that lets me calculate the average number of developer days per story: 3.4 (75/22) — Which is darn close to pi — which makes me believe it has to be right. ;-) This number, 3.4, is what XP practitioners referred to as load factor.

“Over the Top: The new war for TV”:

As it is, I’ve been without cable/satellite for two years now, and I mostly don’t miss it, but I have very little interest in live sports. I’ve realized one big problem with the Apple TV approach, though. An application-centered interface paradigm is fine for a smartphone or tablet, but a television wants a content-centered interface. An icon for every service is passable (although not ideal) for replicating the channel surfing experience, but I want a screen which shows me all my subscriptions and favorites across every service on the device. If I want to answer the question “Are there any new episodes of ‘Castle’” I shouldn’t have to first answer “am I getting ‘Castle’ through iTunes, Hulu, Netflix, or the ABC app”.

Source: Coyote Tracks

Little, Big:

Part of me rebels against this observation, for “people like me” form a terribly skewed sample. We do a lot of things with our hardware that the Median User does not do—like install software. (If the majority of applications on your phone, pad or even computer didn’t come with it, you aren’t a Median User.) For people who want to have an iPad as an adjunct to their laptop, the Mini may be near perfect. For people who want to have an iPad as their one portable device, though—something that they really can do Serious Work on—the Mini may not be the right thing.

Yet I can’t shake the notion that I run into a paradox with that premise. Most “Power Users” wouldn’t want to replace their laptops with iPads, yet I suspect it’s only the Power Users (and a subset of them) who would look at an iPad and wonder if they could replace their laptop with it in the first place. The best way to use an iPad is not as a laptop replacement. It’s as an iPad. It’s quite possible that millions of people would rather have an iPad instead of a laptop. And it’s quite possible that many of those would, given a choice, rather have a smaller, lighter iPad, just like many of us who want an iPad and a laptop would.

So what does this mean for non-iPad tablets? If the iPad Mini is the better size, then all those other tablets were onto something, right? Yes, but the original iPad sells more than all other competitors combined. Either buyers vastly prefer 10″ tablets, or buyers vastly prefer iPads. Given that other 10″ tablets have been about as popular as a vegan activist at a Texas chili cookoff, I know which one of those I’d put money on.

Source: Coyote Tracks

Apple’s design problems aren’t skeuomorphic:

In the end, what’s wrong with iOS isn’t the dark linen behind the app icons at the bottom of the screen, but the fact that iOS ought to have much better inter-application management and navigation than users fiddling with tiny icons. I’m fairly sure most Apple users would gladly continue to use what are supposed to be skeuomorphically challenged Calendar or Notebook apps for another thousand years if Apple could only solve the far more vexing software problems of AppleID unification when using iTunes and App Store, or the performance and reliability of the same. And yet these are the twin sides of the same systems design problem: the display layer surfacing or hiding the power within or, increasingly, lack thereof.

Source: counternotions

Reply to an open minded reader:

The second is even more important, and is about the data model. Redis is not the kind of system where you can insert data and then argue about how to fetch those data in creative ways. Not at all, the whole idea of its data model, and part of the fact that it will be so fast to retrieve your data, is that you need to think in terms of organising your data for fetching. You need to design with the query patterns in mind. In short most of the times your data inside Redis is stored in a way that is natural to query for your use case, that’s why is so fast apart from being in memory, there is no query analysis, optimisation, data reordering. You are just operating on data structures via primitive capabilities offered by those data structures. End of the story.

However, I would add the following perspective on that.

If you do judicious use of your memory, and exploit the fact that Redis sometimes can do a lot with little (see for instance Redis bit operations), and instead of just have a panic attack about your data growing outside the limits of the known universe you try to do your math and consider how much memory commodity servers nowadays have, you’ll discover that there are a tons and one more use cases where it’s ok to have the limit of your computer memory. Often this means tens of millions of active users in one server.

And another point about the data model: remember all those stories about DB denormalisation, and hordes of memcached or Redis farms to cache stuff, and things like that? The reality is that fancy queries are an awesome SQL capability (so incredible that it was hard for all us to escape this warm and comfortable paradigm), but not at scale. So anyway if your data needs to be composed to be served, you are not in good waters.

Source: antirez weblog

Thread: Outline your Twitter conversations.:

I just released a tool called Microliner that lets you outline your conversations on Twitter.

I don’t think anyone has ever had a tool like this, so I’d better explain how it works.

1. Open up the Microliner Workspace window. Enter an idea. 140 characters or less, please. :-)

2. Click the Tweet button. It goes out to all your followers on Twitter.

3. Wait a minute or so. Click the Replies button. Microliner calls Twitter and gets the replies, and arranges them under the messages they are in response to.

4. You can then reply to the replies, and so on. Once you get going, you can participate in a dozen conversations at once, and not lose track of where you are or who you’re conversing with. It really works.

The tool is available now: http://microliner.opml.org/.

I thought I was done developing on Twitter as a platform, and then I get an idea like this, and I have to do it, whether or not its advisable. :-)

Source: Scripting News

★ Kindle Paperwhite:

Amazon’s goal should be for Kindle typography to equal print typography. They’re not even close. They get a pass on this only because all their competitors are just as bad or worse. Amazon should hire a world-class book designer to serve as product manager for the Kindle.

Source: Daring Fireball

A simple market-based solution to Apple Maps vs. Google Maps:

Why would Google be so blasé? One big reason is that Apple’s users pay nothing for the app. And, because users pay nothing, Google can ignore those users’ suffering while relishing the sight of Apple embarrassing itself.

To fully understand what’s going on here, it is essentiall to understand the difference between customers and users (aka consumers). Customers pay. By not paying, and functioning only as a user, you have little if any economic leverage. Worse, you’re the product being sold to the actual customers, which are advertisers.

This Google vs. Apple thing reminds me of my days in commercial broadcasting. There too consumers and customers were different populations. Consumers were listeners and viewers whose ears and eyeballs were sold to advertisers, who were the real customers. Listeners and viewers had no leverage when a station or a network got in the mood to kill a format, or a show. We’re in the same spot here, at least in respect to Google.

Source: Doc Searls Weblog