As I enter serious middle age, and I retain memories of youth while gaining a certain wisdom of age (and still have the energy to care), I find myself wondering about some of the canards I have heard for decades. One of them is that the younger generations are always somehow worse than they were “once upon a time.” I really think that’s not true, and here’s an argument to support this claim. Continue reading
True story: thirty-something years ago, at institution X – a very large institution with tens of thousands of employees – there was a particular institution-wide department in charge of providing all computing services to all other departments, even though the computing needs and expertise of each department varied very, very widely. Some departments could pretty much take care of their own computing needs – esoteric as some of them were – whereas other departments lacked the local skills to manage word processing software on desktop computers of the day.
Some new research suggests that evolutionary fitness is predictable even if the route taken is not. This actually bears on the difference between function and behaviour, both in nature and in designed products.
One of the most critical parts of systems modeling is defining the boundaries between systems. Different boundaries will lead to different system models, so choosing the “best” boundaries for a modeling goal is really important. Here’s how I do it.
Warning: this is a long one; and I’m very much in favour of gun control.
There’s plenty wrong with Canada, but one thing we’ve got right (in principle at least) is a strong gun control. Given the recent spate of shootings, both in Canada and the US, there has been a lot of discussion about gun control. I’d tried to argue for strict gun control on Google+, but the arguments became scattered over several discussions and so may have lost some of their effectiveness. So I’m going to try and put them all in one place here, in the hope that my position will make more sense.
Conventional wisdom tells us that we design technological artifacts in response to perceived needs; that is, needs drive technology. The formidable Don Norman recently wrote a web article suggesting that, contrary to convention, technology can drive needs. Norman’s article caused quite a fuss in the design research community, in which only some agreed with his novel perspective.
I don’t see the benefit of arguing one way or the other; it’s on par with trying to decide which side of a coin came first, the head or the tail of it. I think a better way to view it is as an infinitely looping process whereby designers adjust reality to balance our needs with respect to a number of other forces, one of which is technological change.
In Dörentrup, Germany, you can literally call up the streetlights. It saves energy, but at what cost?
On 30 July, Time posted an article about the town of Dörentrup, Germany, where the local council recently voted to turn off streetlights at night to save energy and carbon emissions. This naturally caused a fuss. What’s the point of streetlights that are off when you need them?
Town resident Dieter Grote and his wife, working with the local utility company, came up with a solution. You can now use your cell phone to send a special ID code to the utility, and the streetlights with that ID (grouped by stretch of road) will come on for a certain length of time.
The energy saved by turning off the lights at night saves the town (population, around 9,000) about 12 tons of carbon emissions per year. That’s not bad. And other towns around the world are asking Dörentrup for help to set up their own similar systems.
While it’s fine and good to try to lower consumption – especially when no one needs the service – I think their solution is too complicated. First of all, there is a carbon footprint associated with the machinery and electronics needed to keep this new service running; I don’t get the sense that anyone has compared this footprint with the alleged savings.
Next, this system ties the utility infrastructure directly to the phone system quite deeply, in a rather centralized way. You call the magic phone number, which no doubt accesses a facility in one of the utility’s plants, but by way of your phone provider. The centralized system then has to understand the ID code, which can be dialled in or spoken (requiring voice recognition software). The IDs are stickered onto every streetlight. The system then has to direct the pertinent streetlights to turn on, keep track of the time, and then direct them to turn off.
If something goes wrong at the system’s home base, the streetlights won’t come on, even though they otherwise could. If your phone’s battery dies, or you lose signal strength, you can’t control the lights, even though they would respond otherwise. If you don’t have a phone, or your hands are otherwise occupied carrying groceries or whatever, you might not be able to use the phone – again, you can’t get the streetlights to work. If you can’t read the ID sticker on the streetlight (because the streetlights are off), then you might enter the wrong ID or be unable to figure out the ID at all. Vandals could change the ID stickers.
These are all failure modes that don’t need to exist. There are probably others that I haven’t thought of.
I would suggest something simpler.
Residents would carry some kind of semi-active sensor, like a battery-assisted RFID tag, or the GPS locator already in many cell phones. A small unit would be attached to every streetlight, that can detect the presence of a nearby RFID tag or GPS locator. The unit then turns on the streetlight, and keeps it on till the signal moves out of range. This can be rigged to ensure that two or three streetlights are on for each person.
Assuming these kinds of sensors have the required range (and I think they do), I think this is a better solution because:
- no hands are required to activate the system;
- no hardware/software needed at the central utility facilities;
- power for the streetlight unit can be drawn from the streetlight itself;
- the RFID battery can last ‘way longer than a cell phone battery;
- no need to remember phone numbers or look up streetlight IDs;
- this kind of distributed/decentralized system is more robust and resilient than centralized alternatives; and
- fewer streetlights would be on, and for shorter periods.
In other words, I think my suggestion is more effective, without giving up efficiency. It compartmentalizes the whole on-demand streetlight system so that failures anywhere are less likely to affect related systems.
Seems like a no-brainer to me.