Technology

A Story About Rob’s Dad

4th December 2022 by rmj 8 Comments

My dad died two years ago today. To mark the anniversary, here’s a story. The story features several of my favourite things, including: mathematical analysis, football pools, Butlins holidays, retro geekery, repair, and of course my dad.

The System

If Caroline’s dad and mine are anything to go by, having a clever uncle was a powerful factor in working-class boys escaping pre-war poverty. Peter had his Uncle Reg, who taught him to play chess. My dad had Uncle Arthur. Arthur was a veteran of the Great War, invalided out I think. For a while, our family had his hand-written war diaries, until they were snatched back by another family member, something that upset my dad greatly.

Arthur had introduced my very young dad to The System. For Arthur I think it was horse racing. The two of them would pore over The Sporting Life, analysing the horses’ form, scratching out some calculations to eventually come up with a mathematical assessment of the odds offered. I don’t know how good Arthur’s system was, but it clearly had a profound effect on my dad. As I grew up, he had a System for analysing everything. Sometimes it was the horses, eventually, when he had a little cash to invest, it was the stock market. He even applied it to his work, assessing kids’ reading ability. But in the early 1970s it was the football pools.

The Football Pools

For the uninitiated, football pools were a hugely popular form of betting in mid-20th century England. The art was to predict which of the 46 Football League matches on any given Saturday would be score draws. Eight correct guesses would win you a First Dividend, and a share of the pool. It was so popular that armies of agents would walk door-to-door on a Thursday evening, collecting the completed coupons and stakes, and pocketing a 12.5% fee for their trouble. It strikes me that the agents probably had the best of this. But my dad reckoned he had an edge. The System, as I first remember it, involved an array of index cards, with years of match scores written on each card. Rothman’s Football Yearbook was an essential part of The System, as it detailed all the relevant results from previous seasons. Each week, referencing the data on the cards, Dad would come up with an estimate of the likelihood that each match would be a score draw, and put his crosses on the coupon accordingly. “Come up with an estimate” rather glosses over the detail, which involved a great deal of calculation. Surprisingly, Dad had no higher mathematical education at all, but he was self-taught in some pretty chunky statistical techniques.

Calculating The System by hand was intensely time-consuming and error-prone, so he bought a hand-cranked, mechanical calculator. Realise, in the days before electronic calculators, it was a choice between a slide rule (slow and giving only approximate answers) and one of these amazing contraptions. It required a kind of physical long multiplication, with each digit being processed by an appropriate number of rotations of the handle. [I’ve only just learned that it was a Marchant XL, made between 1923 and 1936, see it on video here.] He must have developed a strong right arm! I don’t remember how long the mechanical calculator was in service, but with the advent of desktop electronic adding machines, it was eventually replaced with a very basic electronic model.

On a foggy Saturday night in November 1973, the very first week that the electronic adding machine had been used, we went to the fair on Hearsall Common. It was a typical family outing. I was 10 and my sister Helen was five. Probably, a goldfish was won, to be put in a demijohn, and nurtured for a few months until the inevitable demise occurred and it was flushed down the toilet. We bought a copy of ‘The Pink’, the Saturday evening sports edition of the Coventry Evening Telegraph, and my dad checked the results. Score draws: 1, 2, 3, 4, 5, 6, 7…. 8! A first dividend!! As we walked home, I think Dad was carrying Helen on his shoulders, but was so distracted that he walked under a road sign gantry, clonking her on the head. She wasn’t that badly hurt, at least, not so badly as the time I hurled her out of a push-chair, landing flat on her face on a pavement. I digress…

So, a first dividend! We were in the money! How much money though would depend on how many other punters had first dividends, the pot being divided among all the first dividend winners. Some weeks, there would be only one, and the winnings would be truly life-changing. It took several days for the results to be tabulated and the prizes announced. Around Tuesday of the next week, we found out that there was another winner who had picked nine score draws and therefore won nine shares of the pot. It left my dad with a prize of £1,800; about a year’s salary, a major cause for celebration. We booked a holiday at Butlins, Skegness, for the next summer, which was one of the happiest holidays of my life! There was money for presents for the family, and some to be invested; bring on The Stock Market System!

Then my dad did what any sensible person would do in the circumstances. He discarded the cheap adding machine that had earned its cost many times over in a single week, and immediately bought himself the best electronic calculator known to mankind.

The Calculator

HP 9100A image by bobo11, licensed under Creative Commons.

Stanford graduates Bill Hewlett and Dave Packard had started out in the 1930s, in a garage in Palo Alto, California. Silicon Valley as we would now know it, but at that time mostly orchards. Through the 40s, 50s, and 60s, they built up the most prestigious engineering company in the world, designing and manufacturing precision test equipment for laboratories and engineering companies. In 1968, they came up with a new line, the Hewlett Packard 9100A, a scientific calculating machine the size of a large typewriter, and costing $5,000. It might well have been described as the first personal computer, but Hewlett said “If we had called it a computer, it would have been rejected by our customers’ computer gurus because it didn’t look like an IBM.” Instead they called it a calculator.

With the new machine launched, Bill Hewlett turned to the engineers responsible for the 9100A, Tom Osborne and Dave Cochrane. Rather than praise, they got a new challenge: “I want it to be a tenth of the volume, ten times as fast and cost a tenth as much.” He wanted a scientific calculator that could fit in an engineer’s shirt pocket, instead of filling up most of the engineer’s desk.

Needless to say, the engineering challenges were enormous, but over a couple of years, Osborne and Cochrane came up with a design. The snag was the project cost; over a million dollars. “That’s when a million dollars was really a million dollars”, said one engineer. HP had poor financial results in 1970, and the outlook for massive, high-risk launches was not good. Ignoring advice from the Stanford Research Institute to cancel the project, Hewlett gave the go-ahead on February 2nd, 1971. The fascinating story of that product development is too long to expand here, but to cut a long story short, the HP-35, the world’s first scientific pocket calculator, was launched in January 1972 at a price of $395.

There’s a tale from shortly after the launch that gives a clue to why HP was such an admired company. Two of the calculator’s functions are ln (log natural) and e^x. Each is the inverse of the other, so, if you take a number, press ln and then press e^x, you should get back the number you first entered. In the course of exhaustive testing, an extremely obscure bug was found. 2.02 ln e^x gave the answer 2. Dave Packard called a meeting and asked the team what they were going to do, with more than 25,000 units already in the field. Someone in the crowd said “Don’t tell?” At this Packard snapped his pencil and said: “Who said that? We’re going to tell everyone and offer them a replacement. It would be better to never make a dime of profit than to have a product out there with a problem”. Every one of the calculator’s 768 words of program memory had been filled, so the fix involved not only resolving the incorrect calculation, but finding a way to reduce the space occupied by other functions. Nonetheless, a fix was devised and offered to every owner. Only around 30% took up the offer, many keeping the recall letter as a memento.

The HP-35 was a spectacular success. Needing to sell 10,000 to break even, HP sold 100,000 calculators in the first year alone, and 350,000 in the product’s three-year lifetime. Despite ramping up manufacturing, it took 18-months to clear the order backlog. The calculator division became the most important part of HP’s business, delivering more than half of its profits, and relocated to a new campus in Cupertino. There they hired a young engineer to develop calculators; his name was Wozniak and his hobby was building a computer in a garage. Many years later, Wozniak’s partner Steve Jobs acquired the same Cupertino site as Apple’s resplendent headquarters.

I was disappointed to find that the HP-35 didn’t make any moon landings, but it did travel with astronauts on Apollo flights to Skylab in 1973 and 1974. James Burke used to wear one on his belt as he presented the BBC coverage of those space missions.

