I love making stuff. I'm so happy that my job allows me to make stuff, and when I'm not at work, I'm making stuff anyway. Some of the stuff I've made has solved real technical and business problems; some of it I've done just to see if I can. In this talk I'll describe some of the valuable things I've built for my employer, IBM, and our clients - I'll also describe some of the ridiculous things I've made for myself.
These are slides for a talk given at BuildStuff Odessa, 2016 (http://www.buildstuff.com.ua/odessa/)
2. @holly_cummins
What is the Bluemix Garage?
(It’s not actually a Garage.)
I’m the technical lead in IBM’s London Bluemix Garage. The Garages are located in startup communities, rather than IBM offices. Our mission is to do exciting customer
projects using the Bluemix platform and the Bluemix Garage Method.
3. @holly_cummins
The Garage is all about innovation; we use a combination of design thinking, xp, and lean startup to help clients innovate quickly.
5. @holly_cummins
Cuddly toy
zipwire
Cuddly toy
hotel
1979
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.
6. @holly_cummins
Cuddly toy
zipwire
Cuddly toy
hotel
1979
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.
9. @holly_cummins
1998
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.
10. @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.
11. @holly_cummins
No matter how much math you
throw at it, you can’t actually
predict what it’s going to do.
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.
12. @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.
13. @holly_cummins
Idea.
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.
14. @holly_cummins
Idea.
Built it.
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.
15. @holly_cummins
Idea.
Built it.
Used it.
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.
16. @holly_cummins
#devops
Idea.
Built it.
Used it.
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.
19. @holly_cummins
2002
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.
20. @holly_cummins
2002
100 page design document.
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.
21. @holly_cummins
2002
100 page design document.
Seriously.
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.
22. @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.
23. @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.
24. @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.
25. @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.
26. @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.
27. @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.
28. @holly_cummins
But …
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).
29. @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.
30. @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.
31. @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 efficiently.
37. @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.
38. @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.
39. @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.
40. @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.
41. @holly_cummins
The WebSphere Hat
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.
42. @holly_cummins
The WebSphere Hat
(“the world’s first wearable application server”)
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.
44. @holly_cummins
I didn’t get the hat fully portable in the first version; that’s an ethernet cable coming down from my head :)
45. @holly_cummins
2014
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.)
46. @holly_cummins
2014
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.)
47. @holly_cummins
Presenting:
The WebSphere Sphere
(“the cuddly throwable application server”)
2014
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.)
49. @holly_cummins
Sensors
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.
50. @holly_cummins
Sensors
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.
53. @holly_cummins
–My Mother
“Holly, why would
anyone want an
application server in
a cuddly ball?”
I told my mom all about my hard work, but she was a bit perplexed about why it was valuable.
55. @holly_cummins
… and then what happened?
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.
56. @holly_cummins
… and then what happened?
pcDuino could never
display on any monitor.
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.
57. @holly_cummins
… and then what happened?
My LED connections snapped, and even though the main computer had a zip-access, those wires could only be accessed by unsewing and unstuffing the whole ball.
58. @holly_cummins
… and then what happened?
Wires snapped.
My LED connections snapped, and even though the main computer had a zip-access, those wires could only be accessed by unsewing and unstuffing the whole ball.
59. @holly_cummins
… and then what happened?
Wires snapped.
Many times.
My LED connections snapped, and even though the main computer had a zip-access, those wires could only be accessed by unsewing and unstuffing the whole ball.
60. @holly_cummins
… and then what happened?
Wires snapped.
Many times.
Inside a unit that had to be
disassembled before any
repair could be done.
My LED connections snapped, and even though the main computer had a zip-access, those wires could only be accessed by unsewing and unstuffing the whole ball.
62. @holly_cummins
A USB power
connector lived here
… and then what happened?
Thirty second before a demo, the USB power connector ripped off the board as I was stuffing the pcDuino into the ball.
63. @holly_cummins
Another USB power
connector lived here
… and then what happened?
Luckily, there was another power connector! Two months later, I ripped that one off as well, again just before a demo.
65. @holly_cummins
It’s ok! I wired in a battery.
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).
66. @holly_cummins
… and then what happened?
LiPoly battery.
Standard 3.3V output.
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.)
67. @holly_cummins
… and then what happened?
Battery voltage isn’t enough
for LEDs.
LiPoly battery.
Standard 3.3V output.
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.)
68. @holly_cummins
… and then what happened?
Battery voltage isn’t enough
for LEDs.
Or sensors.
LiPoly battery.
Standard 3.3V output.
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.)
69. @holly_cummins
… and then what happened?
What does that mean in practice?
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.
70. @holly_cummins
… and then what happened?
What does that mean in practice?
Normally, 0 = bounce.
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.
71. @holly_cummins
… and then what happened?
What does that mean in practice?
Normally, 0 = bounce.
With insufficient
voltage, pin is always 0.
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.
72. @holly_cummins
… and then what happened?
So it infinitely … oh. Oh dear.
It was really hard to get that previous screencap, because it rapidly turned into this!
73. @holly_cummins
… and then what happened?
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.
74. @holly_cummins
… and then what happened?
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.
75. @holly_cummins
… and then what happened?
Motion sensor started
smoking, stopped working.
Had to buy a new one.
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.
76. @holly_cummins
pcDuino stopped working.
Had to buy a new one :(
… and then what happened?
Eventually the whole single board computer gave up the ghost and had to be replaced.
77. @holly_cummins
–My mother
“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 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.”
79. @holly_cummins
… and then what happened?
It worked faultlessly.
Twice in a row.
But then … it worked! I was so happy …
80. @holly_cummins
… and then what happened?
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.
81. @holly_cummins
… and then what happened?
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.
82. @holly_cummins
… and then what happened?
Not supposed to
look like that.
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.
83. @holly_cummins
… and then what happened?
Pin on power board snapped.
Remnants of pin in PCB hole.
Not supposed to
look like that.
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.
84. @holly_cummins
… and then what happened?
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.
85. @holly_cummins
… and then what happened?
I did something wrong
soldering the switch on
the replacement.
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.
87. @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.
88. @holly_cummins
Being an innovator isn’t easy.
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.
89. @holly_cummins
Being an innovator isn’t easy.
(and we’re all innovators!)
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.
91. @holly_cummins
–My partner
“Holly, most of your
demos are doing
something really simple
in a complicated way.”
I don’t think this was meant as a compliment!
92. @holly_cummins
Just because it isn’t easy,
doesn’t mean it’s valuable.
So the corollary of ‘never give up on difficult things’ is that not everything difficult is worthwhile.
96. @holly_cummins
Feedback
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.
98. @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.
99. @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).
100. @holly_cummins
“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
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.
101. @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.
103. @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
104. @holly_cummins
Value isn’t always
measured in hryven’
Substitute your local currency here. Wikipedia assures me that hryven’ is the correct way of referring to Ukrainian currency. Everyone in Odessa shuffled 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.
106. @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)
107. @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)
108. @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.
109. @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’.
111. @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.
113. @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.
114. @holly_cummins
Bus number
Number of developers who can
be run over by a bus before
critical knowledge is lost
Pairing is also great for your bus number. Especially if you rotate pairs, it naturally spreads knowledge through a team.
115. @holly_cummins
–Alan Cooper, 2005
“Code is not an asset
… it’s a liability.”
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. )
116. @holly_cummins
In the Garage, we’re so passionate about pairing that we’ve got our office 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.
118. @holly_cummins
Let’s talk about
tools.
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.
119. @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.”
120. @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.
121. @holly_cummins
–Me
“How hard can an
offline data push be?”
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.
122. @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.
123. @holly_cummins
Simon’s route was
supposed to be
shown here :(
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.
124. @holly_cummins
There is no devops in
the desert.
Some mistakes you don’t have a chance to fix. The offline 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.
125. @holly_cummins
This is what we should have done. Bluemix has a lot of great services (it’s part of what makes us efficient in the Garage, because we can leverage the platform).
128. @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.
134. @holly_cummins
As useless as a …
In Britain, ultimate useless thing is a chocolate teapot. And of course such things don’t exist, it’s just a metaphor.
135. @holly_cummins
As useless as a …
chocolate teapot.
In Britain, ultimate useless thing is a chocolate teapot. And of course such things don’t exist, it’s just a metaphor.
139. @holly_cummins
Help Desk
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 efficiency of their help desk.
140. @holly_cummins
Email Ticket
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?”
141. @holly_cummins
Email Ticket
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?”
142. @holly_cummins
?
Email Ticket
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?”
143. @holly_cummins
This is the sort of unstructured problem where a normal search algorithm would do badly, but Watson does really well.
144. @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.
145. @holly_cummins
Hypothesis: Can a computer categorise the emails into the
right queue in the ticketing system?
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.
146. @holly_cummins
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
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.
147. @holly_cummins
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
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.
148. @holly_cummins
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!
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.
149. @holly_cummins
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.
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.
150. @holly_cummins
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…
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.
151. @holly_cummins
Lean Startup
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…
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.
152. @holly_cummins
Lean Startup
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…
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.
153. @holly_cummins
Does what I
built work?
That’s a specific case, of a more general question we always want to know when we build stuff - does it work?
154. @holly_cummins
–Me
“It worked a second
ago, when you weren’t
watching, honest!”
How many of us have said this? I’ve said it more times than I can count.
155. @holly_cummins
Demo-driven testing.
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.
156. @holly_cummins
Test first.
Code second.
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.
157. @holly_cummins
More feedback! Writing the tests first - and running them continuously - ensures we’re find out fast about any regressions in behaviour.
158. @holly_cummins
Automate everything.
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.
159. @holly_cummins
Automate everything.
Quality
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.
160. @holly_cummins
Automate everything.
Quality
Nimbleness.
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.
161. @holly_cummins
Automate everything.
Quality
Nimbleness.
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.
162. @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).
163. @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.
164. @holly_cummins
My team do this first. Always.
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.
168. @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.
171. @holly_cummins
• You may not succeed the first
time. Or even the tenth time.
• Don’t reinvent wheels without
reason.
172. @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.
173. @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.
174. @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.
175. @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.
176. @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.
177. @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.
178. @holly_cummins
Feedback
Focus on user value
Tools
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 …
179. @holly_cummins
Feedback
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.
I’m the technical lead in IBM’s London Bluemix Garage. The Garages are located in startup communities, rather than IBM offices. Our mission is to do exciting customer projects using the Bluemix platform and the Bluemix Garage Method.
The Garage is all about innovation; we use a combination of design thinking, xp, and lean startup to help clients innovate quickly.
If you’d like to know more about Bluemix, the link will take you to a signup page for a free trial.
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.
When I got a bit more skilled, I moved on to modelling clay.
Anyone want to take a guess about the date, from looking at the computer?
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.
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.
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.
In 2001, I got my first real job, with IBM.
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.
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.
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.
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.
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).
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.
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 efficiently.
I’d reinvented a wheel. And it was the WRONG wheel, and it was a wheel with almost no audience.
Skip forward a few years, to 2011.
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.
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.
Here’s me looking very dignified in the hat.
I didn’t get the hat fully portable in the first version; that’s an ethernet cable coming down from my head :)
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.)
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).
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.
This is the URL for the web app hosted by the sphere (when it’s running on the same wireless network).
I told my mom all about my hard work, but she was a bit perplexed about why it was valuable.
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.
My LED connections snapped, and even though the main computer had a zip-access, those wires could only be accessed by unsewing and unstuffing the whole ball.
This did not make me popular at home.
Thirty second before a demo, the USB power connector ripped off the board as I was stuffing the pcDuino into the ball.
Luckily, there was another power connector! Two months later, I ripped that one off as well, again just before a demo.
Without any way to power it, a computer isn’t good for much.
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).
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.)
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.
It was really hard to get that previous screencap, because it rapidly turned into this!
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.
Eventually the whole single board computer gave up the ghost and had to be replaced.
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.”
But then … it worked! I was so happy …
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.
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.
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 console myself that it’s not just me.
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.
This strip describes a depressing number of my IoT demos.
I don’t think this was meant as a compliment!
So the corollary of ‘never give up on difficult things’ is that not everything difficult is worthwhile.
For an example of this, we don’t need to look further than my source code to LATeX round tripper.
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.
Skipping forward a few more years, let’s talk about some of the projects we’ve done in the Bluemix Garage.
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.
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).
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.
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.
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
Substitute your local currency here. Wikipedia assures me that hryven’ is the correct way of referring to Ukrainian currency. Everyone in Odessa shuffled 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.
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)
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.
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’.
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.
Pair-programming is a really effective development technique, especially for hard problems.
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.
Pairing is also great for your bus number. Especially if you rotate pairs, it naturally spreads knowledge through a team.
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. )
In the Garage, we’re so passionate about pairing that we’ve got our office 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.
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.
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.”
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.
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.
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.
Some mistakes you don’t have a chance to fix. The offline 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.
This is what we should have done. Bluemix has a lot of great services (it’s part of what makes us efficient in the Garage, because we can leverage the platform).
In particular, Cloudant has, out of the box, mobile extensions for offline synch.
There’s even lots of documentation and everything.
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.
This is something we all naturally do, so we need to be aware of the tendency.
It’s hard to resist building stuff, because we all love making stuff, right?
In Britain, ultimate useless thing is a chocolate teapot. And of course such things don’t exist, it’s just a metaphor.
… except that almost anything one can think of, someone will have made.
The same applies to things one would never think of, like RFID socks.
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 efficiency of their help desk.
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?”
This is the sort of unstructured problem where a normal search algorithm would do badly, but Watson does really well.
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.
That’s a specific case, of a more general question we always want to know when we build stuff - does it work?
How many of us have said this? I’ve said it more times than I can count.
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.
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.
More feedback! Writing the tests first - and running them continuously - ensures we’re find out fast about any regressions in behaviour.
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.
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).
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.
This talk has covered a lot of tips for building stuff, so a recap is probably useful.
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.
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 …
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.
TODO this is great, but what story does it fit? maybe more near beginning? need transition
75% of us spend less than half our time coding.
I’m getting kind of senior, so I won’t tell you what my answer was
TODO i forget what this means