Building Stuff for Fun and Profit - confessions from a life in code and cables

What is the Bluemix Garage? (It’s not actually a Garage.) @holly_cummins I’m the technical lead in IBM’s London Bluemix Garage. The Garages are located in startup communities, rather than IBM oﬃces. Our mission is to do exciting customer projects using the Bluemix platform and the Bluemix Garage Method.

@holly_cummins The Garage is all about innovation; we use a combination of design thinking, xp, and lean startup to help clients innovate quickly.

http://ibm.biz/bluemixgaragelondon @holly_cummins If you’d like to know more about Bluemix, the link will take you to a signup page for a free trial.

1979 Cuddly toy hotel Cuddly toy zipwire @holly_cummins Like all of us, I suspect, I’ve loved building things for as long as I can remember. I decided my stuffed animals didn’t have enough excitement in their life, so I used to make them little amusement parts and houses from cardboard boxes.

1987 When I got a bit more skilled, I moved on to modelling clay. @holly_cummins

@holly_cummins Anyone want to take a guess about the date, from looking at the computer?

1998 @holly_cummins This was my final-year project in university. It’s a double pendulum. I machined the pendulum out of aluminium, and instrumented it so that its position and speed could be measured. The breadboard in the computer is the electronics for recording the readings.

@holly_cummins The double pendulum is an interesting system because even though it’s so simple physically, and can be described by easy equations, it’s completely - and fundamentally - unpredictable. This is known as sensitive dependence on initial conditions, or chaos theory.

No matter how much math you throw at it, you can’t actually predict what it’s going to do. @holly_cummins The double pendulum is an interesting system because even though it’s so simple physically, and can be described by easy equations, it’s completely - and fundamentally - unpredictable. This is known as sensitive dependence on initial conditions, or chaos theory.

@holly_cummins Why was this such a satisfying project? I did the electronics, I was there in the machine room, I was the one running the system and getting value from the output. Nowadays, some people would call that kind of end to end ownership devops.

Idea. @holly_cummins Why was this such a satisfying project? I did the electronics, I was there in the machine room, I was the one running the system and getting value from the output. Nowadays, some people would call that kind of end to end ownership devops.

Idea. Built it. @holly_cummins Why was this such a satisfying project? I did the electronics, I was there in the machine room, I was the one running the system and getting value from the output. Nowadays, some people would call that kind of end to end ownership devops.

Idea. Built it. Used it. @holly_cummins Why was this such a satisfying project? I did the electronics, I was there in the machine room, I was the one running the system and getting value from the output. Nowadays, some people would call that kind of end to end ownership devops.

Idea. Built it. Used it. #devops @holly_cummins Why was this such a satisfying project? I did the electronics, I was there in the machine room, I was the one running the system and getting value from the output. Nowadays, some people would call that kind of end to end ownership devops.

2001 @holly_cummins In 2001, I got my first real job, with IBM.

2002 @holly_cummins In 2002, I started working on a large project. Before we did any development, we’d write up a design. It’s hard to imagine now, but in 2002 100 page design documents made sense. It’s worse than that; each component in the project (one or two developers) had a design document, so the total design output was around 500 pages.

100 page design document. 2002 @holly_cummins In 2002, I started working on a large project. Before we did any development, we’d write up a design. It’s hard to imagine now, but in 2002 100 page design documents made sense. It’s worse than that; each component in the project (one or two developers) had a design document, so the total design output was around 500 pages.

100 page design document. Seriously. 2002 @holly_cummins In 2002, I started working on a large project. Before we did any development, we’d write up a design. It’s hard to imagine now, but in 2002 100 page design documents made sense. It’s worse than that; each component in the project (one or two developers) had a design document, so the total design output was around 500 pages.

@holly_cummins The reason the documents were so big is that we wrote down every every method of every interface. And then we’d implement it. And of course the implementation would be different, because we’d learn things in the course of doing the implementation.

@holly_cummins This was a problem, because know one knew whether to look at the code or the design document to understand how things worked. The clever solution was to do some automated round-tripping between the code and the document to keep the two in sync.

@holly_cummins IBM had a really nice product for this, called Rational Soda, which would update Word documents live from the implementation, and also generate the initial implementation from the document. (I have no idea what this says, hopefully it’s not something awful.) Have a look how primitive 2002 interface design looks now.