And my dad bought one for his football pools system.

The Repair

I inherited my dad's HP-35. It was badly damaged by a leaking battery pack somewhere along the line, and failed to come to life. Over the past few years I've developed a habit of taking electronics things to bits, and - just occasionally - making them work again afterwards. This year marks the 50th anniversary of the launch of the HP-35. I felt it was time to lift the lid at last.

The first thing to observe is just how much gold is in this machine! HP's lab equipment was built to last, and designed to be repaired, and it's obvious they brought the same philosophy to the early calculators. By the 1980s, HP's calculators, while still high-quality, were definitely not repairable.

I've been puzzling over the fault for several weeks. The internal power supply is designed to generate three voltages: 6V, 8V and -12V. The first two were present but not the -12V. Some speculative replacement of parts made no improvement. Bear in mind that the componentry is 1970s vintage, but some of the obsolete parts can still be found by diligent search. Eventually, this week I turned my attention to a tiny transformer. You can see it encased in a cylinder of white goop at the top of that circuit board. I desoldered it, and as I pulled it out, it became obvious that one of the leads was broken, probably corroded by leaked battery contents. Resoldering that joint brought the calculator to life for the first time in 40 years or so.

There are still problems: the power switch doesn't work properly, and some keys don't register, so I've got more work to do. But it was a good feeling to see those tiny LEDs light up again.

Ironically, I bought another HP-35 on ebay, advertised as 'not working, for spares only' thinking it would be a good donor for parts. I simply made a makeshift battery pack for it and it worked immediately. It has the '2.02 bug'!

This project has thoroughly obsessed me for a couple of months. I watched a YouTube presentation by a man who has built his own HP-35 from first principles. He said something which sums up my autumn 2022.

I discovered a whole world of classic HP calculator enthusiasts on the web. First I thought they were lunatics, but I couldn't look away. Eventually I quietly became one of them.

The System, revisited

There was one more small pools win, more like a month's salary, than a year's, but then the government put up tax on football pools. My dad was smart enough to know that the small edge he enjoyed on the pools would be eaten up by this reduction in the pot, so he stopped playing. I think he went back to the horses for a while, then the lottery; you may think that is pure chance but dad had other ideas!

We had a second holiday at Butlins in the drought summer of 1976 and I remember the clouds bursting as we came home by coach in late August, the first rain for two months.

There were more calculators. After the HP-35, there was the Novus, then a Texas Instruments programmable SR-56, on which I did my first programming, a golf game as I recall, then the TI-58, with plug-in ROM modules. By this time home computers had arrived and dad brought home the Exidy Sorcerer, a machine with a massive 32kB of memory. "How could we ever fill it?" we said to ourselves. (I renovated that a couple of years ago.) On it went for the next thirty years or so.

He never kicked the habit. In total I inherited more than a dozen calculators including a couple more classic HP's. They are delightful things, and a lovely reminder of my dad, and his System.

A GPS tracker for ultra-endurance cyclists

29th March 2018 by rmj Leave a Comment

Posted in: Rob, Technology

[Preserving this write-up I submitted as an entry in an electronic design competition].

Ultra-endurance cycling events are becoming more and more popular. Events such as the Transcontinental Race (4,000km, unsupported, from Belgium to Turkey or Greece) require cyclists to ride for upwards of 16 hours a day, often catching just a few hours sleep, bivvying at the roadside to avoid wasting time on hotel checkins. Some events, such as the Audax UK “Lumpy End-to-End”, 1,800km in 8 days, require validation by GPS track. Opportunities for charging battery-powered devices are few and far between. While most participants use a dedicated consumer GPS device, or mobile phone, for navigation and capture of their track, there is a serious risk that batteries fail en route. It would be devastating to complete such an event, but not to capture the relevant GPS validation track. The purpose of my device is to provide a very low-power, simple GPS tracker, that can run unattended for days at a time on a single battery charge. It could be used as either the primary, or a backup, GPS tracker for ultra-endurance races.

Requirements

Key requirements for such a device include:

Low-power. Rechargeable battery powered with ability to run for several days without a charge.
Weather-proof. There is a high probability of heavy rain at some point on such a long event. The device must exclude water.
High data storage capacity. Each GPS track point requires 32 bytes, in a suitable binary format. The device must record a point at least every 5 seconds for validation. Hence the device must be capable of storing more than 0.5MB per day in non-volatile storage.

Selection of components

ESP32. This microcontroller has many advantages which contribute to delivering the requirements outlined above. Low-power: The device can operate in deep sleep mode, consuming 10 µA, for much of the time e.g. for 4.5 seconds in every 5 second sample period. While collecting track points from the GPS device, the device is powered-up, but WiFi and Bluetooth are not required, so the radios can be disabled. Miniature. Even in a development board format (in this case the ESP32-PICO-KIT board), the device is small enough to be housed in a compact, lightweight enclosure that can be carried unobtrusively by the cyclist. WiFi. The device operates standalone while collecting GPS tracks, but at the end of event, we need to retrieve the saved track. This can easily be achieved by activating WiFi and a simple web server, allowing the GPS file to be downloaded. Touch-sensors. By using touch sensors as switches, e.g. to switch between tracking and track-retrieval mode, we avoid the need to open up physical ports on the enclosure, thus minimising opportunities for water ingress.
U-blox MAX-8C GPS. U-blox GPS devices are cheap and easy to obtain. They provide support for text-based NMEA protocol, as well as proprietary UBX binary format. However, many of the development boards are not designed with low-power in mind. MAX-8C is inherently low-power, and can be built into a low-power board such as this one from Uputronics. Typical current during GPS acquisition is 18mA, but low-power modes provide potential for this to drop to around 4mA post-acquisition and during tracking.
Winbond W25Q256FVFG External SPI Flash. The ESP32-PICO-KIT provides 4MB of flash memory, but much of this is consumed with firmware and program storage, leaving no more than 2MB available for storing GPS trackpoints. Given our aspiration to record a track for many days at a consumption rate of 0.5MB per day, I identified the need to interface to a further external SPI flash chip. The Winbond W25Q256FVFG provides 32MB of additional flash, which will support 60 days of GPS track recording.
LiFePO4 battery. All the above components run at a standard Vcc of 3.3V, therefore – with a suitable voltage regulator – many options of battery format are possible, including LiPo (3.7V – 4.2V), Alkaline, NiMH. LiFePO4 batteries are an attractive option, because the nominal voltage is 3.2V, and the discharge curve is very flat, dropping below 3.0V only after releasing around 95% of its total capacity. This means that 3.3V devices can be reliably powered without a voltage regulator, avoiding the associated inefficiencies. A drawback is that these batteries are heavier and more bulky than LiPo batteries of comparable capacity.
TP5000 LiFePO4 charging module. The LiFePO4 battery, which is sealed inside the enclosure, can be charged with 5V from a typical USB charger, via an internal TP5000 charging module. To prevent water ingress, a 5V DC jack with rubber seal is used in preference to a mini- or micro-USB connector.
Touch-pad hardware. Touch-pads are implemented with a metallic disc attached on the inside of the enclosure. A steel washer has been used successfully. Further work is required to evaluate alternatives e.g. a copper rivet, for sensitivity and precision.

Design approach

Software is developed in C/C++ using ESP-IDF development framework. Tasks within the framework include:

