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

© 2016 IBM Corporation

Building stuff for fun and profit

Dr Holly Cummins Bluemix Garage, London

@holly_cummins

@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.

@holly_cummins

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

@holly_cummins

http://ibm.biz/bluemixgaragelondon

If you’d like to know more about Bluemix, the link will take you to a signup page for a free trial.


@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.

@holly_cummins1987

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

@holly_cummins

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

@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.

@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

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.

@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.

@holly_cummins

Idea.


@holly_cummins

Idea.

Built it.


@holly_cummins

Idea.

Built it.

Used it.


@holly_cummins

#devops

Idea.

Built it.

Used it.


@holly_cummins

2001

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

@holly_cummins

2002In 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

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.

@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.

@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.

@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).

@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 efficiently.

@holly_cummins

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

@holly_cummins

@holly_cummins

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

@holly_cummins

2011

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

+

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.

@holly_cummins

The WebSphere Hat


@holly_cummins

The WebSphere Hat(“the world’s first wearable application server”)


@holly_cummins

There’s a WebSphere server running in that hat

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 :)

@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.)

@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.)

@holly_cummins

embedded application

server

Sensors

Liberty

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).

@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.

@holly_cummins

@holly_cumminsphoto courtesy of re:develop conference, Bournemouth

@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.

@holly_cummins

Who wouldn’t want an application server in

a cuddly ball?

@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.

@holly_cummins


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.

@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 unstuffing the whole ball.

@holly_cummins


Wires snapped.


@holly_cummins


Wires snapped.

Many times.


@holly_cummins


Wires snapped.

Many times.Inside a unit that had to be disassembled before any repair could be done.


@holly_cummins

Solder burns on kitchen counter.


This did not make me popular at home.

@holly_cummins

A USB power connector lived here


Thirty second before a demo, the USB power connector ripped off the board as I was stuffing the pcDuino into the ball.

@holly_cummins

Another USB power connector lived here


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.

@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).

@holly_cummins


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.)

@holly_cummins


Battery voltage isn’t enough for LEDs.



@holly_cummins


Battery voltage isn’t enough for LEDs.

Or sensors.



@holly_cummins


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.

@holly_cummins



Normally, 0 = bounce.


@holly_cummins



Normally, 0 = bounce.With insufficient voltage, pin is always 0.


@holly_cummins


So it infinitely … oh. Oh dear.

It was really hard to get that previous screencap, because it rapidly turned into this!

@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.

@holly_cummins


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.

@holly_cummins

pcDuino stopped working. Had to buy a new one :(


Eventually the whole single board computer gave up the ghost and had to be replaced.

@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.”

@holly_cummins


But then … it worked! I was so happy …

@holly_cummins


It worked faultlessly.Twice in a row.

But then … it worked! I was so happy …

@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.

@holly_cummins


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.

@holly_cummins


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.

@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.

@holly_cummins


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.

@holly_cummins

–Thomas Edison

I have not failed. I've just found 10,000 ways that won't work.

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.

@holly_cummins

Being an innovator isn’t easy.


@holly_cummins

Being an innovator isn’t easy.(and we’re all innovators!)


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_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!

@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.

@holly_cummins

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

@holly_cummins

@holly_cummins

Know when to stop.

@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.

@holly_cummins

2016

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).

@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.

@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.

@holly_cummins

How do we measure value?

@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

@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.

@holly_cummins

Value isn’t always measured in number of users

@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’.

@holly_cummins

Are we lone geniuses?

@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.

@holly_cummins

Bus numberNumber 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.

@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. )

@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.

@holly_cummins

Find a friend. Work with them.

Better yet, find several friends.

@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.

@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.

@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.

@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.

@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.

@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.

@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).

@holly_cummins

In particular, Cloudant has, out of the box, mobile extensions for offline 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.

@holly_cummins

Use the tools available to you.

@holly_cummins

Beware not-invented-here syndrome.

This is something we all naturally do, so we need to be aware of the tendency.

@holly_cummins

Cuddly toy zipwire

Cuddly toy hotel

It’s hard to resist building stuff, because we all love making stuff, right?

@holly_cummins

–Lt. Col. Carlos A. Keasler

“Just because you can, do e s n’ t me an you should.”

@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.

@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.

@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.

@holly_cummins

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

@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.

@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?”

@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?”

@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.

@holly_cummins

Hypothesis: Can a computer categorise the emails into the right queue in the ticketing system?


@holly_cummins


Minimum Viable Product: Watson categorisation of exported emails + dashboard + metrics


@holly_cummins



Cost: Two weeks


@holly_cummins



Cost: Two weeks

Answer: Yes! It's awesome!


@holly_cummins



Cost: Two weeks


Next step: Live emails.


@holly_cummins



Cost: Two weeks



And repeat…


@holly_cummins

Lean Startup



Cost: Two weeks



And repeat…


@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?

@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.

@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.

@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.

@holly_cummins

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

@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.

@holly_cummins


Quality


@holly_cummins


Quality Nimbleness.


@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.

@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.

@holly_cummins

Continuously deliver.

@holly_cummins

What I’ve learned

This talk has covered a lot of tips for building stuff, so a recap is probably useful.

@holly_cummins

What I should have learned

@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

@holly_cummins

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

@holly_cummins


• Don’t reinvent wheels without reason.

@holly_cummins



• Just because it’s difficult, doesn’t mean it’s valuable.

@holly_cummins




• Value has lots of forms.

@holly_cummins





• Find a friend. Work with them.

@holly_cummins






• Use the right tools.

@holly_cummins







• Test first. Code second.

@holly_cummins







• Test first. Code second.

• CI/CD is really important.

@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 …

@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.

@holly_cummins

And finally …

@holly_cummins

@holly_cummins



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

Software

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