But … @holly_cummins I had a small problem, though. I used Linux, and Linux on Word was definitely not a thing. My two choices were to reinstall my system to be a Windows one (pretty terrible), or two continue manually synchronising the 100 page document every time I changed my code (pretty terrible).

@holly_cummins I decided on a third optionand, I started spending all my time writing my processing tool. After all, I knew LATeX well, and LATeX, is great at producing beautiful documents. All I needed to was use reflection to turn my Java code into a LATeX script. And then some more code to make diagrams, and some more code to get the layout of the diagrams right. This left me no time for the code I was actually supposed to be writing.

@holly_cummins Soo, did I make my fortune? Well, no. At the time, the number of linux users was smaller. The proportion of those who knew LaTeX is even smaller, and the proportion of them who had an interest in generating enormous design documents was even smaller. Really, I was solving the wrong problem - agile has taught us that the aim should not have been to write 100 page design documents more eﬃciently.

@holly_cummins I’d reinvented a wheel. And it was the WRONG wheel, and it was a wheel with almost no audience.

@holly_cummins

Don’t reinvent wheels. Unless there’s a good reason. @holly_cummins

2011 @holly_cummins Skip forward a few years, to 2011.

@holly_cummins IBM had produced a new variant of its application server, WebSphere. Although WebSphere was extremely powerful, and suitable for ops, it wasn’t great as a development environment. Some very clever people wrote a new modular, dynamic, kernel, but kept the main WebSphere libraries, so that user applications behaved the same way. WebSphere Liberty was amazing; it had a 50mb download, 100mb memory footprint, and it was so light it could even run on a raspberry pi.

@holly_cummins My colleague Simon Maple had done the pi project, so I felt I couldn’t just redo that. I decided to go into wearables. A raspberry pi is small, but not so small that it can fit into a pocket. I settled on a hat, instead.

The WebSphere Hat @holly_cummins My colleague Simon Maple had done the pi project, so I felt I couldn’t just redo that. I decided to go into wearables. A raspberry pi is small, but not so small that it can fit into a pocket. I settled on a hat, instead.

The WebSphere Hat (“the world’s first wearable application server”) @holly_cummins My colleague Simon Maple had done the pi project, so I felt I couldn’t just redo that. I decided to go into wearables. A raspberry pi is small, but not so small that it can fit into a pocket. I settled on a hat, instead.

There’s a WebSphere server running in that hat @holly_cummins Here’s me looking very dignified in the hat.

@holly_cummins I didn’t get the hat fully portable in the first version; that’s an ethernet cable coming down from my head :)

2014 @holly_cummins It turns out that having a computer in a very floppy hat and then regularly up-ending it onto my one’s head isn’t great for robustness. The USB power connector would often work loose. A millisecond’s power interruption would mean a two minute reboot, which was awkward in a live-demo. I decided I need something more reliable, so I decided to make a custom case. I wanted it to be interactive, so I decided to make a case that could be thrown around. (I should have realised that this didn’t sound very compatible with reliability.)

2014 Presenting: The WebSphere Sphere (“the cuddly throwable application server”) @holly_cummins It turns out that having a computer in a very floppy hat and then regularly up-ending it onto my one’s head isn’t great for robustness. The USB power connector would often work loose. A millisecond’s power interruption would mean a two minute reboot, which was awkward in a live-demo. I decided I need something more reliable, so I decided to make a custom case. I wanted it to be interactive, so I decided to make a case that could be thrown around. (I should have realised that this didn’t sound very compatible with reliability.)

Sensors Liberty embedded application server @holly_cummins The system architecture was that I had WebSphere Liberty running on a pcDuino (a single board computer, but with lots of power and on-board flash drive).

Sensors @holly_cummins That’s not a very realistic IoT architecture, so I also included an EJB timer which would regularly post an MQTT message with sensor readings to an MQTT broker living in the Bluemix cloud. Bluemix also hosted a web application, so that it wasn’t necessary to connect directly to the sphere.

@holly_cummins

photo courtesy of re:develop conference, Bournemouth @holly_cummins

“Holly, why would a ny o n e w a n t a n application server in a cuddly ball?” –My Mother @holly_cummins I told my mom all about my hard work, but she was a bit perplexed about why it was valuable.