GPS. Initialise the GPS device with the sample rate and protocol messages required. GPS location acquisition can be accelerated by using AssistNow Offline (u-blox), meaning that GPS information (ephemeris and almanac) can be downloaded from an Internet site over WiFi for 35 days into the future. Then, when the device is powered-on, the relevant day’s offline data is downloaded to the GPS device. This speeds up acquisition from 30 seconds to around 5 seconds. Once GPS location has been acquired, the GPS device sends a trackpoint via UART to the ESP32 host once every 5 seconds. A binary message, UBX-NAV-PVT, is used, because it encodes the location data in a relatively compact binary format. The received UART data wakes the ESP32, which, with minimal processing, writes the location data in the same binary format, via SPI, to external flash. The ESP32 can then return to deep sleep. This 5 second cycle will repeat indefinitely for as long as the device is in track-recording mode. A simple file system is implemented on the flash (esp32_fatflash by Illucius) to allow tracks to be associated as files, and so that they can be deleted by the user, and the storage occupied by that track can be made available for reuse.
Touch-pad. A second ESP-IDF task monitors for touch pad events. A long-press on a touch pad triggers a software event, which switches the device to “track-retrieval mode”. This activates WiFi and a simple web server. This will normally only occur when the ride is over; the device may be powered with external 5V supply at this time, and the additional power consumption will not be a problem.
WiFi / Web server. A third ESP-IDF task, triggered to be created in “track-retrieval mode”, WiFi will activate (could be either as a station on a pre-configured SSID, or as an AP providing a new, temporary SSID). A web server will be started, offering, via a browser page, a list of GPS tracks available for download. Each will be identified according to its start time, which is readily discoverable by decoding the first trackpoints of the binary trackpoint data stored in external flash. When the web client selects a track to download, the web server will decode trackpoints read from external flash, on-the-fly, converting them into the industry-standard GPX file format. The web server will also provide the ability to delete selected files, which will result in an entry being deleted from the list of tracks held in flash, and the flash pages used by that track being returned to a free page pool.

Development status

The hardware elements have been acquired and integrated on breadboard. Each of the main capabilities has been prototyped in software and demonstrated individually, i.e. ESP32-GPS integration, ESP32-external flash (both direct page read/write and via FAT), WiFi and web server, LiFePO4 battery operation and charging, touch sensor detection. The capabilities have not yet been integrated into a single working firmware build; this is work in progress. The current software implementation can be consulted here. Further work is also needed to design the enclosure to accommodate the hardware in a compact, weatherproof format. The build needs to be optimised for power consumption. Initial measurements suggest a current-draw of around 35mA in track-recording mode, but I believe this can be reduced below 20mA with optimised use of deep sleep, and with careful power management of the GPS module. This suggests the device could operate for 3 days on a single 1600mAh LiFePO4 battery, or 6 days on two. I look forward to completing this unfinished work, but wanted to submit an entry for the competition in time for the deadline.

Potential further enhancements

Because the ESP32 is also blessed with Bluetooth, the possibility exists to also track Bluetooth sensors such as heart-rate monitors and pedal-power meters. This would clearly increase power consumption compared to simple GPS tracking, but in certain circumstances it might be an attractive trade-off.

A Survey of Car Park Height Restrictions

19th March 2017 by rmj Leave a Comment

Posted in: Rob, Technology, Travel

Ever wondered what proportion of car parking spaces are subject to height restrictions?

We are currently selecting a camper van and the big choice is between a VW Transporter or Ford Transit base vehicle. The Transit seems better value for money, with superior features in the base vehicle, at a lower price. But one concern is that the pop-top Transit conversion is around 2.07 m high, whereas the pop-top VW is variously spec’ed as 2.00 m or 2.03 m.

How significant is this difference in terms of access to height-restricted car parking spaces?

To find out I built a scraper to collect car park data from Parkopedia. I suspect Parkopedia is not keen on this type of activity; they don’t have an open API, and I seemed to get banned after scraping the site a few too many times. But I’m not exploiting the detail of their data (which is very comprehensive) just aggregating and summarising. Grateful thanks to Parkopedia for the data.

I pulled the data for 13 of the UK’s most populous urban areas: London, Manchester, Birmingham-Wolverhampton, Leeds-Bradford, Glasgow, Southampton-Portsmouth, Liverpool, Newcastle, Nottingham, Sheffield, Bristol, Belfast, Leicester and Cardiff – a total of 242,500 parking spaces – and plotted the percentage of spaces from which a vehicle of any particular height would be excluded.

So what did I find? Well, either vehicle has access to the majority of car parking spaces. The number of spaces that fall between 2.03 and 2.07 is pretty small; about 5%. Although a more cautious person might baulk at taking the Transit under a 2.10 restriction, in which case a further 9% of spaces become inaccessible.

Using OsmAnd+ for long-distance cycling

18th January 2017 by rmj 36 Comments

Posted in: Bikes, TCR04, Technology

Just as Hoover came to define vacuum cleaners, Garmin has unfortunately become synonymous with GPS navigator for bikes. To the irritating extent that one of my riding groups recently announced Garmins are mandatory on this ride. As Andy Matthews said in an excellent blog post Garmin are a lazy company … They’ve largely captured the market for cycling computers and seemingly not through excellence but from being first to market and being good enough. Caroline and I have collectively owned five Garmin devices and experienced the highs and lows: liberation from the stress and delays of navigating with paper maps, but numerous irritations such as random reboots, confusingly different and proprietary file formats, unreliable navigation, limited configurability.

Entering the 2016 Transcontinental Race (a single-stage continuous bike race from Flanders to Gallipoli where the clock never stops) prompted me to re-evaluate. In theory a smartphone with OpenStreetMap and a decent mapping application should be capable of overcoming many of these limitations and providing a much better navigation experience. But, as Yogi Berra said, the difference between theory and practice is that in theory there’s no difference but in practice there is.

I identified my requirements:

Ability to follow a pre-planned route. For TCR, Audax, tours and indeed most of my training rides, I plan in advance and create GPX files with tools such as bikehike and brouter. The main use case is simply to keep me following the planned route.
Ability to navigate on demand to off-route locations. In TCR I expected I would need to find hotels, food stops, bike shops which might be somewhat off-route. I want to be able to rely on the mapping app to choose a fast, bike-suitable route for these relatively short deviations from my planned route.
A database of relevant points of interest. Bike shops, supermarkets, fuel stations, restaurants; bonus points for hours of operation (I relied on 24-hour fuel stations for food and drink).
Clear, simple map display, easy to control on the move (e.g. change zoom and map orientation)
Easy access to good quality maps for all of Europe.
Able to record a ride and easily upload to Strava over the air.
Physically robust and able to survive heavy rain – Garmin’s trump card; ours have survived several high-speed falls from the bike, and when the rain comes down, we’ll be far more anxious about covering ourselves with waterproofs than covering the Garmins.
Ability to ride 15 hours a day without battery worries.

I chose to use the Android app OsmAnd+ on a Motorola Moto G (3rd gen) phone, but carried a Garmin Edge 605 as backup. The good news is that OsmAnd led me through several long Audaxes including the 600km Brimstone in May, a 1,700km tour along the Rhine in June, successful completion of the Transcontinental in August (3,800km in 16 days). OsmAnd has its own quirks, and can be a little daunting at first, but it was the single most valuable piece of kit I carried on that long ride from Geraardsbergen to Çanakkale. OsmAnd never failed and the Garmin remained turned off in my bag.

This piece explains my thought process in selecting OsmAnd and Moto G3, details how I used it, and highlights some of the quirks and areas for improvement. I’ve shared an album of screen shots that show, in some detail, the step-by-step process of installing, configuring and using OsmAnd. I’ve included a few key screen shots directly in this post.

I should perhaps say: I am a techie, I’m not daunted by more complex technology, and perhaps my preference for OsmAnd reflects this. Nonetheless I want to try and make this description as clear and complete as I can, because I feel OsmAnd really rewards the effort to install and learn to use it.

