Softwire Blog
We’re 14th Best Small Company to work for!
25 February 2016, by Amy Wood
Softwire are pleased to announce that for the 6th year running we’ve placed in the top 25 on the Sunday Times’ Best Small Companies to Work for list. Having surveyed all of our wonderful staff about what it’s like to work at Softwire we came in the 14th this year, placing even higher than last year.
Softwire have always aimed to create a great place to work, this is all part of showing our staff that they are valued and giving them the room to grow and flourish in their careers. We’re very proud of this, so we thought we’d share just some of the reasons why it’s so great working here;
‘I like working at Softwire because of the culture. Being surrounded by motivated people who are keen to write good code, deliver good results, help each other out and have fun doing so makes Softwire a fantastic place to work.’
Rob P – Developer
‘I like the fact that I can count my colleagues as friends, that I’m trusted to do my work without someone peering over my shoulder constantly and that my boss actually cares about my wellbeing.’
Ellie – Office Manager
‘I like being pushed to be the best that I can. There are lots of opportunities to try new and challenging things but with people who will support you if you get out of your depth. I get lots of head-hunters approach me through LinkedIn and they can never seem to understand that I value the company atmosphere more than a 6 figure salary. I really like it here, and I’m paid well, so why would I leave?’
Chris A – Developer
‘I love the opportunity to work on interesting, challenging problems that I haven’t already solved many times before. I like working with people who are real experts. I like the trust that lets me accomplish things in a way that works for me, including the lack of clock-watching.’
Alex W – Head of Project Delivery
‘I think primarily because my contribution is respected – I’m rewarded for good work and given help to do better when I’m finding things tricky. Managers here both listen and take action to change things when they need changing.’
Jenny – Tester
So as you can see there are plenty of reasons why we’ve placed 14th and we’re very chuffed, but that’s not the most important thing here we’re most happy that our staff are happy. The happier they are, the longer we get to keep them and see them flourish!
Tips for managing technical people – Insist on an explanation
24 February 2016, by Zoe Cunningham
The following is an excerpt from my new book, “Galvanizing the Geeks – Tips for Managing Technical People”. You can buy the full book on my website, here.
In Respect your team, I talked about why you need to give clear explanations to your team in order to increase buy-in and, of course, to show that you respect your team enough to let them in on your decision-making. One great advantage of this is that, if you are in the habit of giving explanations, you are also in a position to demand them when you are unsure about exactly why something has to be a certain way, or why it should take so long.
As a manager, who probably doesn’t often have the time to go into the detail, you need to be able to assess proposals and plans at a high level. Some transactions can just be done on trust: with your longest serving managers, you can get to a situation where they have such a history of delivering on time that you can let them put together plans and simply look at whether the cost works for you or not. Even then, there may be times where you need to clarify exact approaches or establish why a certain approach doesn’t work.
You should develop a healthy suspicion of being given the ‘right’ answer. If you get the answer that you expected (or were hoping for), it might be that everything is tripping along swimmingly – or it might be that this is the obvious answer to stop you enquiring further. It could also be that, in your rush to assume that there are no crises for you, you don’t hear the substance of what is being said and interpret the answer according to your own expectations. It’s too easy to hope for and assume the best. Look for further details and reasons to ensure that you’re not being misled (accidentally or deliberately).
If you’re uncertain of something, blind trust is not the answer. Good, challenging questions and a culture of explaining what you’re doing and why will help you to get to the best answers.
Lightning Talks – Langton’s Ant
18 February 2016, by David Simons
In October 2015 we ran another Lightning Talks competition where eight employees each had five minutes to tell us something they find interesting – inside or outside the software development world. We had talks this year on topics from Security to Simulating the Sky!
Once again we voted on our favourite talks and the top two won Amazon vouchers. This is Rupert McKay’s winning talk about the cellular automata and Langton’s Ant!
Encouraging women in(to) technology
16 February 2016, by Jenny Mulholland
Following on from our managing director Zoe Cunningham’s blog post on getting more women into technology, I thought I’d share some of my own recent experiences around encouraging women in, and into, technology.
CSR at Softwire in 2015
11 February 2016, by Jiang Yingxin
Last year, we wrote a blog post listing our CSR goals for 2015. Here’s how we did against them:
Educational outreach
- We worked with lots of young people last year through events that we’ve already blogged about, such as Code Club, Code Club Pro, Young Rewired State and Tech City Stars.
- In the summer we also hosted 5 work experience students from the Social Mobility Foundation. This is the second time we’ve done this, and we hope to continue with it!
- Through Stemettes, a group of 20 schoolgirls enjoyed a day trip to our offices where they learned to make a simple app. We introduced them specially to some of our female developers and project managers, and of course our MD Zoe. We hope some of them will be inspired to go into STEM careers!
Raising money
- Our sponsorship of the village of Bonkron, through Ashanti Development, has been a great success. They’re now relatively well off and can continue to develop on their own, so we plan to find another village in the same region to support.
- We raised £24,500 through Charity Saturday, just short of our goal of £25,000 but still a figure we are very proud of.
- Over 10% of our employees have signed up to payroll giving and we’re on track for the Payroll Giving Gold award.
- In total, we raised £30,800 for charity in 2015, and Softwire donated a further £4,000 through our matching scheme. The money went to charities including Ashanti Development, MIND, Broken Rainbow, Giving What We Can, Home-Start, Shelter and Schistosomiasis Control Initiative.
Using our skills
- Zoe became a trustee of Ashanti Development this year. She’s helping to ensure the charity is fulfilling its objectives and making the best decisions, using skills she’s developed in her role leading Softwire as Managing Director.
- Our contribution to 24 Pull Requests was an unprecedented success this Christmas – we came in 4th place overall!
- In Bristol, we’ve been supporting Baby Bank Network with a day a month of technical assistance.
Ensure ToDos get ToDone
10 February 2016, by Chris Arnott
It is very common to write ToDos in code. This makes sense. You’re working on a piece of functionality and suddenly remember something relevant, but slightly off topic, which needs to be done. So you add a ToDo. Brilliant, you’ve successfully not shaved any yaks.
But when will you actually get around to finishing off the ToDo? How urgent is it? Will you remember that the ToDo is there when you do get around to implementing that extra functionality?
A War on State
3 February 2016, by James Griffiths
Here at Softwire, we’ve been busy building a mobile app for a chain of health clubs, and this is the final post in a four-part series about our experience and what we’ve learned.
We’ve chosen to build the app using Apache Cordova, so our code can easily run on both iOS and Android platforms. Take a look at the first post to read about what Cordova is, the second to see some of the practices we use to make Cordova feel as app-like as possible, and the third to see how we keep our transitions smooth in KnockoutJS.
In the nearly 16 years we’ve been around, we’ve supported many customers’ projects – including maintaining and supporting this customer’s pre-existing web application, which allows users to book exercise classes and tennis courts. All this has given us great insights into what makes software easy or difficult to maintain.
One of the major causes of difficulties in the old website, and elsewhere, is unnecessary state.
As you browse the website, the site builds up a large collection of state about your visit, which it then uses to work out what should be displayed on each page. This means if we find a bug it can be quite time-consuming to work out where each piece of state was originally set, and how the various pieces of state interact.
For the mobile app, we definitely didn’t want to repeat this mistake. We decided to declare war on state and to focus within this project on making the app as stateless as possible, so it was easy to reason about, understand, and maintain in future.
What did this mean for us?
There’s an API for that
To start with, we decided that the app should communicate with the back-end booking system using a stateless RESTful API.
Each API request that the app makes contains all information that the API needs to complete the request, meaning that the API doesn’t need to remember details of any previous requests.
This makes testing significantly easier, as the back-end API can now be tested separately from the app. Debugging is also much easier, as the isolated requests make it clear whether a bug is caused by the app, or the API.
Let’s go on a journey
The design of the UI in our app is reasonably complex; it’s built from hundreds of moving parts, each of which can change depending on the state of the user’s booking.
To reduce the amount of common state that we have to deal with we’ve divided the UI of our app into 3 ‘journeys’, each of 4 separate pages. Each journey is responsible for the flow between various pages, and the interactions between the pages required to make this work. Each page is then responsible for the details of a specific part of that journey.
These are represented by ‘journey’ and ‘page’ view-model objects within our code; any state relating to how the journey and pages are displayed is stored on these objects. Each time the user starts a journey, we create a new instance of the journey and page objects, and when the user leaves a journey, we destroy the journey and page objects. This ensures the journey and pages never contain state left over from a previous visit.
On a strictly need-to-know basis
In the old website a great deal of information was passed between pages, including large, complex object models, dramatically increasing the complexity of the codebase, and making it hard to tell where any information came from.
For the mobile app we have taken the opposite approach and pass around as little information between pages as possible, usually just a single ID, e.g. the ID of the exercise class being booked, or the ID of the booking.
We’re using the repository pattern throughout to enable this. We have a set of repositories in our javascript code which load data and manage internal caches using HTML5 local storage, and we’re then able to get away with just passing IDs between pages, because we know the next page will be able to load any information it needs from the repositories at very little cost.
If it breaks, turn it off and on again
Within our app we’re using quite a few fancy UI widgets. One of them – a swipeable carousel of dates – doesn’t play very nicely with Knockout: every time we change the list of available dates, the widget re-draws the carousel vertically, rather than horizontally! Clearly this widget isn’t stateless, sadly, as it’s appearance isn’t just a function of its inputs, but is also affected by its previous state.
We spent a while trying to fix this in the widget itself, but to no avail. Fortunately, we then thought of another approach: instead of changing the list of dates, simple destroy the old widget and create a new instance with the new set of dates, which worked a treat.
This change essentially makes the widget stateless, from our point of view, by destroying and rebuilding it at any time when the state might change, so that the widget’s appearance is instead based only on its current inputs. When statelessness gets difficult frequently and pre-emptively “turning it off and on again” can actually get you remarkably close!