Who wouldn’t want an application server in a cuddly ball? @holly_cummins

… and then what happened? @holly_cummins I was mistaken when I hoped the sphere would be more reliable than the hat. I spent ages trying to debug why none of the five displays I tried ever showed any output. Running headless is ok, but sometimes a monitor saves networking hassle.

… and then what happened? pcDuino could never display on any monitor. @holly_cummins I was mistaken when I hoped the sphere would be more reliable than the hat. I spent ages trying to debug why none of the five displays I tried ever showed any output. Running headless is ok, but sometimes a monitor saves networking hassle.

… and then what happened? @holly_cummins My LED connections snapped, and even though the main computer had a zip-access, those wires could only be accessed by unsewing and unstuﬃng the whole ball.

… and then what happened? Wires snapped. @holly_cummins My LED connections snapped, and even though the main computer had a zip-access, those wires could only be accessed by unsewing and unstuﬃng the whole ball.

… and then what happened? Wires snapped. Many times. @holly_cummins My LED connections snapped, and even though the main computer had a zip-access, those wires could only be accessed by unsewing and unstuﬃng the whole ball.

… and then what happened? Wires snapped. Many times. Inside a unit that had to be disassembled before any repair could be done. @holly_cummins My LED connections snapped, and even though the main computer had a zip-access, those wires could only be accessed by unsewing and unstuﬃng the whole ball.

… and then what happened? Solder burns on kitchen counter. @holly_cummins This did not make me popular at home.

… and then what happened? A USB power connector lived here @holly_cummins Thirty second before a demo, the USB power connector ripped off the board as I was stuﬃng the pcDuino into the ball.

… and then what happened? Another USB power connector lived here @holly_cummins Luckily, there was another power connector! Two months later, I ripped that one off as well, again just before a demo.

@holly_cummins Without any way to power it, a computer isn’t good for much.

It’s ok! I wired in a battery. @holly_cummins After a bit of a struggle, I was able to get the pcDuino battery connector connected to a battery (this should be easy, except one can’t buy batteries with the right connector).

… and then what happened? LiPoly battery. Standard 3.3V output. @holly_cummins The computer could run on 3.3V, but all the LEDs and the digital sensors really needed 5V to do anything at all. (My temperature readings from the analog sensor were pretty crazy with 3.3V, too.)

… and then what happened? LiPoly battery. Standard 3.3V output. Battery voltage isn’t enough for LEDs. @holly_cummins The computer could run on 3.3V, but all the LEDs and the digital sensors really needed 5V to do anything at all. (My temperature readings from the analog sensor were pretty crazy with 3.3V, too.)

… and then what happened? LiPoly battery. Standard 3.3V output. Battery voltage isn’t enough for LEDs. Or sensors. @holly_cummins The computer could run on 3.3V, but all the LEDs and the digital sensors really needed 5V to do anything at all. (My temperature readings from the analog sensor were pretty crazy with 3.3V, too.)

… and then what happened? What does that mean in practice? @holly_cummins The failure mode for a digital shock sensor when the voltage isn’t right was a surprise to me. Normally, the output pin reads 1, and it reads 0 if there’s a bounce. Of course, when the voltage isn’t enough to get a ‘1’, you always get a ‘0’, which the application thinks is perpertual bouncing. You can see how horrified I look as I realised what had gone wrong.

… and then what happened? Normally, 0 = bounce. What does that mean in practice? @holly_cummins The failure mode for a digital shock sensor when the voltage isn’t right was a surprise to me. Normally, the output pin reads 1, and it reads 0 if there’s a bounce. Of course, when the voltage isn’t enough to get a ‘1’, you always get a ‘0’, which the application thinks is perpertual bouncing. You can see how horrified I look as I realised what had gone wrong.

… and then what happened? Normally, 0 = bounce. With insufficient voltage, pin is always 0. What does that mean in practice? @holly_cummins The failure mode for a digital shock sensor when the voltage isn’t right was a surprise to me. Normally, the output pin reads 1, and it reads 0 if there’s a bounce. Of course, when the voltage isn’t enough to get a ‘1’, you always get a ‘0’, which the application thinks is perpertual bouncing. You can see how horrified I look as I realised what had gone wrong.