The device

Moto G3 I have no knowledge of, or interest in iPhones, so for me it’s an Android. Water-resistant Android phones are becoming far more common. There are self-consciously ruggedised models, including some pretty cheap Chinese brands. There are high-end models such as Sony Experia Z3, which make a song and dance about their water-resistance and have received good feedback from other TCR finishers including Simon Romaine. I chose a Moto G 3rd Generation because I could justify £150 to update my phone even with the risk it wouldn’t meet the more stringent requirements as a navigation device. It’s allegedly IPX7 rated, meaning it can be dunked in up to one metre of water for up to 30 minutes (with videos to demonstrate). In a lab perhaps, but I was far from confident in real-life conditions. But so far, so good. [Update: the new, 4th gen Moto G no longer has the IPX7 water-resistance rating. My guess is the design hasn’t changed but Motorola is taking a more cautious stance, perhaps due to warranty claims. But you may want to consider alternatives which advertise water-resistance. A helpful commenter here, Jacek, recommends a very different approach, an Android watch.]

If you are planning on riding across Europe, you’ll need plenty of storage space for maps, stored tracks and photos, so I’d suggest getting a phone that will allow you to plug in an SD card. My Moto G3 came with 16GB internal storage, which I use mainly for installed apps, and I plugged in a 32GB SD card. Maybe overkill, but it only cost £10 so why worry.

The mapping software

I was already happily using OpenStreetMap maps on the Garmin so I had no hesitation in choosing them for TCR. For those who don’t know, OSM is the Wikipedia of mapping; it’s compiled through the contributions of volunteers. Mapping coverage was faultless, even throughout the Balkan phase of TCR (I crossed Croatia, Bosnia, Montenegro, Kosovo, Macedonia). Oddly enough, the only place I’ve found a few gaps in OSM mapping was in deepest mid-Wales, when I followed-up TCR with Mike Hall’s Valleycat in September. Of course OSM encourages you to correct any errors and we’ve fixed one or two.

OsmAnd stores maps offline so you have no dependence on mobile/Wifi network coverage when you’re on the road. It’s super-easy to download new countries or regions, just click on each of them while you are on-network and wait… they are quite large files: For TCR, I carried 3.3GB of maps for 16 countries (including some contingency countries off my planned route; be prepared!). Smaller countries tend to be packaged as a single map file, larger ones have a file per region, so I ended up with 43 map files. The free version of OsmAnd is limited to 10 downloads (maps, voice files, etc.). So if you only want UK maps you might be able to get by with the free version of OsmAnd, but the paid version (designated OsmAnd+ in the Play store) only costs £5.99 so I’d suggest paying up.

I know some TCR riders have had success with downloading offline Google maps. It seems to me a little more awkward than with OsmAnd, but perhaps I’m just not so familiar. The Google mapping is inferior to OSM for cycling, especially regarding details of road surface and status. And when you need a dry place to spend the night in rural France, it’s truly wonderful to locate and navigate to a bus stop using OSM!

By the way OsmAnd is also available for IPhone but I don’t have any personal experience.

Battery life

Two factors dominate battery usage: network usage and illuminating the screen.

I discovered that switching the phone to aeroplane mode led to a vast improvement in battery life. Connecting to the mobile network seems to be very power-consuming, especially in areas of poor coverage, where the phone is often seeking a signal.

As for the screen, I turn off adaptive brightness, and lower the brightness level, normally to one notch above the lowest setting. The map remains perfectly visible on dull days in the UK. In the TCR, in the middle of bright sunny days, I found I needed to turn the brightness up. Adaptive brightness would seem useful to avoid this faff, but I find that it turns the brightness higher than really necessary, even if the manual slider is at its minimum setting. (In an earlier Android version, adaptive brightness also seemed to have a bug whereby the brightness would occasionally be turned down so low as to be invisible; hard then to find the controls to turn it up again! I think that’s now fixed though.)

Together, aeroplane mode and low brightness give me something between six and nine hours turn-by-turn navigation on my Moto G3 with the screen permanently turned on. For best battery life you should also close any unnecessary apps, but I think aeroplane mode and brightness are the two biggies.

For a long time I was convinced I needed the software to be able to turn off the screen when following a continuous road, but wake the screen and alert me when a turn is coming up. OsmAnd can do this, and it would no doubt extend battery life, but here’s the snag. What is straight on? I found I would sometimes miss a turn when the main road curved right, and my fork went straight on. Conversely, spurious bends in the main road are often announced as turns. Too many times I missed an unannounced turn. So I gave up on turning the screen off, except manually when I absolutely knew the road ahead was long and continuous.

Remember my requirement was 15 hours a day without battery worries? We’re some way short of that, with six to nine hours of low brightness-aeroplane mode. I always carry a small USB battery pack, a Zendure A2, which gives me a couple of full phone charges at a cost of 200g extra weight. I also used a Shutter Precision dynamo hooked up to B&M Luxos U light and USB charger. So I can keep either the phone or battery topped up while riding.

A couple of snags to be aware of though:

In theory the Zendure supports charge-through and I’m pretty sure it did when I first started testing. However I had a near-disaster on Day 1 of TCR, when I found every time I tried to charge-through from the Luxos via Zendure to the phone, the front lamp would come on. Eventually I realised it was fine to charge either phone, or battery pack, but not charge-through both. So no disaster but a slight annoyance. I think the Luxos is probably at fault.
Charging from dynamo works great on normal days, but alpine climbing days with more than 5,000 meters of ascent are not normal! Because of the long hours at speeds less than 10 km/hour, I wasn’t getting much juice out of the dynamo. I still managed to get through two days riding without need for an additional charge (my pattern was alternate nights in hotels and roadside bivvying). But I was eating into the reserves of my battery pack on those days.

Attaching phone to bike

NC-17 Stem Bag I’ve been using an NC-17 Connect Smartphone Stem Bag for the best part of a year. It’s got a lot of good points and one really bad point. The phone slides into a slim pocket underneath the transparent window. The touch screen works pretty well despite the extra layer of plastic. With practice you can still use the screen on-off switch and volume rocker on the right side of the phone. The larger zippered space under the phone has plenty of room for a battery pack, and it has an opening underneath the bag through which I feed the USB output of the Luxos U, so all the vulnerable electrical interconnects are protected within the bag. My Moto G3 is a tight fit within the bag, especially with a micro-USB charging cable plugged in at the bottom. I had to choose a cable with a short ‘collar’ and even then it has become quite deformed from the pressure of the zipped-up bag. I worried that this would cause a broken connection, but so far no problem.

The major flaw though is that it’s not at all waterproof. It’s billed as water repellent but the seams leak water like a sieve. And, though the ingress of water caused no apparent damage to the phone (it’s IPX7, remember?), once the bag is saturated, the clear plastic cover gets covered in mist and water droplets and it’s nigh-on impossible to see the screen. The solution, which, though crude, I’m rather proud of, is to carry a hotel shower cap and slap it over the phone at the first drop of rain.

[Update: I now have an Aquapac bike-mounted case. The small size is a tight but satisfactory fit for Moto G 3rd Gen. Reviews consider this decent, but overpriced at full retail price. I got mine for a knock-down price at SportPursuit, so I’m not complaining. I haven’t yet put this to a full test; I will update when I’ve used it on the road for a while.]

If you really trust the waterproofness of the phone, you could use a free-range alternative such as Quad Lock or Finn. These seem a neater solution than my rather ugly stem bag, but on the other hand I’d fear for the vulnerability of charging connections on a wet day.

Installing OsmAnd

