An interesting analysis from the New York Times of the progressive replacement of traditional fixed-line phones by mobiles.
The Count – Users Are Tossing Their Landlines Overboard – NYTimes.com
I’m going to have to read these articles. Jason Yip recommends Geeking with Greg: Early Amazon as a fascinating insight into the inception and growth of Amazon.
Steve Freeman has put together one of the most thought-provoking software development articles I have read in a long time – based on application of ideas from a New Scientist article.
I’m always interested in how other parts of the industry views the key issues in mobile and digital music publishing. It seems like a few people got together for a conference on this topic on 23 September in London. Here’s a few links about the event
EconMusic – the economics of digital music : Blogs : BCS
EconMusic Video: Billy Bragg In Reuters’ Conference Wrap-Up
EconMusic: Direct-To-Fan: Radiohead, Marillion And The End Of Labels
Over recent years I have occasionally found myself involved in the web and mobile front-end of systems which provide a way to buy and download mobile content, including games and applications, and I am always on the look out for information about what works and what doesn’t. Here’s a critique of T-Mobile’s App Store:
Wendong’s Smart Phone Weblog » T-Mobile’s new App Store: huge disappointment
The industry in which I work involves a fair amount of content delivery over HTTP. or at least it does when the rest of the system is in place to allow people to buy stuff. As such, we have a fair amount of operation and deployment issues around keeping this working. For each new customer in a new part of the world there is a decision about how to serve content and, most importantly, where to serve it from. Making the wrong choice can lead to latency, errors, increased cost, and inflexibility.
So the announcement that Amazon are setting up a service to cater for just this situation is an interesting one. The premise is that Amazon will use their increasing global network of “cloud” servers to shuffle and cache content around the world, and use that adaptability to provide downloadable content from the most appropriate server for the end user.
Every time I read one of these “cloud” announcements, I get a small feeling that I should make some time to prototype something like our current product using these technologies. The potential pay-off of outsourcing the infrastructure could be enormous.
Technology News: Web Apps: Amazon’s New Service to Rain Content From the Cloud
From time to time we go through a bout of recruiting, and part of that process is inevitable trying to sort the wheat from the chaff to decide which ones to bring in for a detailed interview. Naturally one of the first things I do when presented with details of a new candidate is to look them up on the web. Obvious things such as a google search for the candidate’s name, looking them up on LinkedIn, facebook etc.
What usually surprises me is how little use most candidates make of this. When applying for work, your name is your brand, and making sure that the best information is easily available to potential employers seems an obvious thing to do, yet so few candidates bother. Instead, the overwhelming impression for most candidates is either that they have practically no internet presence at all, or that their web footprint consists of holiday snaps and mildly embarrassing facebook/twitter chat.
My top tips if you are thinking of looking for a new job.
Above all, remember that potential employers will be looking, so make sure you have a say in what they find
One in Five Employers Uses Social Network Sites When Hiring People
Back to thinking about stories in the agile software development sense.
For the first time this iteration we have reached a situation where two stories were left incomplete at the end of the iteration. I could give a bunch of excuses about changing priorities during the iteration, but the point is that agile processes are supposed to be able to cope with this kind of stuff.
So now we are at the point of deciding what to do with these stories. Luckily, the guys at Elegant Code are also facing this problem, and discuss some options in a recent blog post.
Elegant Code » What to Do with Left Over Stories
In our case, the discussion is still proceeding. From an agile purity point of view the suggested approach of throwing the part-completed stories back into the pot for re-estimation, re-prioritisation, and re-scheduling is certainly compelling.
A few years go I wrote a series of articles for The Java Ranch Journal entitled “Small and Simple Web Applications – the Friki Way”. The series showed an example of developing a very simple wiki (collaborative editable web site) in Java using Test-Driven Development (TDD) and a form of agile project management.
From time to time I refer someone to these articles but it has been tedious to find and gather all the individual article links. This post contains those links, so I can just give out a single URL in future.
Unfortunately I never got around to continuing the series beyond that point. Maybe one day I should …
It must be that end-to-end software production process is on my mind. I keep spotting interesting articles about the topic. Here’s one from Digital Dim Sum which delves into the way that requirements find their way into development, contrasting a “push” of requirements with a “pull” of information..
Don’t push requirements – pull information | Digital Dim Sum
My favourite at the moment is a more “pull”-centred process than many I have seen. Anyone is free to write and contribute “user stories” at any time. From time to time ones which seem valuable are “planning poker” game for estimation. Before each iteration of work, a mixed group of stakeholders gets together to pull a fixed amount of development effort from the pool of available estimated stories into the next iteration schedule. Developers then pull stories from those scheduled for the iteration, work on them and place them in a pool of implemented stories. When the integration test team are ready, they pull a build containing stories implemented so far and test it. Meanwhile the customer deployment team may pull and deploy any tested build at any time.
For years Frank Carver has been paying attention to the strange world of convergent technology. During that time he has discussed and researched broad subject areas, come to some surprising conclusions, produced and distributed digital media, scattered ideas and opinions like sparks from a firework, and above all consulted for businesses both large and small to help develop and deploy successful systems, services, and products in this highly complex arena.