… and then what happened? So it infinitely … oh. Oh dear. @holly_cummins It was really hard to get that previous screencap, because it rapidly turned into this!

… and then what happened? @holly_cummins I eventually fixed my power problems, but then I had other issues. A sensor shorted, and so it stopped working, and everything else on the computer stopped working, too, until I isolated and removed the faulty sensor.

… and then what happened? Motion sensor started smoking, stopped working. Had to buy a new one. @holly_cummins I eventually fixed my power problems, but then I had other issues. A sensor shorted, and so it stopped working, and everything else on the computer stopped working, too, until I isolated and removed the faulty sensor.

… and then what happened? pcDuino stopped working. Had to buy a new one :( @holly_cummins Eventually the whole single board computer gave up the ghost and had to be replaced.

“Holly, I saw a video of your sphere talk. I thought you handled the fact that the demo failed really well. Are there any videos where it actually works?” –My mother @holly_cummins My mom’s always says I don’t phone enough, so she sometimes googles me. The depressing answer to this question was “No. No mom, there aren’t any times where it worked end to end.”

… and then what happened? @holly_cummins But then … it worked! I was so happy …

… and then what happened? It worked faultlessly. Twice in a row. @holly_cummins But then … it worked! I was so happy …

… and then what happened? @holly_cummins There’s an IoT travel dilemma; carry it as hand luggage, and risk awkward questions and confiscation, or check it, and risk loss. So I lost my demo for a key twenty four hours at a conference.

… and then what happened? Not supposed to look like that. @holly_cummins My mechanical problems also returned. My power unit had a dumb end of life caused by a snapped pin I couldn’t desolder out of the hole at eleven at night before a demo.

… and then what happened? Not supposed to look like that. Pin on power board snapped. Remnants of pin in PCB hole. @holly_cummins My mechanical problems also returned. My power unit had a dumb end of life caused by a snapped pin I couldn’t desolder out of the hole at eleven at night before a demo.

… and then what happened? @holly_cummins I got a replacement, but at eleven at night before a talk spot the theme), I realised I’d got switch wiring wrong, and it never produced any power.

… and then what happened? I did something wrong soldering the switch on the replacement. @holly_cummins I got a replacement, but at eleven at night before a talk spot the theme), I realised I’d got switch wiring wrong, and it never produced any power.

I have not failed. I’ve just found 10,000 ways that won’t work. –Thomas Edison @holly_cummins I console myself that it’s not just me.

@holly_cummins All of us do things that we’ve never done before (even if others do them all the time), and that’s hard. It’s so worthwhile, though, that we shouldn’t give up.

Being an innovator isn’t easy. @holly_cummins All of us do things that we’ve never done before (even if others do them all the time), and that’s hard. It’s so worthwhile, though, that we shouldn’t give up.

Being an innovator isn’t easy. (and we’re all innovators!) @holly_cummins All of us do things that we’ve never done before (even if others do them all the time), and that’s hard. It’s so worthwhile, though, that we shouldn’t give up.

http://www.commitstrip.com/en/2016/05/26/the-internet-of-things-a-revolution/ This strip describes a depressing number of my IoT demos.

“Holly, most of your demos are doing something really simple in a complicated way.” –My partner @holly_cummins I don’t think this was meant as a compliment!

Just because it isn’t easy, doesn’t mean it’s valuable. @holly_cummins So the corollary of ‘never give up on diﬃcult things’ is that not everything diﬃcult is worthwhile.

@holly_cummins For an example of this, we don’t need to look further than my source code to LATeX round tripper.

@holly_cummins

Know when to stop. @holly_cummins

Feedback @holly_cummins How do you know when to stop? Feedback is a great starting point. If I’d listened to feedback, or even had anybody but me try the tool, I would have realised there wasn’t enough people for whom it fixed a problem.

2016 @holly_cummins Skipping forward a few more years, let’s talk about some of the projects we’ve done in the Bluemix Garage.

@holly_cummins Simon Wheatcroft is an inspirational figure. He’s blind, and a long-distance runner. Most blind runners run with the aid of a human guide. Simon does this in marathon and ultra-marathon competitions, but he trains solo, using an app called Runkeeper. Although it wasn’t specifically designed for blind users, Runkeeper gives audio distance prompts. That, in combination with footfeel, is enough to allow Simon to maintain a mental map of where he is and train solo. Building up such a map takes a lot of repetition of the route, though, and no one - not even a committed runner - would run a 150 mile ultra-marathon course enough times to memorise how each step feels underfoot. Simon had the idea that an app could guide him, and the Bluemix Garage built it for him.