The version I’m describing is OsmAnd 2.5.4. It’s a straightforward install from the Play store. You’ll want to do the following from a WiFi network, as it involves downloading a lot of application and map files. I’m going to assume you will install OsmAnd (the free version) first, and you can then later install OsmAnd+ if you want a greater number of maps or the additional features of the paid version. [Update: I discovered while writing this that OsmAnd+ installs as a separate app alongside the free OsmAnd, so if you later pay for OsmAnd+ you would need to repeat the configuration and map download.]

Search for OsmAnd on the Play store, and hit install. When the install completes and you tap the new OsmAnd icon on your home screen, you will be invited to Get Started, and then OsmAnd will detect your location and suggest a first map. Before you download the map, if you have an SD card, I suggest you tap the button at the bottom of the screen to change data storage location. You need to Allow OsmAnd to access photos, media, etc. Choose Memory card as the data storage folder.

You can now tap Download to get your first map. You’ll see your local map, and the World overview map gradually downloading.

When the download has completed you can go to map. You might need to Allow OsmAnd to access this device’s location. You can tap the + icon to zoom in and you should see a detailed map of your local area.

Now is a good time to download voice files if you want to hear turn-by-turn announcements. At the bottom-left you will see an icon with three horizontal bars. Let’s call this the Menu button. If it’s not visible, just tap anywhere on the map and it should appear. Tap Menu then select Download maps (oddly, voice files are downloaded from the same menu as maps). Scroll to the very bottom, where you will see Voice prompts. Text-to-speech (TTS)-synthesised voices are recommended by OsmAnd. There are many TTS language options, including English and English (UK). Sadly the English (UK) option actually has a US accent. Tap the down-arrow on the right to download your chosen TTS language. Alternatively you can choose Voice prompts (recorded), and under this there is a UK English voice, which has a nicer accent, but is a bit staccato. By all means install several voice files and see which you prefer. Back-arrow to the map screen when you’ve downloaded your voice files.

You now probably want to set up defaults for bicycle use. Tap Menu then Settings. On the next screen, tap General settings and then Default profile and finally select Bicycle. Still on the Global app settings screen, scroll down and tap Voice guidance then select your preferred voice file that you recently downloaded.

If you wish you can set personal preferences here, such as language and units of measure. Back-arrow until you get back to the map.

Tap Menu once more, then Configure map. Mid-way down the Configure map screen are icons for car, bicycle and walking. If it’s not already highlighted, tap the bike. Scroll down to Map rendering. Your tastes may differ, but I usually switch Map mode to Day; Text size to 75%; Map language to English. Back-arrow to the map screen.

You are now ready to navigate your first route.

Navigating a pre-planned route

I’ll spare you (for now) the details of how I prepared my routes. That will make a whole other blog post. In short though: good routing software that can offer multiple route options and evaluate distance and climbing; meticulous attention to details especially road surface, Google street view and and satellite images. On the whole I was really pleased with my route choices. This section is about how to follow them.

The first aspect is file format. Garmin uses some proprietary file formats such as TCX. Standard GPX flavours include Routes, Waypoints and Tracks that differ in the type of GPX coordinates they use, and how closely-spaced they are (some GPX routes have the points far apart and expect the navigation device or human to fill in the gaps). I experimented with all of these and I find GPX Tracks absolutely the best. This type of file contains GPX track points spaced just a few metres apart, so there are essentially no navigation decisions left for OsmAnd. The tools I typically use to make GPX tracks are brouter and bikehike, but I’m sure many other tools are capable.

Now you need to get the GPX file onto the phone. I’m going to assume you know how to get files onto the phone. Either by plugging the phone into your computer via USB cable. Or, what I do, connect over WiFi to our home network file server and use an app such as ES File Explorer to copy the GPX file from the server to phone. I guess Dropbox would be another way.

Whatever the method, the key thing is to put the GPX file into the folder from which OsmAnd loads tracks. If you have set up OsmAnd to use an SD card for storage, the folder will be:

SD card/Android/data/net.osmand.plus/files/tracks

Now, from the OsmAnd home screen, tap Menu (bottom left of screen), then Configure map, then GPX track, then tap on the name of the GPX file. A tick should appear on the right of the file name. Then OK at the bottom, and back-arrow to go back the home map screen. Your GPX track should now be visible on the map, perhaps as a red line if you haven’t changed the defaults.

When it comes to riding, you might be happy just to follow the red line. The map should pan as it tracks your current position (if it doesn’t, tap the blue compass icon at the bottom towards the right).

But if you prefer turn-by-turn directions, with voice prompts, you need to tap the curved arrow icon at the bottom towards the left). A menu will pop up asking whether you want to use the displayed track for navigation. Tap yes, and you’ll see a mini-map with your planned route highlighted in purple. The first time you do this, you’ll want to set some default options for cycling. Make sure the bike icon is highlighted above the From: and To: addresses. Tap the cog icon at the bottom of the screen. Set options as follows:

Voice guidance: Select the voice you downloaded in the previous section.
Pass along entire track: Make sure this is NOT ticked, however tempting!
Calculate OsmAnd route for first and last route segment: Ticked.

And then tap Navigation settings, check that the following screen references Bicycle at the top, and then select Navigation options as follows:

Avoid: I suggest you tick Avoid motorways and Avoid stairs, but suit yourself!
Snap to road: I have always had this ticked (which is the default) but as I write, it occurs to me that unticked might be better, especially if you are taking off-road routes.
Announce: I generally untick all except GPX waypoints.
Unit of speed: Your choice.
Turn screen on: This allows OsmAnd to turn on the screen when you are approaching a turn, and specifies how long to leave it turned on. It’s worth selecting a time here, e.g. 30 seconds, even if you generally intend to keep the screen turned on permanently as discussed under Battery Life. You will then be asked to Activate device administrator for lock screen; tap Activate at the bottom of the screen.

Back-arrow to the navigation screen and tap Go next to the blue arrow.

You are now in turn-by-turn mode. The fat purple line shows your route, with yellow arrows indicating turns. An icon on the left-middle of the screen controls the orientation of the map. It has three options: North up, To direction of movement, or To compass. The menu and navigation icons at bottom left will disappear after a short while, to give you a clearer view of the map, but you can make them re-appear by tapping anywhere on the map.

One thing you might want to configure is the display at the top-right of the routing screen. By default you get distance to destination, OsmAnd’s estimated arrival time, speed and altitude. To select different display data, tap Menu and then Configure screen. You can turn off the default data items, and add preferred items to your heart’s content. There are similar options for the navigation display in the left panel, which by default shows distance to and direction of the next turn (and below that the second next turn).

If you want to stop navigation, tap on the map to make the icons at bottom left reappear, tap the blue arrow, and then X in the bottom left to dismiss the route.

One important note. If you are resuming a GPX track part-way through, you will want to set the From: location to ‘My Position’ rather than the beginning of the track.

Ad-hoc Routing

So far, so good. We’ve installed OsmAnd and used it to follow a pre-planned route. But now we want to divert and find food, or a hotel, or a bus stop. There are three main ways I do this: search by category, free-text search, or directly selecting a point on the map.

