I have been working to build a “Remote-able” software delivery team in an otherwise office-based company for the last 12 months.
Now, as the COVID-19 pandemic takes hold, we are able to share a set of successful practices with other teams making the transition to remote.
For the individual, remote working offers huge value, most notably in freeing up time otherwise spent commuting. In the UK, 3.7million people commute for 2+ hours / day. …
Apps are the most accessible way to engage with the online world, making light work of monotonous tasks. Should you develop one too?
It’s hard to argue against the fundamental idea that people use technology to solve problems. And we know that App usage is growing. In fact, it’s forecast to keep pushing up to a total global spend of $6 Tn by 2021.
Users spend over 220 minutes/day touching their phones.
Users spend over 220 minutes/day touching their phones and of those interactions, apps dominate mobile web usage by ~85% to ~15%.
Whether it’s to share photos with friends…
Minimum Viable Product — We dreamt big and our imaginations took us to an ambitious project. We’re confident. We believe in our abilities and we work with some smart people. We all want to shoot for the stars so why should we do the least we can get away with?
There’s a rumour going around that developing towards an MVP is doing the least possible work to satisfy the customer. That means the customer is happy because they got what they asked for and the developer is happy because they didn’t lose time building features that the user didn’t want.
Can you Move Fast without Breaking Stuff?
As a Software Engineer, it’s not often you get to work on huge, Greenfield projects that will change the landscape of Financial Services for a whole region. Thanks to some forward thinking from Project Thunderbird, however, this team of devs is doing just that.
Fans of Mr. Zuckerberg will recognise the mantra “Move Fast and Break Things”. It signifies being at the cutting edge and not being put off by the fear of making mistakes.
TLDR: For a recent project, Jigsaw XYZ started using Cucumber and Gherkin to allow us to write more explanatory Feature Tests without repetition. It’s working really nicely so we wanted to share some of the thinking.
Before you go any further, this post assumes you know the basics of Cucumber testing. If you don’t, have a look at their docs, here.
At Jigsaw, we’ve long designed and developed software with London School TDD principles in mind. Recently, however, we tried out the Cucumber’s Behaviour Driven testing framework because of the verbose syntax. Cucumber uses plain-text specifications with spoken-language “Gherkin” syntax…
So I guess I should start by introducing myself…
My linkedin profile says, “I’m a Full-Stack Software Engineer and former British Army Officer with 11yrs experience in leadership, business analytics and web-development. My broader experience has helped me shape the direction of an Agile business from an objective, technical viewpoint.”
What that really means is that over the last decade I’ve seen the world from a multitude of viewpoints; from conflict resolution and combat leadership, through the corporate sales in investment banking, to a software development bootcamp and at a nimble technology startup. …