@holly_cummins Simon’s plan is to use the app to run the 155 mile Namibia desert part of the 4 deserts challenge, solo. The app is programmed with a course, and when Simon goes more than 10m to the left or right of that route, it beeps to let him to know he needs to adjust course (a bit like a satnav crossed with a reversing sensor).

“ I ’m going to do the 4 deserts run. I’ll have to run though bleeding blisters, deal with toenails falling off, and I’ll be vomiting - in the best case.” — Simon Wheatcroft @holly_cummins We knew ultra marathons were hard, but we were still surprised when Simon described some of the physical challenges he might face, even apart from navigation.

@holly_cummins We named the app we wrote eAscot, after Simon’s guide dog, Ascot. Here it is installed on my phone. We built the app in a very short time, and it successfully navigated Simon along the desert course.

How do we measure value? @holly_cummins

@holly_cummins Did this app make our fortune? Well, no. This is an app custom-built for one person, and even if we generalised it by including things like route upload interfaces, the market is necessarily limited; there’s just not that many blind ultra-marathon runners out there. So is it useless? Q: How many blind ultra-marathon runners are there? So how many people could benefit from this? All of us, in a way. Explore limits of human possibility. Remember, title is ‘making stuff for fun and profit’ - then not so much profit

Value isn’t always measured in hryven’ @holly_cummins Substitute your local currency here. Wikipedia assures me that hryven’ is the correct way of referring to Ukrainian currency. Everyone in Odessa shuﬄed their feet and looked at the floor when I asked if I had this right, so I’ll assume you’ll need to do that even if you’re in Ukraine.

Value isn’t always measured in number of users @holly_cummins

@holly_cummins Simon’s app has captured people’s imaginations, even though there’s only one user. It was such an interesting story, that I think it made people think differently about what’s possible - and that’s amazing value. I can’t include all of the links here, but here are some: • http://www.bbc.co.uk/news/technology-36312976 • http://www.cnbc.com/2016/05/03/this-blind-man-is-running-a-155-mile-ultra-marathon-with-the-help-of-an-ibm-app.html (a CNBC interview) • http://www.fastcompany.com/3059037/startup-report/how-one-blind-marathon-runner-is-using-technology-to-run-solo • https://developer.ibm.com/bluemix/2016/05/12/bluemix-garage-helps-blind-athlete-run-marathons-solo/ (a blog post I wrote)

@holly_cummins When he’s not running, Simon has a strong collaboration with his guide dog, Ascot. The app eAscot was intended to be an Ascot replacement that could cope with high speeds and deserts. Another important collaboration was the one between Simon and the Garage. The project wouldn’t have been possible for one us alone, because Simon doesn’t code, and we would never have had enough insight into Simon’s needs without working closely with him.

@holly_cummins The collaboration was really about feedback, starting right at the design stage. We had assumptions about what would be useful, and a lot of them turned out to be wrong. For example, Simon was able to tell us that beeps would be a better user interface than speech, even though speech seemed more ‘human-centred’.

Are we lone geniuses? @holly_cummins

@holly_cummins I tend to work on my demos alone, since they’re not part of my day job. I’d been working for a while on a microservices demo called “Cat-astrophe” (spot the author who’s got experience of live demos). After Christmas, I did some pair programming with my colleague Sam, and the demo got much better, both technically and as a demo.

@holly_cummins Pair-programming is a really effective development technique, especially for hard problems.

@holly_cummins Feedback again. The reason pairing works so well is that we get near constant feedback on the code we’re writing and the thought processed behind it, so both code and thinking become better.

Bus number Number of developers who can be run over by a bus before critical knowledge is lost @holly_cummins Pairing is also great for your bus number. Especially if you rotate pairs, it naturally spreads knowledge through a team.

“Code is not an asset … it’s a liability.” –Alan Cooper, 2005 @holly_cummins Why is the bus number important? Code isn’t an asset, it’s a cost - the more specialised that code is to maintain, the higher the cost. We don’t want big areas of code that everyone is too scared to touch because no one understands it except for Bob. (Alan Cooper is the father of visual basic. )