Search by category: Tap Menu, then Search, then Categories, and you will see a list of categories e.g. Cafe and restaurant. Tap a category and you will see a list of items of this category, in this case restaurants, ordered closest first. I found this absolutely brilliant on TCR, when I would frequently need to know where is the closest food store, or restaurant, or filling station, or hotel. You will even find opening hours for some items, if the good people of OSM have captured this information. Now tap one of the items and you’ll be taken back to the map, with a push-pin marker showing the location of that item. If you want to go there, tap the blue arrow or blue flag (depends whether you are currently in turn-by-turn routing), and OsmAnd will choose a route and present it to you. Just tap Go and you’ll get turn-by-turn directions.
Free-text search: Tap Menu, then Search. At the top of the Search screen is a free-text entry box. You can type pizza or parking or Brighton or Acacia Avenue or doctors… whatever you want. OsmAnd will do a text search across all items and display them below in order of distance from your current location. Tap an item in the search results and it might take you into a more detailed list of search items, e.g. tapping Brighton will show a list of Brighton street names. Alternatively, if you tap a specific item such as Pizza Express, Bridge Street, Winchester, it will take you to the map with the usual push-pin marker and blue arrow/flag.
Directly select a point on the map: If you know where you want to go, and you can find it on the map, just long-press on the map, and the usual push-pin will appear, with an invitation to route to that point.

OsmAnd’s route selection seems pretty good. I wouldn’t trust it to plan an all-day route; I’d definitely want to review that on a large screen map ahead of time. But for short, spontaneous diversions it seems to pick sensible cycling routes (obviously assuming you’ve set suitable options such as Avoid Motorways).

Recording rides

Many of us want to record our rides, e.g. to upload to Strava. OsmAnd has a free plugin to record a GPX file of your ride. I would imagine it’s a pretty battery-efficient way to do it, given you’re already using OsmAnd for navigation. But I don’t use it as a rule, instead I use the Strava app for Android. The reason is simply that the Strava app makes it so easy to upload its track at the end of a ride, whereas uploading a GPX file captured by a different device is a bit fiddly (you have to use a web browser to visit strava.com and repeatedly say ‘no, I don’t want to use the Strava app’).

The Strava app is pretty battery-efficient (I understand it uses around 2% of battery per hour) so it’s no big deal, but perhaps one day I’ll experiment with using OsmAnd to capture ride logs. If you want to do this: Menu, Plugins, Trip recording, three-dots, Enable. You’ll then see an additional item ‘GPX’ on the top right of the map. Tap this and the circle next to GPX will light up in red and you are capturing a track.

Other cool features

There is a plugin for Contour lines. I’ve never tried it. I think you need the plugin enabled, and also you need to download the contour data for the relevant country, so it will count as an additional one of your ten downloads if you are sticking with the free version of the app.

Points of Interest (POIs): You can choose to display markers for categories of interest. For instance, on TCR when I had a non-urgent need for an ATM, I wouldn’t necessarily search for a specific one and then route to it, but instead turn on POI display for category:Finance, and then keep an eye on the map in case I passed near a bank. To enable display of POIs: Menu, Configure map, POI, select category. If you want to display more than one category of POI at the same time, you need to tap the double-tick icon at bottom-left whereupon tick boxes will appear alongside the categories.

From the Download maps menu option, you can also download Wikipedia data for each country (this feature is available only in OsmAnd+). You then have the option to display these as POIs on the map, and tap for additional text. I guess this could be very useful if you are touring and want to access interesting facts about landmarks you see along the way.

Favourites: You can create your own list of favourite locations, and then use them as routing destinations. Any time you see a push-pin marker on the screen, e.g. after a search, or after directly-selecting a point on the map, there should be a five-pointed star at bottom left. Tap that and you will be invited to add this point as a favourite. I added all the TCR checkpoints and parcours as favourites. If you have coordinates of multiple favourites like TCR checkpoints, a quicker way is to create a GPX file of these points and open the file in OsmAnd. This document describes a way to do this.

Map updates: There is a very active community constantly making improvements so it’s well worth updating your downloaded maps from time to time (Menu, Download maps, Update).

Alternative offline routers: OsmAnd has an architecture to allow alternative routing engines to be plugged-in. You set up your preferred routing engine via Menu, Settings, Navigation settings, Navigation service. OSMAND is the only out-of-the-box offline router that supports bikes, so it’s the obvious choice and does a good job. But my favourite web routing engine, brouter, also offers an offline engine for installation in OsmAnd. I briefly tried this and couldn’t immediately make it work, but it’s worth knowing that alternatives do exist.

Quirks and annoyances

I already mentioned the issue of occasional turns that are not announced (because the fork goes straight ahead) and more often, random bends on the road being announced as turns. As far as I can see, OSM doesn’t seem to have a way to model the dashed white lines at a junction that indicate right-of-way, so it simply relies on the shape of the road to guess. It’s a pretty common issue for all navigation systems.

A related problem is that the voice announcements try to describe the approach, entry and exit from a roundabout using only the words left and right. There’s no enter roundabout and leave by the third exit. Of course it’s perfectly clear when you look on the map, but the voice announcements alone can be misleading.

When you are navigating a GPX track turn-by-turn, but you go off-route, OsmAnd tends to be quite persistent in telling you to go back and complete the whole planned route. Of course, by looking at the map you have probably found a way to divert then re-converge with the route a little further down the road. OsmAnd may panic but you shouldn’t! Just keep navigating to the convergence point and OsmAnd will eventually calm down and recognise that you are back on track.

As I already mentioned, when you install OsmAnd+ (to lift restrictions on number of downloads) after starting out with free OsmAnd, you will need to repeat the initial configuration, and download maps once again. In this case you will most likely want to uninstall free OsmAnd and delete its associated folders, to save storage space on your phone.

I haven’t found a way to show a profile of elevation along the route. When I used Garmin, I used to torture myself by looking at the elevation profile and watching my slow progress towards the top of a hill. Unless I’ve overlooked it, it seems OsmAnd doesn’t allow that masochistic experience.

Summary and recommendation

I heartily recommend OsmAnd+ for navigating long-distance cycling events. Compared to the Garmin devices I have owned, I find it has a larger and clearer display, fewer software problems, and it has powerful and easy-to-use features for ad-hoc routing on the move. I ran OsmAnd+ on an inexpensive phone, which I would in any case have taken on TCR for communication, thus potentially saving one device. That said, I would still recommend TCR competitors have a backup navigation device of some form.

I’d really like a fully waterproof bag to protect phone, battery pack and USB charging connections, so I could retire my hotel shower caps! This remains my biggest concern.

I’m very interested to hear your thoughts on this subject. Have you tried OsmAnd? Was it successful for you? Have you solved the bike-mounting issue? Is there anything I haven’t described clearly? Please use comments to provide feedback.

Shoestring entrepreneur: I want to be a horse, not a unicorn

28th February 2015 by rmj Leave a Comment

Posted in: Technology, unenterprising

Remember my qualms about The Lean Startup; the assumption that the startup must aspire to rapid and massive growth. Here’s an interesting article that offers a slightly different view.

The siren call for many entrepreneurs isn’t money, it’s freedom. The freedom to chart your own path, the freedom to build what you want with the people you love. Taking money, building a board, and raising rounds takes away that freedom little by little. When you take venture money, you work for your investors, not yourself. You’re committing to grow fast to dominate your market and get your investors their cash back in the form of an exit or going public as soon as possible.

I was also interested to read about this alternative funding model from indie.vc

Despite sharply decreasing costs to start and scale technology based businesses, VCs continue to fund companies the same way they did 40 years ago.

And that way isn’t for everyone.

That way comes with a lot of expectations about the kind of company a founder wants to build. The kind of team a founder wants to recruit. The kind of exit a founder wants to see. And the kind of timelines a VC needs to see this all happen within.

There’s a mythology that entrepreneurs need to take VC money to hit the big time. While it’s true that some companies really do need outside capital, there are many examples of great companies that have reached revenues of hundreds of millions of dollars, or even gone public, without ever taking in capital, or taking it in only at a late stage, when they’d already created a high valuation by bootstrapping the company.

