A year after speaking at Ruby Ireland about building a proof-of-concept Ruby-on-Rails app for a big corporate client. It went so well that they commissioned a full product build. Having recently completed the full project - and a casestudy - we wanted to come back to Ruby Ireland and update everyone on how it went. Did Ruby succeed or fail?? Who was the mysterious client??
Today’s tools and services gives you lot of power and control when it comes to setting up continuous integration and deployments. And they provide support to all popular languages, like Ruby, Python, Javascript out of the box, as well as some hip ones, like Rust and Go, that might not be used that much, but sound cool.
At a talk we gave recently to Ruby Ireland, I was support to the main act (the Kobayashi to the Ruby Kyser Söze, I suppose) on the topic of "Can Ruby Survive the Financial Turmoil". I promised the room I'd publish my talk on our blog - finally, here it is...
It's been an interesting year, have to say. This time last year the we were working with SumUp, and I think none of us would have thought that merely 12 months later we be standing (actually sitting) here, with TheProduct.Works...
On the Wednesday, 08 October, I presented to the senior management team at the National Maternity Hospital, Holles St.
The subject? The SMART app for mobile and browser. You can read a little more about the project here.
The response from the NMH management team? Absolute and overwhelming support and enthusiasm for the SMART project. Wooohoooo, we'd gotten the final sign-off!!!
Teresa and I were over the moon after the meeting. The Product Works iMessage chat room was full of exclamations after I messaged the lads back at base.
Why so elated? Sure, the sign-off by the NMH management team was a great milestone in a project that meant a lot to all of us. It was vindication of 3 months of spiking, planning, development on our part - not to mention 2 years of dedication by Teresa herself. It was great being able to show the management team the working prototypes. God, I was even a little chuffed after the preparation I'd put into the presentation itself. But all those things are par for course with product development, right? Reflecting on it all, it didn't really add up to the spontaneous elation we'd all felt after the meeting. So what was it?
For me, it was immediate recognition in the management team of the concept and its value - the sheer lack of surprise in the room when I revealed the prototypes for the first time - that was the remarkable thing. We'd nailed the product development! And we'd done it our way, The Product Works way.
Let me wind it back a little... my 2-year stint of leading SumUp organisation and product development here in Dublin ended in the summer just gone. As we wrapped up the office, I had naturally begun looking ahead to my next challenge. I had a strong sense of direction with what I wanted to do next, but only a blurred image of what the end form would look like. No bother though; it's the journey as much as the destination for me. I had long adopted an evolutionary approach to all projects - keep what works, tweak what doesn't, keep moving - and felt sure that the same could be applied in starting the company. Natural selection for ideas, if you will. I was delighted and honoured when Mate and John agreed to sign-up for the journey, despite the uncertain course.
First step: what to do?
We wanted SMART to be our first product and, with Teresa's blessing, we began work in earnest in July.
Next step: how to do it?
Over the years, I've seen a lot of complex behaviours build up around the development of software. In fact, the processes and tools often take the focus of the project - it's as if some believe that software isn't credible unless everything around it is complex.
I was keen to strip out the extraneous. I believe there are some basic behaviours that are the core to all good product development, irrespective of how technical the implementation or the tools needed. We all agreed that The Product Works would follow some basic human simplicities that had worked so well for us in the past.
Lots of Dr Phil stuff there, eh? But there it is; these are the things that have guided us. I'll be blogging more on these topics but let me give some examples of how these manifested in the SMART project...
We thought like a community midwife.
We had a stakeholder AND end-user in one person in Teresa, who not only manages a team in the Community Midwives but is also works on the front-line with the mothers and babies. Perfect. By simply talking to Teresa about her days - what was easy, what was painful - we quickly built a mental picture of how the NMH Community Midwives went about their days.
We talked.
We sat with Teresa for several sessions and simply talked to her about her daily worklife. It was obvious that the midwifery teams were managing a quite complex paper-based system. It was working for them - it had grown organically to suit their needs - but it was time-consuming and repetitive. Hah, the perfect place for software. The early talking allowed us to model the midwifery team's behaviours in both UI and backend. Then, throughout the project, we continued the dialogue, continuously getting Teresa to validate our work. If we ever diverged, then it was never by much.
We learnt the lingo.
Surprise, surprise, it turns out that natal care and midwifery comes with its own syntax! One of the first things we do is to build a domain glossary (ehh, a table in a google doc!) and input all the phrases that arose in conversations with Teresa, coming up with our own plain-english definitions and getting Teresa to review them.
We then forced ourselves to use the syntax. Software development is the petri-dish of abbreviations, acronyms and obtuse references; so we forced ourselves to use meaningful midwife syntax everywhere: in our conversations with each other, in API calls, in database tables and columns, etc.
We used simple tools
All of our daily tools needed to compliment the act of talking, not get in the way. We started with, wait for it, paper and pencil (not pen)! A pretty cool notebook in fact, which is coincidentally the rough same shape as a mobile phone. We still use these for conversations, passing round the notebook and pencil.
But we were not always in the same place so for online we used simple word docs and spreadsheets in google docs for things like our glossary and data field definitions, Trello for simple task management. We've found these tools to be the closest we've seen to a physical whiteboard... as I type into a google doc or move a Trello card in my apartment in Dublin, Mate can see my updates in real-time at home in Bray, almost as if I'm at the whiteboard in front of him. Magic.
We tried stuff, we prototyped
How much you prototype depends on the complexity of the task ahead. I've seen instances where the effort invested in a prototype far outweighs the benefit to the project. We prototyped in 2 ways that allowed us to work in parallel:
And so the design - from balls to braces - evolved and developed over time. While we had some idea of what we needed from the initial conversations, by allowing the full picture to emerge as we went, rather than try to define everything upfront, relieved everyone involved of getting it right from the get-go. The conversations between us all were immediately more cooperative and collegiate.
We threw stuff out.
As is typical of software projects, internal naming convention did not end up matching external domain lexicon. Often this is never corrected; remnants of old project names or properties linger throughout code bases. We are serious about having consistency across the entire project. We were never afraid to rename database or json schema. At one stage we changed the name of the entire repo in GitHub so that it matched the name being used by Teresa. There was also a dalliance with tagging that, while really excited us, we just couldn't reason a way for it's inclusion in the final drafts. We dropped it.
A week after the sign-off with the senior management, while thinking about this, I had occasion to visit the Community Midwife office and get introduced to some of the team. I sat down with Pauline, one of the office support staff, to give her a first glimpse of the web prototype on my laptop. I was about to lead off on the touchpad when, without prompting, Pauline reached over and took over my laptop. Without any guidance she began clicking through the creation of an appointment in SMART. I sat back, watched and smiled. We'd done it. The Product Works way!