@holly_cummins In the Garage, we’re so passionate about pairing that we’ve got our oﬃce set up exclusively with pairing stations; each one has a communal laptop (which rotate around), two monitors, two keyboards, and two mice. This is Sam Gunaratne and Dom Harries pairing on a project.

Find a friend. Work with them. Better yet, find several friends. @holly_cummins

Let’s talk about tools. @holly_cummins The team around you is one of the things that helps you succeed, and another is the tools around you. Part of the problems I’ve had with the sphere is I was doing it as a hobbyist and my place is small, so I didn’t want to buy a lot of kit.

@holly_cummins I posted a sad photo of an 11pm sphere repair session, and someone pointed out that my soldering iron was inappropriate. My immediate response: “Yes, yes I could. Sadly, 11 at night, right before a demo, isn’t the time to buy one.”

@holly_cummins I did take the advice, though, and replace my iron with one suitable for electronics, and I also got other bits I needed (like a desoldering pump and desoldering braid, which might have saved my snapped-pin bacon), and a stand, which might have saved my worktop from burns.

“How hard can an offline data push be?” –Me @holly_cummins Tools aren’t just physical, of course. One of the things the Simon app needed to do was upload the actual route he ran. There’s no mobile coverage in the desert where Simon was, but we were told he would have a small amount of satellite data in the evenings, so we wrote a bit of code to wait for the data connection to be available and then push up the stored route data since the last push.

@holly_cummins Confession time: it turns out it’s exactly that hard. That map is where his route is supposed to be. I hate this, it makes me so mad. Our designer worked hard on the design, and we were going to send the information to Simon’s friends, but something went wrong and we never got any data.