Perhaps there is a little moderation and common sense breaking out among tech startups?

[Unicorn image Creative Commons Share Alike Some rights reserved by Anley Piers]

Thoughts on The Lean Startup (Eric Ries)

18th January 2015 by rmj 1 Comment

Posted in: Technology, unenterprising

I just finished reading the Eric Ries book, The Lean Startup: How Constant Innovation Creates Radically Successful Businesses. I recall skimming this in Waterstones a few years back; I was surprised to find it was published as recently as 2011. Since then, it’s become a classic and many of its concepts, especially the Minimum Viable Product, have become ubiquitous in business life.

What’s this book all about?

Enterprises focus on developing new products efficiently, but what use is it to efficiently developing a product no-one needs? Today’s challenge is to build the right thing. Given the uncertainty, the unknowability, of the market, the only way to build the right thing is to test your ideas in the marketplace as early as possible. Push out a first offering and measure its uptake. Refine and repeat. Through a series of structured experiments, learn what customers value, and what will drive growth of your business.

Ries talks about a couple of leap-of-faith assumptions. These are the riskiest elements of a startup’s plan, therefore it’s a priority to test these hypotheses.

The first leap-of-faith assumption; the value hypothesis

A startup will only succeed if it offers something of value to its customers. This is equally true of for-profit businesses or not-for-profit social or governmental offerings. My current hobby project (definitely not planned as a for-profit startup) is a web site for travellers. The value hypothesis is: “Travellers will find it useful and fun to track all of the UNESCO World Heritage Sites they have visited or plan to visit, hence they will be motivated to sign up and to return to the site.”

Ries would recommend building a very basic form of the the offering, in this case a web site. This is the Minimum Viable Product (MVP). The MVP will be primitive, it might even be buggy. But it provides a vehicle to test the value hypothesis. Early adopters are willing to endure rough edges if there is value in the offering. The imperative to learn quickly must trump the desire for perfection at this stage of an embryonic startup. Even small numbers of visitors can deliver insight into to customer experience; Ries described the early days of his company IMVU, which paid Google Adwords $5 a day to bring 100 customers to the site. Each week, the company would chart the behaviour of recent visitors, in terms of sign-up, login, usage, and conversion to a premium paid offering. Each week, new features would be introduced, and the team would monitor impact on the key metrics. This gave clear visibility of features which customers valued and should be retained, as opposed to features of no value, which were discarded as a waste of effort.

The second leap-of-faith assumption; the engine of growth

How does a startup grow? In one of three ways, says Ries: sticky, viral or paid. The engine of growth dictates which growth metric the entrepreneur should study most closely.

Sticky growth occurs when customers, once recruited, tend to stay with the product for a long period. This might be because of barriers to entry (such as market-leading technology), network effects (a special-interest community) or high obstacles to change (enterprise software). If your business depends on sticky growth, the key growth metric is attrition or churn rate. Even if you are attracting new customers at a high rate, growth will be meagre if existing customers are defecting.

Viral growth occurs when existing customers attract new customers through recommendation or word-of-mouth. The key growth metric is the viral coefficient, which is the number of additional customers who will use the product as a result of each new customer recruited. Businesses that seek viral growth must focus on this more than any other factor, because small changes will have dramatic effects on growth rate. A coefficient of 0.9 will lead to stagnation or failure, whereas a coefficient of 1.1 will lead to spectacular growth. As a result, such companies often do not charge customers directly, lest this impede viral spread, but instead rely on indirect revenue such as advertising.

Paid growth occurs when a business has strong visibility of the value it will extract from a customer over the lifetime of their relationship, and can therefore invest in marketing to attract customers. It matters not whether the Cost Per Acquisition (CPA) is $8 to acquire Lifetime Value (LTV) of $10, or CPA of $8,000 to acquire LTV of $10,000; both have a marginal profit of 20%, which is available to reinvest in further growth.

A fundamental assumption of this book I’m not sure about

There is an assumption that the startup must aspire to rapid and massive growth. Ries talks about:

The land of the living dead … when a company has achieved a modicum of success – just enough to stay alive – but is not living up to the expectations of founders and investors. Such companies are a terrible drain of human energy.

Prior to reading this, I would have confidently espoused my ambition to become a shoestring entrepreneur, building a web application or two that would appeal to a loyal, niche audience with no intention whatsoever of attracting venture funding, still less becoming the next Facebook. A digital corner shop if you will. But in Ries’s world, every corner shop should be dreaming of becoming the next Walmart. Caroline says it’s just because he’s American. I’m feeling a bit confused about this now; do I lack ambition? Is a small scale project doomed?

Things I really liked in this book

The book has a really strong focus on developing actionable metrics; Ries also calls this innovation accounting. I love to see simple measurements that illuminate exactly how a process is working. Unfortunately it’s a rare thing, and even the best-intentioned seem to create scattershot collections of what can I measure? that only serve to confuse. Ries further points out the danger of vanity metrics, which are less innocent. A management team determined to demonstrate success to investors can easily show flattering measures such as overall growth in number of customers, while ignoring or suppressing figures that may indicate growth is slowing, or attrition increasing, or new product features have not been valued by customers. They only delude themselves, and are likely discarding the vital information that could turn around their plight.

Specifically, I learned some techniques that I wish I’d known sooner and may be able to use in future. I’d heard all about A/B testing, but there were good examples of companies who build this into a rapid innovation pipeline such that no feature is complete until the A/B test results are in, and the decision is made whether to persist with it, or back it out as a failed experiment. I learned about cohort analysis, which would have been immensely valuable when I was trying to provide a clear representation of the marketing pipeline at Brighter Business, a complex situation with customers arriving online, sometimes obtaining quotes online, but generally converting via the call centre.

In regard to validated learning, the key phrase is Pivot or Persevere. Armed with the metrics that should provide crystal clear insight into how your product is performing, the entrepreneur has to decide whether optimising the current strategy will eventually deliver success, or whether a more radical change is needed. Pivot means changing course, while keeping one foot on the ground, for instance changing to a different engine of growth strategy, narrowing or expanding the product scope, or seeking a different customer group. I think for Ries, the difference between success and failure for a startup is the speed of reaching these decision points and the clinical accuracy of making the pivot or persevere decision.

Towards the end of the book, Ries introduces a discussion of small batch thinking, which absolutely appealed to me, and brings things back to the starting point of this blog; the inevitable failure of traditional Enterprise Architecture. The scenario is a father and daughters stuffing newsletters in envelopes. Father asks the children: what is the quickest way to address, stamp and stuff 100 newsletters in 100 envelopes? The daughters confidently say: first fold 100 newsletters, then stuff 100 newsletters into 100 envelopes, then address 100 envelopes, then attach 100 stamps. Father challenges them, and takes the opposite approach, fully processing one newsletter at a time, known in manufacturing as single-piece flow. Counter-intuitively, Father wins the race, and not just because he is an adult.

The advantages of single-piece flow have been consistently demonstrated. Part of the advantage arises because of tasks we tend to forget: in this case stacking and tidying the growing pile of 100 folded newsletters. But more significantly, the large batch approach is prone to unexpected rework. What if the folded newsletter doesn’t fit the envelope as we expected? We may have to go back and repeat work.

Enterprise IT, and specifically traditional Enterprise Architecture, takes upon itself the challenge of working out in advance all of the steps required to reach the target state. Then it tends to demand large quantities of cash to execute the plan. Lo and behold, things don’t go according to plan. The project’s stakeholders develop antagonism towards the project, and demand more frequent reviews. Productivity takes a dive as everyone spends their time talking about the problem rather than contributing to the solution.

