Softwire Blog
What’s keeping voting from moving online?
6 May 2017, by Francine Barsam
With the general election swiftly approaching, conversation in the office this week turned to why we’re still unable to vote online and what might have to change in order to make voting online a possibility.
The first and probably most obvious argument against online voting is security of the system. In a year of particularly prominent news relating to online security breaches and cyber-attacks, such as the recent attack on the NHS, it’s only too clear that the internet isn’t exactly the safest of places. Moving voting online opens it up to many potential problems, not least from external groups but even from the people who might take responsibility for building the systems by which we could vote online. Simply, it would be too difficult to find a totally impartial party to create a voting system. Regardless of whether a company had any political affiliations or motivations, it would be nigh on impossible to put together a team of developers who had no political leanings of their own.
And if it’s not possible to impartially build a voting system then, it’s difficult to expect the public to put their trust in the system and believe that their vote will be accurately counted and untampered with. Trials of electronic voting machines in the past have already flagged various problems, including demonstrations of the ability to alter the software they run on with just 60 seconds and a USB stick. Creating a voting system where anyone could simply vote from their desk at work or their smartphone would throw the net wide open to all manner of threats. There’s no simple way that the public could be shown that their votes had been counted and communicated accurately.
Convenience would be the most cited reason for allowing voting to take place over the internet, but one could argue that the fact that people have to make the effort to go and vote means that only those that have a real interest in the outcome of the election are likely to bother voting. Online voting would be open to manipulation on a large scale, but also due to convenience, it could be quite easy to persuade someone who wasn’t planning to vote to let someone else use their vote. By making voting so convenient, votes could end up being traded for something so minimal as a cup of coffee or a sandwich. Postal voting lessens the likelihood of such simple manipulation taking place.
It doesn’t seem that online voting is something that will happen anytime in the foreseeable future and with the majority of the kinks having been ironed out of the current paper voting system, other than convenience for both the voter and the people responsible for counting the votes, there’s no great argument that online voting would improve anything other than voter turnout. It would however be interesting to see online voting tested parallel to a paper vote to test the increase in turnout, but until an online vote is counted as relevant it wouldn’t be open to the genuine threats that online voting is so exposed to. Essentially, even testing an electronic system alongside the current system would simply be likened to an elaborate exit poll at best. So for now at least, it looks like we’ll be sticking to paper and pencil.
Coaching open source contributions with Codebar
20 June 2017, by Suzanne Hamilton
Codebar are an organisation that run weekly events to help get people from groups who are underrepresented in tech into coding. And for the past two years they and Ladies of Code have jointly run a day-long workshop in December as part of 24 Pull Requests, where more experienced devs volunteer to help people to make their first open source contribution.
Photo by @codebar
I coached at the 2015 event, which was a lot of fun. For 2016, Softwire also sponsored the event as part of our drive to support diversity in tech, so as well as coaching, I got to tell a diverse audience of people about why they should apply to Softwire!
There were several lightning talks about open source during the day, including ones from Andrew Nesbitt (who started 24 PR) and Charlotte Spencer (who runs @yourfirstpr).
But most of the day was spent coding. In the morning, the coaches were paired up with students according to what languages we knew or wanted to work with. JavaScript was by far the most popular, with a few people using Ruby or Python, and one person who wanted to write some Java.
I paired with Anna and Bybreen, who were just starting out with learning HTML and CSS. Git was the steepest learning curve, because neither of them had used it before, so we started out using the GitHub desktop client to make things a bit less intimidating.
Photo by @binusida
It was quite tricky to find issues to work on (which is one of the hardest things about 24 Pull Requests in general), but someone suggested taking a few open issues on Prepare to Code, a website which provides beginners’ guides for setting up different kinds of dev environments. The issues were just typos and broken links, but it was perfect for us because there was no dev environment to set up. Once they’d got into the swing of things, I hunted around for more things that they could fix on the same site. Hooray for buggy code!Between them, they made six pull requests, which is pretty impressive for people who were completely new to git. And we hit the 24 pull requests goal as a group.The day wound down with some drinks and a group chat about the things we’d been working on and what we’d learned.It was a really good day. Everyone there was so enthusiastic about learning or teaching (or both), and it was great to be able to help people see open source (and coding in general) as more approachable.
Volunteering at the Full Fact hackday
13 June 2017, by Michael Kearns
Full Fact are a British independent factchecking charity who check claims made in the press, in parliament and in televised debates (e.g. Question Time). They’re currently in the process of implementing tools to enable automated factchecking (note that they’re not looking to do this in a machine-learning sense of “automated”, but mainly building tools to enable humans to check facts significantly faster).
They recently ran a hackday for the first time, which I volunteered at. They had a few problems which they wanted to tackle via the hackday:
- Wrapping a reverse-search library in a service, so that they can integrate it with their systems (and use it without learning Java, they mainly use Python)
- Implementing a way of finding claims of the form “X is rising” (e.g. “GDP increased by 5%”)
- Implementing a way of canonicalising numerical parts of speech (e.g. “three thousand and fifty” goes to “3050”; also needs to handle things like “few thousand”) so that claims made e.g. in Parliament are in a suitable format to potentially be automatically checked against an appropriate source.
I ended up volunteering for the first task, which in retrospect was definitely the least challenging (so I didn’t learn much) but was probably where I was most useful for Full Fact.
The hackday had quite a wide range of participants, from committers to apache-solr to developers inexperienced with the Solr, along with a special guest representative from the Argentinian fact-checking organisation Chequeado. Good progress was made on all three tasks, although I definitely feel there was a case of too many cooks on our task, along with some various set-up issues which caused the day to be quite inefficient for some volunteers (Java versions, IDE issues etc.)
I gave them feedback on these issues – this was the first hackday Full Fact have run, and they’re now looking to make use of everything that’s come out of it before coming up with lots more problems they need help solving for (potentially) a next one!
Softwire’s Inaugural Charity Auction
6 June 2017, by Laura Bethke
In March, we held a new big fundraising event at Softwire: our first ever charity auction.
The idea was born in a CSR meeting where we were brainstorming ideas for fundraising, and our director Phil and I (a developer) were both very keen to organise this.
We wanted to get donations from lots of different sources: clients, local businesses and employees. As we are a Software company, few of our clients have products that are suitable to be auctioned off, but we managed to get a very generous donation from David Lloyd and also a lot of tasty donations from our various kitchen suppliers.
To get local businesses involved, we sent small teams out to various streets around Highgate Studios, to speak to business owners and see whether they’d like to contribute. I was overwhelmed by the response – we got donations from nearly 40 separate businesses, ranging from vouchers to meals to Escape Room tickets.
Finally our employees offered various promise based items. Examples include delicious cakes, a gig by our director’s cover band in your own home, our chef offering to help you prepare a gourmet dinner party and many more…
On the day of the auction, we made sure to thank all of the businesses who had contributed on our social media, and we also sent them letters after the night telling about how much we’d raised. Hopefully they’ll remember us if we decide to host a similar event in future, as the varied items they donated contributed so strongly to the success of the evening.
The night was held in our offices, for employees and friends. We had delicious food from local restaurants (who kindly gave it to us at a reduced rate as we told them about the charitable aspect) and Phil as compere. There were nearly 60 items to be auctioned off, with some smaller value ones being part of a raffle. What I had hoped to be a pleasant evening that would raise between one and two thousand pounds, turned into an extremely entertaining night which raised a staggering £5500. It turns out that the excitement and fun of bidding (a lot of it down to Phil’s excellent hosting), and the fact all the money went to a good cause, motivated people to be very generous with their bids. A highlight of the night was an item offered by Softwire itself – the right to name a new meeting room. There was a fierce battle between the football and Smash factions, that was ultimately won by the latter – who paid a mind-boggling £1,300 pounds to be proud room parents.
Because of Softwire’s generous policy of matching certain fundraising events, the total amount donates was actually doubled to more than £11,000 in total. The money was split between Ashanti Development and Home-Start Camden, two charities we at Softwire feel very passionately about.
The night was a tremendous success and also a lot of fun, but also a big organisational challenge. I do hope we can repeat it at some point in future though – and who knows, we might raise even more.
The power of play at work
1 June 2017, by Karl Graham
What if you worked in a place where you are not only allowed to play, but encouraged. It’s a trend that’s emerging in many organisations, especially amongst technology and start-up businesses. High profile examples include Google, Pixar and IDEO. More importantly, they instil a culture of play – not as a distraction from work, but as a benefit to it. For years the worlds of work and play have been seen as separate and distinct; that play is inferior and takes away from ‘real work.’ In fact, many of us have been taught to think of play in the work place as inappropriate and a waste of time.
What if play at work is really a benefit? Let’s be realistic. People get bored. People get distracted. People get frustrated. It happens! Whether it’s just the monotony of routine tasks that demand our attention, or the root of a thorny problem. What employers want is a more positive, energized problem solving workforce. Employees want to enjoy their work, and have permission to do it. Wouldn’t it be great if all employees were having fun while at work?
Helpguide.org in collaboration with Harvard Health Publications have said, “Success at work doesn’t depend on the amount of time you work; it depends upon the quality of your work. And the quality of your work is highly dependent on your well-being.
“Taking the time to replenish yourself through play is one of the best things you can do for your career. When the project you’re working on hits a serious glitch, take some time out to play and have a few laughs. Taking a pause for play does a lot more than take your mind off the problem. When you play, you engage the creative side of your brain and silence your “inner editor,” that psychological barrier that censors your thoughts and ideas. This can often help you see the problem in a new light and think up fresh, creative solutions.”[i]
Other research indicates that play can decrease stress and absenteeism. As employees make time to play, it lessens work related stress. This leads to less sickness absence. On the other side of the coin, it also leads to a more positive attitude and more energized work environment.
Allowing play in the workplace is good for business and employees. The opportunity to play shows employees they’re valued. Employees are therefore more likely to be engaged, collaborative, creative and focused. All better outcomes for the employer. A natural follow-on is that employees are likely to experience more job satisfaction. As Forbes reported, “Last year revenues increased by an average of 22.2 percent for the 2014 Fortune 100 Best Companies to Work For.”[ii]
Isn’t it about time your staff starting playing?
[i] https://www.helpguide.org/articles/emotional-health/benefits-of-play-for-adults.htm
[ii] https://www.forbes.com/sites/meghanbiro/2014/01/19/happy-employees-hefty-profits/#fa9903b221a8
Why enterprises can be disrupted
25 May 2017, by Andy Patterson
Software engineering is the foundation that allows new consumer services, efficient back-office systems, and market-disrupting products to be created. As with all foundations, it’s important to get the basic principles correct, and we believe that these principals are not only technical but creative. There are so many possible implementations of software applications that an environment which stimulates creative and innovative solutions will deliver the best results.
If we start with the humble software engineer, we can look at what motivates them to do their job effectively and create software to make a difference. A large body of research exists (summarised neatly in Drive[2]) to demonstrate that extrinsic motivators (reward and punishment) work well for simple rule-based tasks, but work very poorly for creative or complex tasks. For these types of task, we can measure the presence (or lack of) three types of intrinsic motivation:
- Autonomy: the urge and capability to direct our own work and make our own decisions
- Mastery: the desire to master our tools and improve our skills
- Purpose: the need to do something with meaning, and with clear direction
These motivators provide us with a language to discuss how to create an environment that is productive and efficient, producing brilliant software; conversely, it provides terms to explain why companies can have environments that are stagnant and inefficient, leading to software that no one wants to use.
Autonomy
We start with the hardest motivator: autonomy. It might seem confusing that autonomy is important – isn’t the job of a software engineer to implement something that the business has decided is necessary? Allowing engineers to dictate their own workloads is only a single example of autonomy (and, incidentally, one that Google and others have used to great effect[3]). Indeed, most engineers are happy to admit that UX or business analysis are not their areas of expertise. However, autonomy is much deeper than this – it’s about giving engineer the freedom to decide how to implement what’s required (what processes or frameworks to use), and the responsibility for delivering working software to end users. Teams with high autonomy are more efficient, as they’re empowered to remove processes that slow development effort down, and free to adopt better tools or frameworks as they become available.
One of the reasons that agile practices (and by extension, practices like Continuous Delivery and DevOps) have been so successful is that they push autonomy down to the team level, focus on cross-functional teams, and encourage continuous change. This isn’t to say that agile methods such as scrum or kanban are the only methods for achieving autonomy: they’re just a particularly well-known and effective one.
Mastery
For software engineers, mastery of a toolset, skill, or framework is immensely satisfying. However, Mastery is more than perfecting one skill: it’s heavily reliant on continuous improvement. It should be obvious that technology is a rapidly-changing industry, and that adopting new tools and skills as they become available is the key to success.
Mastery of technical improvements
By now, the analogy of technical debt[4] is well known and addresses one aspect of mastery (the desire to improve the code being worked on). Long-running codebases with low technical debt are strongly correlated with products that are reliable, high-quality, and respond predictably to change requests – Google is an excellent example of a company that invests heavily in reducing debt[5]. However, technical debt is an imperfect analogy as it is unquantifiable, and must be measured by its side effects: slow, unreliable delivery, and disenfranchised, unmotivated developers. Business that focus solely on putting features in front of customers win in the short term, but over the long term incur sufficient debt that delivering even simple features takes a huge effort.
Mastery of personal development
While developers will generally self-improve over time, this can be greatly accelerated with the right support and processes, including formal and informal training. These two approaches differ in what they aim to achieve, and personal development is normally most effective when they’re combined. Training courses and conferences aim to teach a specific skill, or give a breadth of knowledge about the industry. They also provide opportunities to network and engage with companies working on similar problems. By contrast, coaching and mentoring are much more individual, helping developers improve their strengths and mitigate weaknesses. These approaches can deliver huge benefits to teams and organisations:
- Ensuring that knowledge is spread across the team, removing single points of failure and improving consistency
- Improving skills and abilities
- Allowing individuals to take on more responsibility, resulting in more capable teams
The rate at which software development changes is phenomenal; the tools and technologies for most new projects have changed in the last 5 years, and are radically different to those 10 years ago. The NodeJs ecosystem is the canonical example; just over 5 years old, NodeJs and npm now have over 4 million active developers, and are used by thousands of companies.
Mastery deals less with each individual change, and is more concerned with the process of adapting to changes over time. It’s important to determine where best to invest in changing technology, but as we saw from autonomy, the correct place to make this decision is within an engineering team.
Purpose
Given that most software engineering is product or service-focussed, providing a clear backlog and direction of work gives a purpose to both individual and team efforts. In addition, a frequent and well-defined release schedule provides a visible goal to focus on. A purpose can be highly effective when combined with the goals of Mastery; to not only deliver software, but to get better at the process of delivering software. Teams with a strong sense of purpose are more likely to succeed, and less likely to get distracted and solve unrelated problems.
Scaling and disruption
Autonomy, mastery, and purpose are useful tools as they allow us to examine teams (or individuals) separately, and suggest targeted improvements. Some teams may have a strong sense of purpose, but are held back by poor tooling, whereas other teams may be able to make wide-reaching decisions but lack a clear goal. The ability to address the needs of each team in isolation allows this approach to scale. There are obvious technical challenges with scaling development work across multiple teams (particularly communication overhead made famous by the Mythical Man Month), but teams that are motivated to succeed will overcome these problems for themselves.
Looking at the world through the lens of intrinsic motivation it’s possible to see why a startup can deliver a disruptive product, but an industry behemoth can struggle to update its flagship products and services. The startup’s developers have autonomy (freedom from constraining structure and processes), mastery (time and money to improve skills and tooling), and purpose (the vision of the startup). Large organisations can be disruptive – Apple, Amazon, and Google regularly deliver ground-breaking products – but to do so requires continual effort and focus.
[1] The perils of ignoring software development: http://www.mckinsey.com/industries/high-tech/our-insights/the-perils-of-ignoring-software-development
[2] Drive: the surprising truth about what motivates us: http://www.worldcat.org/title/drive-the-surprising-truth-about-what-motivates-us/oclc/311778265
[3] Google’s “20 percent time” in action: https://googleblog.blogspot.co.uk/2006/05/googles-20-percent-time-in-action.html
[4] TechnicalDebt: http://martinfowler.com/bliki/TechnicalDebt.html
[5] Searching for Build Debt http://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/37755.pdf
Alexa is the new command line
19 May 2017, by Andy Patterson
In the beginning, man created the command line interface, and lo! There were commands that no-one could remember, and syntax designed by Satan himself.
User interface experts call this problem discoverability; given that you’re at a particular point in an application, how do you find where you can go next, or what you can do? The early graphical user interfaces beat the more-powerful command line because they allowed users to discover features without needing to remember that a feature was there. This property turns out to be so compelling that command lines were relegated to, well, somewhere that you can discover with a bit of digging.
The unchallenged dominance of the graphical user interface is facing a new contender: voice-activated assistants, such as Siri, Alexa, and Google Assistant. These ever-listening devices attack the soft underbelly of the graphical user interface; the (non-alternative) fact that you need a graphical screen to interact with them, and you need to be within touching distance of that screen. With voice-activated assistants, you only need to be in yelling distance (or have your phone nearby).
Once you’ve vocally activated your assistant, you need to give it commands. One of the hard problems with this, and with life in general, is that different people ask questions in different ways. Where you’ll say “Alexa, what time is it?”, I’ll proclaim “Alexa, what be the hour?”. Internally, the servers powering Alexa need to figure out that we’re asking the same question, which we call disambiguation. One of the strengths of command and graphical interfaces is that input is unambiguous (yes, you really did click the “delete all my files” button). Unfortunately, disambiguation is a hard problem, even for relatively simple commands. Try adding “fork handles” to your shopping list to discover this for yourself.
If we can make the simplifying assumption that we’ve solved the above problem, we’ve just discovered a deeper problem; how do you do discoverability on a voice assistant? “Siri, tell me everything you can do” is likely to flatten your phone battery pretty quickly (which I don’t believe is an intended feature of Siri), nor does it help you decide if Siri can order you a late-night Chimichanga delivery. At the moment, this isn’t really a problem because voice assistants are very limited in what they can achieve. Alexa is about to run face-first into this problem with the addition of Traits. Given two Alexa devices with Traits, there’s no way to tell which Traits are available. Without a good solution to the discoverability problem (wait, you were expecting me to have one?), voice assistants will be limited to simple commands and instructions.
An interesting property of command lines that hasn’t featured in voice assistants yet is that of composition (i.e. can I chain the output of multiple commands together?). We even have this concept in the graphical world – the humble copy-paste allows us to move data from one program to another with only a modicum of mouse-pointer shuffling. Telling Siri to “email the news story about the giraffe to my mother” could lead to some unexpected (but possibly hilarious) results. Which is a pity, because composition is incredibly powerful, and we really ought to continue making it available.
Is the end nigh for our mellifluous Alexa? It seems unlikely; convenience outweighs theoretical concerns, and there are some genuine good uses as well as novelties and party tricks. Only time will tell. If we can figure out how to ask for it, anyway.
Being a good ally
10 May 2017, by Helen Hosein
The technology industry is notoriously bad at embracing diversity. Almost everyone acknowledges the problem, but a lot of folks don’t know where to start. As a non-binary person of colour who’s worked in technology for their entire career, I’ve seen and experienced a lot of things that I think could be better. Here at Softwire, my colleagues often ask me what they can do to help. This is where allyship becomes important – to amplify our voices and help make the technology industry (and the world!) a more equal place.
Who can be an ally?
Anyone can be an ally! It doesn’t matter what your own background is, or how you identify. Even if you’re going through your own struggle, you can still be an ally to someone whose struggle may be slightly different than yours. If you don’t think that applies to you, that’s ok too – there’s no need to feel guilty about privilege. What we call privilege may just mean that there are more ways that you can help out.
A good ally isn’t a perfect human being either – we’re all flawed, and we all carry our own biases. Part of allyship is educating yourself and working to overcome yours.
What do I have to do?
I can’t speak for all marginalised folks (nor would I want to!) but here are three steps that I’d suggest to get you started.
Step 1: Talk to us
Ask your friends and colleagues what it’s like for them (understand, though, that sometimes talking about it is hard, so be patient). You may already have done some reading up, which is awesome, but don’t assume that you already know what your friend’s or colleague’s experience is like. Everyone’s experience is different. Your friend may have a very different experience from someone you’ve read about, or someone you’ve talked to in the past. The more you talk to us, and listen with humility and an open mind, the more you learn about us as individuals and as a group.
Step 2: Believe us
When you talk to us, some of what you hear may surprise you! It’s easy to imagine that our negative experiences are rare, not only because you may not experience them yourself, but also because you may not hear about them. For a person who feels marginalised, it can be embarrassing, or worse, frightening, to face the prospect of coming forward. In some cases, they may feel personally threatened.
Those who do speak out usually feel more comfortable doing so among other members of their group – they know these are people who will understand. If you’re not a member of that particular group, you may never get to hear those stories. That makes it all the more important, when someone does make the leap of faith to confide in you, that you believe everything they say. By believing them, you demonstrate that it’s safe to come talk to you about their experiences.
Step 3: Support us
Get involved! There are loads of ways to help support marginalised and underrepresented folks in the technology industry. You can lend your skills at events like codebar, support inclusive events like AlterConf or Diversity in Tech, sign the Minimum Viable Diversity Pledge, or do lots more stuff like those.
Don’t neglect the people you already know, as well. If you’re managing someone who may be from a marginalised group, check in on them. If there’s something they’ve asked for in your 1:1s, make sure you follow through.
Most of all, make sure you give us space to be heard, and back us up when we need it.
What’s next?
Remember that “ally” is not just a noun, it’s also a verb, so make sure you do the work to help out. This article is just a starting point; there are a lot more useful resources out there when you’re ready to take your journey as an ally further. The job is never done – there’s always more to learn, and more to do, so keep working at it!
What I did on my volunteering day – Jake
19 April 2017, by Jake McKenna
Recently I went and volunteered at Cambridge City Food Bank, an organisation that helps provide emergency food to local people in crisis. They’re an entirely volunteer-run organisation that mostly relies on donations of food by the public. They work on a referrals basis, so not just anyone can turn up and ask for some food (which makes sense, but I hadn’t thought of it before), and they also sometimes provide other help, such as tokens/vouchers for top-up energy meters.
I was working at their office/warehouse and got shown around. This is their main sorting area, where all the donations they collect get weighed and categorized:
After this, the volunteers create boxes containing set amounts of various things for a set amount of people – this is a box for 3/4 people for a few days of food:
The boxes then get sent out to the various distribution points for pickup.
What I was actually doing was somewhat unrelated. The problem they had was that their accounting system for donations was set up slightly strangely – they were using what I think is double-entry accounting, where they were recording both an invoice and a payment for donations, which got slightly strange when they forgot to enter the invoice and the month rolled over, or something like that. So what I was tasked to do was to convert all the Invoice-Payment pairs into Sales Receipts in their Quickbooks accounting system. Sounds like something you could script, but there didn’t seem any easy way to do it, and there were quite a few edge-cases, so I ended up just doing a lot of copying and pasting.
Some interesting things I learned:
- People are selective in what food they donate – e.g. they are often short of sugar because people think ‘that’s bad’, but people still need sugar!
- Food bank usage is probably not growing as fast as the leftist media would suggest but is growing.
Payroll giving
3 April 2017, by Jiang Yingxin
One of the many perks we get at Softwire is access to a Payroll Giving scheme, which makes it easier than ever to support your favourite charities. Signing up to a payroll giving scheme has the following benefits:
- The money comes out of your pay before you see it, which makes it tax-efficient and also psychologically easier to donate more and continue to donate for many years.
- It’s charities’ preferred method of receiving donations, as it reduces the admin overhead of e.g. reclaiming Gift Aid.
- It’s really easy to set up.
Last year, we took the time to publicise our payroll giving scheme more internally, and found a simple but effective way to reduce the barriers to entry still further: a number of my colleagues volunteered to go round to the desks of people interested in the scheme and take them through the sign-up process. And if it was after working hours, they would even bring a couple of beers along. This led to a doubling in uptake of the scheme, and we got 20% of our employees signed up in time for the Payroll Giving Awards 2016, which we think is fantastic! We are therefore proud to display our “PGA Gold Award”.
12 months on, we now still have over 20% of employees signed up to payroll giving, and we’re gunning for the Platinum Award this year.
If you were thinking of setting up payroll giving at your workplace, or joining your existing scheme, please do read the testimonials below for more inspiration, or feel free to contact us for practical help.
Rich C:
I signed up with Tom after the company meeting. It was really simple to do, I think it took less than 10 minutes. I had some direct debits set up to some charities anyway and so I have simply transferred these into Payroll Giving so that the Gift Aid is taken care of and I can easily manage them online. The main problem I had was finally getting round to doing it – scheduling a time with Tom to sit down get it done really helped me, maybe I just need a lot of nagging to get stuff done though!
Tom E:
I started payroll giving fairly soon after joining Softwire, at the same time as I signed up for the Giving What We Can pledge. I find payroll giving a very easy way to give money both practically and psychologically – there’s no need to think about Gift Aid, and because the money never arrives in my account it doesn’t feel like I’m losing it. Sign-up is simple, and there’s no ongoing admin.
Zoe:
I’ve been doing payroll giving for quite a while now. I started when I realised that we were collecting large capital sums to support a village in Ashanti, and then incurring ongoing costs – for example the hardship fund. I liked the idea that if enough of us put in £10/month we could have an ongoing fund that would work a bit like taxes and provide ongoing support to the village. It was much easier to set up than I thought – I just filled in a form and now it goes out every month without my thinking about it.