Simon’s route was supposed to be shown here :( @holly_cummins Confession time: it turns out it’s exactly that hard. That map is where his route is supposed to be. I hate this, it makes me so mad. Our designer worked hard on the design, and we were going to send the information to Simon’s friends, but something went wrong and we never got any data.

There is no devops in the desert. @holly_cummins Some mistakes you don’t have a chance to fix. The oﬄine push worked every time in testing, but failed when it mattered, and we couldn’t get a patch out, because Simon was in the desert with no signal.

@holly_cummins This is what we should have done. Bluemix has a lot of great services (it’s part of what makes us eﬃcient in the Garage, because we can leverage the platform).

@holly_cummins In particular, Cloudant has, out of the box, mobile extensions for oﬄine synch.

@holly_cummins There’s even lots of documentation and everything.

@holly_cummins You could see this as another variation of the wheel problem - I didn’t use existing tech because I was too lazy (or focussed on the immediate task) to go out and learn a tool.

Use the tools available to you. @holly_cummins

Beware not-inventedhere syndrome. @holly_cummins This is something we all naturally do, so we need to be aware of the tendency.

Cuddly toy hotel Cuddly toy zipwire @holly_cummins It’s hard to resist building stuff, because we all love making stuff, right?

“Just because you can, d o e s n’ t m e a n y o u should.” –Lt. Col. Carlos A. Keasler @holly_cummins

As useless as a … @holly_cummins In Britain, ultimate useless thing is a chocolate teapot. And of course such things don’t exist, it’s just a metaphor.

As useless as a … chocolate teapot. @holly_cummins In Britain, ultimate useless thing is a chocolate teapot. And of course such things don’t exist, it’s just a metaphor.

@holly_cummins … except that almost anything one can think of, someone will have made.

@holly_cummins The same applies to things one would never think of, like RFID socks.

Just because you can, doesn’t mean you should. @holly_cummins

Help Desk @holly_cummins How do you know if you should? Some of it is judgement, and some is experimentation and measurement. This is another project we worked on this year, for a customer who wanted to improve the eﬃciency of their help desk.

Email Ticket @holly_cummins Problems were raised by email, and then a person would choose the right queue for the request in a ticketing system. Their question was “could a computer do this instead?”

? Email Ticket @holly_cummins Problems were raised by email, and then a person would choose the right queue for the request in a ticketing system. Their question was “could a computer do this instead?”

@holly_cummins This is the sort of unstructured problem where a normal search algorithm would do badly, but Watson does really well.

@holly_cummins Cognitive computing is a new domain, and so the customer wanted to see if it could fix their problem. So we started small, and asked lots of questions along the way.

Hypothesis: Can a computer categorise the emails into the right queue in the ticketing system? @holly_cummins Cognitive computing is a new domain, and so the customer wanted to see if it could fix their problem. So we started small, and asked lots of questions along the way.

Hypothesis: Can a computer categorise the emails into the right queue in the ticketing system? Minimum Viable Product: Watson categorisation of exported emails + dashboard + metrics @holly_cummins Cognitive computing is a new domain, and so the customer wanted to see if it could fix their problem. So we started small, and asked lots of questions along the way.

Hypothesis: Can a computer categorise the emails into the right queue in the ticketing system? Minimum Viable Product: Watson categorisation of exported emails + dashboard + metrics Cost: Two weeks @holly_cummins Cognitive computing is a new domain, and so the customer wanted to see if it could fix their problem. So we started small, and asked lots of questions along the way.

Hypothesis: Can a computer categorise the emails into the right queue in the ticketing system? Minimum Viable Product: Watson categorisation of exported emails + dashboard + metrics Cost: Two weeks Answer: Yes! It’s awesome! @holly_cummins Cognitive computing is a new domain, and so the customer wanted to see if it could fix their problem. So we started small, and asked lots of questions along the way.

Hypothesis: Can a computer categorise the emails into the right queue in the ticketing system? Minimum Viable Product: Watson categorisation of exported emails + dashboard + metrics Cost: Two weeks Answer: Yes! It’s awesome! Next step: Live emails. @holly_cummins Cognitive computing is a new domain, and so the customer wanted to see if it could fix their problem. So we started small, and asked lots of questions along the way.

Hypothesis: Can a computer categorise the emails into the right queue in the ticketing system? Minimum Viable Product: Watson categorisation of exported emails + dashboard + metrics Cost: Two weeks Answer: Yes! It’s awesome! Next step: Live emails. And repeat… @holly_cummins Cognitive computing is a new domain, and so the customer wanted to see if it could fix their problem. So we started small, and asked lots of questions along the way.

Hypothesis: Can a computer categorise the emails into the right queue in the ticketing system? Minimum Viable Product: Watson categorisation of exported emails + dashboard + metrics Cost: Two weeks Answer: Yes! It’s awesome! Next step: Live emails. And repeat… Lean Startup @holly_cummins Cognitive computing is a new domain, and so the customer wanted to see if it could fix their problem. So we started small, and asked lots of questions along the way.

Does what I built work? @holly_cummins That’s a specific case, of a more general question we always want to know when we build stuff - does it work?

“It worked a second ago, when you weren’t watching, honest!” –Me @holly_cummins How many of us have said this? I’ve said it more times than I can count.

Demo-driven testing. @holly_cummins I’ve said it so many times that I’ve started calling it demo-driven testing, or audience-driven testing. Demo driven testing is not a good idea. With the sphere things where a little bit different because each use of the sphere shortened the life of the parts and increased the chances of a mechanical failure. For software, where that doesn’t apply, we should do proper testing. A lot.

Test first. Code second. @holly_cummins The best way to test is to write the test first, so you know it works. (The best way to confirm a test works is to know it can fail.) Writing tests first also helps us think carefully about exactly what behaviour we expect from our code, which is a better place to start than thinking about how the implementation should look.

@holly_cummins More feedback! Writing the tests first - and running them continuously - ensures we’re find out fast about any regressions in behaviour.

Automate everything. @holly_cummins The way to get that continuous feedback is to ensure tests are automated, and that they run automatically. Unfortunately, continuous automated testing was not so easy for sphere, because things are different in the hardware world. The failures are all mechanical ones, and testing - like any use - tends to increase the chance of failure.

Automate everything. Quality @holly_cummins The way to get that continuous feedback is to ensure tests are automated, and that they run automatically. Unfortunately, continuous automated testing was not so easy for sphere, because things are different in the hardware world. The failures are all mechanical ones, and testing - like any use - tends to increase the chance of failure.

Automate everything. Quality Nimbleness. @holly_cummins The way to get that continuous feedback is to ensure tests are automated, and that they run automatically. Unfortunately, continuous automated testing was not so easy for sphere, because things are different in the hardware world. The failures are all mechanical ones, and testing - like any use - tends to increase the chance of failure.

@holly_cummins When we’re not dealing with hardware, though, getting an automated build and test pipeline is important. This is another area where Bluemix helps a lot. Bluemix has integrated devops services (http://hub.jazz.net).

@holly_cummins Our pipelines are triggered anytime the git code changes, build, run unit tests, run integration tests using SauceLabs (which has a Devops Services integration), and then push to Bluemix.

My team do this first. Always. @holly_cummins Our pipelines are triggered anytime the git code changes, build, run unit tests, run integration tests using SauceLabs (which has a Devops Services integration), and then push to Bluemix.

Continuously deliver. @holly_cummins

What I’ve learned @holly_cummins This talk has covered a lot of tips for building stuff, so a recap is probably useful.

What I should have learned @holly_cummins

@holly_cummins A lot of these principles are part of the method my team uses, and is sharing within IBM, which we call the Bluemix Garage method. You can read more at http:// www.ibm.com/devops/method.

@holly_cummins

• You may not succeed the first time. Or even the tenth time. @holly_cummins

• You may not succeed the first time. Or even the tenth time. • Don’t reinvent wheels without reason. @holly_cummins

• You may not succeed the first time. Or even the tenth time. • Don’t reinvent wheels without reason. • Just because it’s difficult, doesn’t mean it’s valuable. @holly_cummins

• You may not succeed the first time. Or even the tenth time. • Don’t reinvent wheels without reason. • Just because it’s difficult, doesn’t mean it’s valuable. • Value has lots of forms. @holly_cummins

• You may not succeed the first time. Or even the tenth time. • Don’t reinvent wheels without reason. • Just because it’s difficult, doesn’t mean it’s valuable. • Value has lots of forms. • Find a friend. Work with them. @holly_cummins

• You may not succeed the first time. Or even the tenth time. • Don’t reinvent wheels without reason. • Just because it’s difficult, doesn’t mean it’s valuable. • Value has lots of forms. • Find a friend. Work with them. • Use the right tools. @holly_cummins

• You may not succeed the first time. Or even the tenth time. • Don’t reinvent wheels without reason. • Just because it’s difficult, doesn’t mean it’s valuable. • Value has lots of forms. • Find a friend. Work with them. • Use the right tools. • Test first. Code second. @holly_cummins

• You may not succeed the first time. Or even the tenth time. • Don’t reinvent wheels without reason. • Just because it’s difficult, doesn’t mean it’s valuable. • Value has lots of forms. • Find a friend. Work with them. • Use the right tools. • Test first. Code second. • CI/CD is really important. @holly_cummins

Feedback Focus on user value Tools @holly_cummins This summary is still a lot of tips, but they reduce down to these three. You want the tools so that they leave you more time to create value, and so that you can get feedback faster. The way you learn if you’re on the right track with user value is feedback …

Feedback @holly_cummins So, actually, they all reduce right down to feedback: get lots of it, get it as often as possible, use it to keep quality high, and use it to learn.

And finally … @holly_cummins

@holly_cummins http://ibm.biz/bluemixgaragelondon @holly_cummins

Building Stuff for Fun and Profit - confessions from a life in code and cables

Slide 1

Slide 2

Slide 3

Slide 4

Slide 5

Slide 6

Slide 7

Slide 8

Slide 9

Slide 10

Slide 11

Slide 12

Slide 13

Slide 14

Slide 15

Slide 16

Slide 17

Slide 18

Slide 19

Slide 20

Slide 21

Slide 22

Slide 23

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Slide 32

Slide 33

Slide 34

Slide 35

Slide 36

Slide 37

Slide 38

Slide 39

Slide 40

Slide 41

Slide 42

Slide 43

Slide 44

Slide 45

Slide 46

Slide 47

Slide 48

Slide 49

Slide 50

Slide 51

Slide 52

Slide 53

Slide 54

Slide 55

Slide 56

Slide 57

Slide 58

Slide 59

Slide 60

Slide 61

Slide 62

Slide 63

Slide 64

Slide 65

Slide 66

Slide 67

Slide 68

Slide 69

Slide 70

Slide 71

Slide 72

Slide 73

Slide 74

Slide 75