How much better it would be if we tackled our transformation in small batches, with carefully chosen metrics, and rapid, iterative persevere or pivot decisions.

Three Things a City In Charge of its Destiny Ought to Know About Software

11th January 2015 by rmj Leave a Comment

Posted in: Technology, unenterprising

http://radar.oreilly.com/2015/01/four-short-links-9-january-2015.html

Photo City of Light (c) Carl Milner.

This quote gets to the heart of some of the mistaken group-think in enterprise IT.

The so-called economies of scale claimed for big IT solutions turn out to be largely illusory. Their business cases begin with wrong-headed, goods-dominant accounting copied from the world of manufacturing, where buying stuff in bulk really can be cheaper. Wishful thinking by people remote from the frontline carries these projects forward unchallenged. But by the time complex shared services have been tailored to the needs of the people and teams who use them, they can actually increase costs substantially.

Proud

23rd November 2014 by rmj Leave a Comment

Posted in: Technology, unenterprising

Caroline pointed out that the last post was incoherent. I know what she means. Attempting to write spontaneously, it was blurt of mixed-up resentments laced with a few understated victories. Rather than return and straighten out that effort, I will unpick things and present a few short posts isolating some positive and negative thoughts.

What have I done these five years to make me feel proud? It’s been a team effort, but a few improvements to which I have leant my weight:

We adopted Red Hat Linux as default standard operating system. I arrived to a mix of Windows and IBM AIX. Nothing in particular wrong with Windows (it’s not my bag), but AIX was a liability. Application implementations were fraught with hard-to-find bugs. It became apparent that vendors such as Oracle and BMC placed AIX 4th or 5th in the pecking order for testing. Furthermore the IBM Power hardware was costly and headed for obsolescence. Linux allowed us to adopt commodity Intel-based hardware, and has been robust and well-supported by application vendors. Ubuntu or Centos might have been cheaper and braver choices, but would not have given the confidence of support by tier 1 application vendors.

We focused our application development effort on Java, specifically Pivotal’s Spring. The development team still has to support legacy Microsoft technologies, ASP and .NET, but they now have a focus on recruiting and developing the skill set for modern Java. Java developers are easier to find. The strategy has allowed them to progress into areas such as continuous delivery, and the rapid development framework Spring Boot. Again, there could have been cooler and braver choices (Ruby on Rails and its polyglot siblings) but, as much as I am tempted by the fast-moving, shiny toys, we are still an enterprise shop.

After a brief flirtation with MySQL, we have plumped for PostgreSQL as our non-Oracle database. Yes, we continue to use Oracle Enterprise Edition; we have no choice for many of the enterprise suites we (regrettably) are committed to. But we have placed a considerable bet on Postgres for some demanding bespoke applications.

And finally, in another bold move away from Oracle, we declined to pump a further £1m+ into Oracle SOA Suite and instead chose Red Hat JBoss Fuse. SOA Suite promised great things, but is the typical mega-vendor ‘kitchen sink’ middleware suite. I never had the sense that our developers understood it deeply. Furthermore, and the final straw, was that Oracle’s licensing prevented us from affordably deploying SOA Suite on our standard VMware infrastructure. We came close to creating an Oracle ‘ghetto’, a special purpose virtualised environment where Oracle software could be deployed without a many-fold increase in licence costs. But I couldn’t stomach it. JBoss Fuse is a packaging of Apache projects: ActiveMQ, Camel, CXF; with the commercial support the enterprise demands. It lacks the sophistication of the mega-vendor alternatives, but I view that as a positive. It allows us to treat integration as just another aspect of application development, with our Java team handling the complete task.

What’s the gripe about Enterprise IT?

13th November 2014 by rmj 1 Comment

Posted in: Technology, unenterprising

This Enterprise Architect gig has kept me gainfully employed these past five years. So why turn on it?

I’m sitting in the auditorium of Gartner ITXPO, listening to Clean Bandit’s ‘Rather Be’. Superficially edgy, but ultimately tame. Grey-suited businessmen surround me (and yes they are men).

We are waiting to be told to embrace Bi-modal IT. The notion that it’s OK to let some aspects of IT implementation race ahead, agile-fashion, unencumbered by concerns of creating a chaotic legacy, with the associated high cost of ownership.

It’s progress of a kind. But this is 2014. When I joined The Firm as an Enterprise Architect in 2010, I encountered a sterile and deeply conservative landscape.

The strategy was “Buy Oracle”. Yes, we had a mission to tackle legacy. But the approach was to buy expensive mega-vendor packages, in the belief they must be best of breed, or better yet pre-integrated. No one ever got fired for buying IBM, right? They didn’t get fired, they just ran the company into the ground.

My mistake was to be too meek. I went along with this madness. Despite my hugely positive experiences implementing open source packages quickly and inexpensively for The Insurance Startup, I colluded with the Oracle strategy. Up to a point anyway. I recall making a stand with the IT Director to prefix the strategy “Why not Oracle?” with the words “In ERP”. It was a Pyrrhic victory. I was outnumbered by a conservative IT management team and forced to buy hugely expensive Oracle portal software. The implementation was horrible, the developers took against the programming model, we were forced by Oracle’s protectionist licensing to run on non-standard infrastructure, browser support lagged the industry. We are left with a million pound boat anchor.

On another occasion I spoke up for Linux, and a manager said “yee haw, the cowboys are coming!”.

We’ve made up lot of ground since then. The portal debacle was a turning point of sorts. Gradually it dawned that we were in hock to Oracle. Utterly objectionable licensing made it impossible to escape annual support charges, even for software we had never used, or found impossible to implement successfully.

I accept some responsibility for this. My role allows and expects me to lead the way. A braver soul would have decried the madness (but probably lost their head in the process, amid mutterings of “didn’t fit the culture”). A smarter corporate diplomat would have quietly challenged behind closed doors, and maybe won support bit-by-bit. My challenges were mild and inoffensive, we eventually changed course, Linux is is our default server platform, Oracle is regarded as public enemy number one, the CTO states in management meetings “we should use more open source software”.

The point is that this deep conservatism in Enterprise IT is anathema to me. It stems from management’s poor grasp of what the technology actually does, ruthlessly exploited by Enterprise vendors, who offer reassuring slogans but no real remedy. It has to cope with a community of lacklustre IT workers, who need hand holding. It clings to Enterprise Support as a fig leaf, of dubious real practical value when trouble strikes, but essential as a blame deflection mechanism.

I’ve clung on for nearly five years; the reasons, as I often joke, are “loyalty and stupidity”. In a candid chat with my boss this evening, he quoted a colleague who said “this company will suck the life out of you”. I crave an environment where effort-applied translates into progress-achieved, rather than being dulled by layers of management waffle and bluster. So I’m planning my exit… more later.

Plans and promises

16th November 2013 by rmj Leave a Comment

Posted in: Technology, unenterprising

I’ve no idea how long this will take; I’ve been a competent, dare I say, expert, developer in the past. Developing networking protocol stacks mainly, in C and C++. And then, in a diverse career, I’ve been a makeshift Unix/Linux systems administrator and infrastructure designer. But the chops are rusty. Besides some small-time dabbling in Python and JavaScript, it’s been 15 years since I programmed in earnest.

The plan is to acquire the basics of web application development. Spring seems to be a decent starting point; a balance of mainstream with ‘cool’. That opens the door to Groovy and Grails, which I’m drawn to without much knowledge.

At the same time I am keen to get to grips with Data Science. I have a smattering of relevant experience: A level statistics, machine learning and classification algorithms.

But I’m well aware of the danger of spreading myself too thinly. So let’s draw the line here.

[Image by @giuliaforsythe]