We're Hiring!

Introduction

Foreword #

Software-driven companies are the future.

Like the industrial revolution did, the information revolution is rapidly changing the entire business landscape. Hardware continues to become a commodity. Workers are increasingly interconnected and asynchronous. Machine Learning and AI hold vast possibilities. Software is becoming ever more important to the everyday process of business. Companies that do not embrace software as a truly core part of their solutions will eventually fall behind.

But, software, like the industrial machines that came before it, is only a tool. We understand that. Companies are looking to solve a problem. They are driven by people and processes. Thus, it is vital to get the right tool for the right reasons, and to enable it to work in harmony with these people and processes.

As companies tend to engage in very specific practices, half of the challenge of delivering value through software is understanding the underlying business needs, customers and market it operates in.

We put this process right at the core of our company. Many software companies get caught up on technology itself or a checklist of features rather than striving to genuinely understand the underlying business needs. The clear majority of customers are great at identifying their problems and explaining it within the context of their own industry, but they need support establishing digital strategies to solve these problems and achieve their goals. By guiding our customers, we help them avoid spending time and resources on building and buying the wrong things for the wrong reasons.

Our goal is always to help our customers get closer to becoming truly software-driven.

We define a software driven company as:

  1. The company’s software adds significant, tangible value.
  2. They are perpetually improving their solutions, and software is an intrinsic cost of staying competitive.
  3. Software is used to help abstract away anything not in the company’s core goal, and to deliver their core goal more effectively.

So, our ideology goes far beyond the bounds of simply building and selling software and services. It treats software as a small, but powerful part of a larger picture. By taking on this point of view it helps our customers and Purepoint truly understand each other and deliver value far into the future.

On delivering value #

We pride ourselves on not having a traditional sales team and on having long-lasting, friendly relationships with our customers.

There are many ways to grow a company. Although we try to be atypical in many regards, we are not atypical in our desire to grow as a company. Early on, we decided that growth within our industry is not best achieved by simply cramming as many opportunities as we can into the top of a sales funnel. We want to grow sustainably and always be delivering value to our customers. A relentless, customer-centric approach will ultimately generate value for our own company in the long run.

We have no external investors and are fully independent. This means there is no need to lubricate the cogs of the investment hype machine in preparation for “the next round”, or deliver results quarter-by-quarter. Instead, we care about long-term value and sustainability.

The purpose of the Blueprint #

Putting our ethos, methods, processes and views into text solidifies them. The Blueprint can be a go-to reference for anyone who comes into contact with Purepoint. It pulls back the veil, revealing our day-to-day.

Companies can be viewed as people who are grouped together to achieve a common goal. People change, adapt, come, and go (though we hope the latter is a rare occurrence!). So, over the years, values and outlooks change too. Our aim is to have an ever-evolving Blueprint which reflects our present-day dynamic.

This guide is written to be as human readable as possible. We hope that both customers and our own team find value within the Blueprint.

The Blueprint is not really meant to be a start-to-finish read, but rather a reference that can be dipped in and out of.

Purepoint: Culture

Purepoint’s principles #

1. Understand you

Every business has their own personality. Their own challenges. We understand software is just a tool – a means to an end. We build business solutions, but to do that we first have to deeply understand your unique needs and processes.

2. Solve problems for people

All organisations are about people at their core – from their customers to their suppliers and staff. So, people are at the centre of every solution we build. Getting stakeholder buy-in and users engaged is pivotal to software success.

3. Deliver solutions that last

Solutions should stand the test of time. We achieve this with simplicity, support, training and documentation. Software changes fast, but a good solution should transcend trends and stay nimble and adaptable.

4. Hire only the exeptional

Software powers the world and has the power to make or break entire projects and organisations. We leave nothing to chance, and that starts with the very first step of our recruitment process.

How we operate #

Purepoint operates in a very different way to most companies.

We’re what we like to call a ‘Cloud Company’ - remote-first and spanning 15 countries.

We’re a company of few meetings and even fewer organisational structures. Our main goal of organisational flatness is to avoid unnecessary headcount creep. If Warren Buffet can manage Berkshire Hathaway with 25 people, we can manage software projects for our customers in a similar way.

Productivity is a very personal thing. So, we do not believe that putting our team members in a room together for 40 hours per week is the best way for us to deliver value to our customers. In fact, we are big believers in Parkinson’s law:

“Work expands to fill the time available for its completion”

We follow a very different set of rules. Instead of tracking everything by the hour or day, we measure the performance indicators our customers care about; the quality and speed of our work and its direct impact upon their business. We try to let our employees act autonomously and allow them to take on responsibilities and different roles in different projects. We trust our employees; they’re the best in the industry. We let them pick their own hours, their own holidays and their own working environments. We try and understand the emotional and psychological side of teams, rather than thinking of people as ‘resources’.

For some team members, or customers, a traditional 9-5 routine based in-office still works best. But for others working from their home office in California or getting lost in the challenge of cracking a complex problem late at night is how they’re most productive.

We pride ourselves on understanding each member of our teams and using our judgement about how they are performing, improving and delivering.

Lastly, but by no means least, believe in staying lightweight and favouring automation and process wherever possible. The software market is aggressive and fast moving. As companies grow they tend to follow a similar pattern of expanding offices, new departments and more support staff. We think there are better ways to operate. With software-driven processes our teams can work asynchronously without the need for excessive overheads.

How we approach software #

Compared to many design and build practices before it (like architectural design) software changes at an alarmingly fast rate. But thankfully, the underlying practices of understanding problems and designing good solutions have much deeper roots.

The end-to-end process we go through when delivering any feature or solution can be broken down into the following 5 overarching steps:

  1. Understanding
  2. Planning
  3. Prototyping
  4. Building
  5. Delivering

It’s important to understand that in an agile process we may iterate through these steps many times as we build new features and releases. These steps aren’t something we do once for the whole project, we pass through this process continuously.

1. Understanding

📒 Jump to chapter ‘Engineering Principles’ for practical engineering information.

Understanding - Research

Understanding users is key to success. Users may not always be obvious – not all applications have a user interface, sometimes they are just invisible connections between systems. But at the end of every business goal is a user – customers, staff, stakeholders. We must understand these users and their needs in order to deliver value.

We have to understand:

  • Who the user really is
  • What they’re trying to achieve and how
  • What their current experience is
  • Their limitations and expectations User research is most effective when it’s conducted as a team activity, not just by a single researcher.

Understanding the context and business case for any system is the other key to success. Organisations are complex, fast changing structures. Many times, they are poorly understood even by the people inside them, and so initial understandings and proposed solutions may only partially address the problem, or work for limited users or stakeholders. It is impossible to develop a perfect solution, but understanding the trade-offs is vital.

We have to understand:

  • What the underlying business need is
  • What does success look like?
  • What is the ROI?
  • The current business systems and process
  • The human element, including limitations and training requirements

How we research

Good user research is about paving the way to understand what will work, rather than what is popular. It should challenge assumptions. It shouldn’t focus on technology or implementation details, rather on the fundamental problem and solutions. We have to talk to users to really understand them.

Key methods include:

  • Reviewing existing material and data
  • Talking to people organisation wide and using surveys
  • Interviewing, observing and recording existing users
  • Contextual research
  • Prototype testing and iterating

Who we talk to

User research must be inclusive. We have to consider people with disabilities, people who are less technically able, an entire range of possible devices, mediums and abilities. Services and solutions need to be universal.

How we find and target these people is entirely dependent upon the project. There is no one size fits all solution.

Recording research findings

There are many ways to record the data from user research. But unless it is recorded in a way that is easy to understand, it does not become useful information.

The important points are:

  • Research sounds natural, it is recorded in a human voice
  • Research can be tied directly to ‘user stories’ and outcomes
  • User groups are clearly understood and considered in the solution
  • People outside the team can understand the findings clearly

Understanding - Diverge

One of the key phases of understanding is to allow the team to diverge.

As data is collected, the solution can feel further away. Assumptions are broken, there may be many contradictions.

People will start forming their own ideas and solutions, which may be wildly different. During this phase this sort of thinking should be encouraged, even though it may be counterintuitive. This is a creative process. It is common for there to be a bit of friction as different ideas and understandings form.

Understanding - Converge

In the final phase of understanding, before a team can move into the planning phase, they must start to come back together and move towards a common understanding and goal.

It is not the goal to converge upon a fully specified solution at this point, rather to converge upon a common understanding of the needs, requirements and outcomes. Potential solutions should be understood, and the business trade-offs of these understood too.

2. Planning

📒 Jump to chapter ‘Planning and prototyping’ for practical engineering information.

Planning - Evaluate tools and systems

Every solution is different. Sometimes it is tempting to jump into a technology or toolset we are familiar with, or which seems will give us the fastest turnaround.

Before we can make choices about the technologies, tools and components we use we have to:

  • Understand the options, and the trade offs
  • Understand why existing choices (such as legacy systems) were made
  • Explore potential opportunities
  • Think about the future, project evolution and change

The best solution to get going quickly may not be the best solution for long term maintenance. There are no silver bullets in software, it’s always about measuring trade-offs.

When evaluating technology, be it languages, tools, platforms or components the considerations should be:

  • Be cloud first
  • Privacy and Security must be integral
  • Consider scalability
  • Consider single points of failure
  • Consider cost and ROI

Planning - Understand privacy and security issues

📒 Jump to chapter ‘Security’ for practical engineering information.

With the introduction of the GDPR user data, privacy and security are more in focus that ever before. Privacy and security shouldn’t be afterthoughts or a box checking exercise at the end of a project, they should be built right into the fabric of a solution, and often influence the solution itself.

The four key areas we focus on are:

  1. Confidentiality
  2. Integrity
  3. Availability
  4. Auditability

1. Confidentiality

Data should only be available to those parties whom it’s meant to be available to, and for a period that complies with relevant regulations and policies.

2. Integrity

Information, and the system itself should only be able to be viewed and modified by the parties authorised and intended to do so.

3. Availability

The system should be resilient. Attacks or internal problems shouldn’t restrict access to data or key functions.

4. Auditability

Nothing in the system should happen that can’t be replayed, audited and tied to a responsible party.

3. Prototyping

📒 Jump to chapter ‘Planning and prototyping’ for practical engineering information.

Prototyping - Iterate and improve frequently

📒 Jump to chapter ‘Developing’ for practical engineering information.

We believe in designing via working prototypes, rather than using static design tools. This encourages engineers to be multi-disciplinary and get involved in a hands-on manner in prototyping, learning the lessons first hand. Agile supports rapid prototyping well, because it lets us try, fail, learn and adapt in quick cycles before moving towards a final solution for a feature.

Agile is right at the heart of our prototyping and building process.

The key principles of agile delivery at Purepoint are:

  • Satisfaction through early and continuous delivery
  • Requirements evolve, but the time scale is fixed
  • Collaboration between stakeholders throughout the entire process
  • Support, trust and motivation between all involved
  • Working solutions are the primary measure of progress
  • Self-organising teams are more agile, responsive, and encourage consistent delivery
  • Simplicity & the 80/20 rule

Prototyping - Do ongoing user research

Something often forgotten in software design is the importance of continuing user research throughout development. The nature of agile means requirements change, and solutions change, so we need to continue to test and challenge our assumptions and solutions as those changes happen.

4. Building

📒 Jump to chapter ‘Developing’ for practical engineering information.

Building – Visibility

If a tree falls in a forest and no one is around to hear it, does it make a sound?

To deliver in an agile manner, and with confidence visibility throughout the project is pivotal. This means open communication channels, open access to tools and systems, accessible staging servers and document repositories.

There isn’t such a thing as too much transparency of visibility when it comes to delivering software.

Building - Accessibility and assisted access

In the UK 1 in 5 people have some sort of disability. It shouldn’t be an afterthought to service these users at the end of building a solution. Accessibility goes far beyond just people with disabilities though, users could have limited internet connection, be in a distracting environment, or using outdated hardware.

The minimum compliance should be:

  • Comply with the Web Content Accessibility Guidelines (WCAG 2.0)
  • Build compatibility with the most common assistive technologies – screen readers, and speech recognition tools
  • Build compatibility for users who don’t use a mouse or touch device

5. Delivering

📒 Jump to chapter ‘Delivering’ for practical engineering information.

Delivering - Open Source where possible

Identifying components that could be open sourced up-front is really helpful. It’s easier to work open-source on something from the start than it is to retrospectively turn into an open source project. Working in the open helps you devise standard interfaces, write good documentation, keep data separate, and get the process for integrating open source into your main project in place.

We can’t always produce open source components, it depends on the licences and contracts agreed upon – but it is without a doubt that the advantages open source usually outweigh the disadvantages.

Delivering - Monitor performance indicators

It can be difficult to see the value a project is generating, especially when it is in its early stages. Being able to see hard numbers and results can go a long way towards getting stakeholder buy in and adoption. Information dashboards or regular reports are an excellent way of sharing KPIs with stakeholders.

Key performance indictors to consider are:

  • Availability
  • Performance
  • Goal completion rates & routes
  • Failure rates
  • Process overheads
  • Cost per transaction

Delivering - Measure Success

To really know if a project was a success we must have clear goals, and data to validate them against. Measuring satisfaction, adoption and ROI are all important parts of deciding if a project has reached its goal yet. In an agile process this is a continuous challenge, and there is always going to be room for improvement.

Our methodology #

Work location & hours

As we mentioned in the Introduction, we do not enforce a rule of a minimum number of hours per week inside one office location. Some team members do follow that model and some do not. The key point here is that they have a choice.

We do not track working hours in a strict sense. So how do we ensure essential tasks done? Beyond having a very high level of confidence in our hiring process we measure more meaningful indicators such as whole-team velocity. We grant our team members the authority to create their own working schedules. We understand that those hours may vary week-to-week and that work should not dictate the schedule of your life.

In the same vein, we do not limit team members to a set number of days’ holiday per annum. If a team member requires time off, they are entitled to take it. We just ask that they always give as much notice as possible.

Our experience is that if you treat your team members fairly, they will treat you fairly in return. By creating an environment in which team members can operate at their highest potential, we get the best out of people.

Although dispersed teams are now possible in software development (mostly due to improvements in tooling), they should be carefully managed. Compared to working in the same location, there are many elements of remote working which require more effort. These are:

  1. Ensuring team morale is high
  2. Having visibility into everyone’s contributions
  3. Ensuring there is a balance with decision making
  4. Tackling synchronous blocks

To overcome those problems, good communication and a good working environment are key.

Working environment

A good individual working environment is also very important. Open-plan, busy offices are often a terrible working environment for tasks that require concentration, like programming. In contrast, they are great environments for collaboration.

Working alone at home can be great for pure programming productivity, but can result in feelings of isolation, accompanied with a low visibility into the future picture of the project and company. Even simple factors like ergonomics and quality of light have a big impact over a long enough timescale.

To enjoy the benefits of working remotely and mitigate the downsides, we recommend:

  1. Mixing it up by working from different places depending upon your tasks. Working at home alone to get through a complex programming problem might be ideal, but everyone meeting in the office, or online, to figure out specifications is probably a good idea too.
  2. Having regular team meetups. Get everyone in one place. Meet your co-workers.
  3. Remember it’s not all about work. People work best when they are happy.

There is no silver bullet (as with everything in life and business). We do not think remote working is the key to success, but it is a good tool to have on your belt. Use it when it makes sense.

The Purepoint open source accelerator

Software development would be a far slower process without the open source community. The utility of open source software can not be understated – the creators and maintainers are often unsung heroes. Their work ensures more and more problems can be labelled as already solved problems.

Effort does not need to be duplicated. Purepoint is a passionate supporter of the open source movement and we believe in contributing back as much as we can.

The Purepoint Open Source Accelerator is open to all our employees. Its goal is to promote the creation and distribution of open source software back into the community.

  • We will allocate a total of 1,000 paid developer hours per year from our team, to be split between the accelerator projects - with developers working on their preferred projects to help them grow and develop.
  • We will allocate a budget of £1,500 per year to supporting the project
  • We will provide additional branding, marketing, and resources to help raise the visibility of the project and the lead developers.
  • We will fund the use of additional tools and licences required to grow and and expand projects as required.

We are always looking to back Open Source projects that are broad in scope.

There is no cap on how many projects we will accept. However, it is up to our discretion as to what is accepted - we will work with all our developers to get projects to a point where they can be accepted.

How we communicate #

Customer communication

Communication is necessary to build relationships, clarify ideas, shape new opinions, and establish the facts. Unfortunately, too much communication can become detrimental to actual output. We repeatedly observe two common manifestations of this within companies. The first is ‘design by committee’ decision making and the second, unnecessary meetings.

We’ve created a culture where open communication is absolutely encouraged alongside a deep respect for the time of our fellow co-workers.

Customer communication - Types of communication

On-site

Sometimes we achieve this by temporarily allocating people straight into the customer’s office - usually during the planning phase. This allows for faster prototypes, quicker answers, and a faster understanding of the domain.

Digital

Scheduled quick meetings via Google Hangouts and dedicated Slack channels with the customer are good solutions.

Email is always a much-used tool. We encourage inbox management once or twice per day rather than attempting to deal with emails in a stream as they come. Any input that removes your present focus or attention should be scrutinised. Email is one of those inputs. Rarely is anything so important that it should become ‘ASAP’.

Automated alerts

Truly urgent events relating to customer projects can be tracked via dedicated Slack channels that have third party integrations. An example of this might be reports on elevated error rates on a customer application.

Customer communication - Working with domain vocabulary

The nature of our work means we interact with lots of companies in specialist industries.

Just like the software industry, most specialist industries come with a large amount of domain-specific vocabulary, jargon and acronyms.

Do not be afraid to ask a customer at any moment to clarify a term they use.

At the beginning of each project, we create a glossary document in their customer folder if there is sufficient specialist terminology to warrant it. We allow the customer to access this document too. As team members work on a project, every time they encounter an industry specific word, it gets added to this document.

It is surprising how the glossary can grow over the course of a project. All those terms represent a concept that at one point a team member did not understand. The glossary represents Purepoint’s growing knowledge as a team about that industry. By actively contributing to the glossary, you are helping not only your current team members, but all future team members who interact with that project in the future. You’re also helping management, who might not have the same exposure to the day-to-day jargon.

Although it is often difficult to admit you have no idea what something means, especially if someone is using it flowing conversation, this industry specific jargon is a big blocker to cutting through and understanding the workings of the customer’s company.

Customer communication - Getting everyone on the same page

With domain-driven design, it is very important that everyone is using the same terminology to explain the same concepts. For example, a customer may often, even within their own domain, use words interchangeably.

‘Documents’ may mean different things to different people - one might person might include the idea of data in a database as a ‘document’ and another might not.

Identifying these polymorphic words early on and encouraging everyone to use clearly defined versions can have a huge impact further down the line.

Customer communication - Saying no

One of the most important tools we have is the word ‘no’.

It may seem counter-intuitive to tell a customer who is paying you for your service ‘no’. But in many situations, a ‘no’ prevents a customer from adopting a flawed approach. We believe that a customer is paying us to tell them ‘no’ at the right times.

Saying ‘no’ is just as important as saying ‘yes’. In fact, because of its uncomfortable nature, possibly even more important. Not saying ‘no’ leads to feature bloat, timelines sliding, and whole projects going sideways.

It is our job to understand software and its associated pitfalls and merits so that we may guide our customers towards success. Our customers will often have the best intentions but will not necessarily understand the implications of a particular request. Industry knowledge allows us to realise when a customer may be asking for the wrong solution to a problem. Likewise, if we were asking advice from our customers, there would be industry knowledge they have which we lack.

A software project never failed because it wasn’t large or complex enough.

Infact saying ‘no’ doesn’t just extend towards customers. It applies to management and fellow team members too. Because knowledge is never equally distributed amongst companies and individuals, everybody can make bad requests, as determined by the person who has superior information. If you think that an idea is a bad idea, say so.

But before you say no to something, think about the implications of saying ‘yes’ and try to understand the request from the other point of view. Then rather than just saying ‘no’, have an alternative solution to propose, as well as a strong rationale as to why you think that is a better solution.

Internal communication

Because our teams can be geographically dispersed, maintaining clear communication is critical. It helps with team morale, builds team dynamics, and keeps projects moving on pace.

Regardless of the medium you are communicating through. There are a few key principles we try to follow:

Internal communication - No ASAP

Although something may be urgent for you, odds are it is not urgent for the other person. If you need something ‘ASAP’ odds are it represents an underlying problem. Why do you need something so urgently? What could you have done to avoid that?

Breaking someone’s workflow is detrimental. Emphasising something is of a high priority is fine, but do not expect the other person to break out of their current tasks just because of that.

The nature of our business means that if we are performing our roles well, there should be no surprises and no sudden rushes. Even if customers are sending ‘ASAP’ requests, it is our job to act as a filter of those requests and keep our own processes running smoothly. Setting the expectations of external parties is important.

Every now and then a situation arises where ‘ASAP’ is forced upon us by external factors. These are rare situations like a customer emergency or downtime of a project. In that case, the processes we have in place should dictate how team members act, rather than any ad-hoc ‘ASAP’ requests.

Internal communication - Everyone makes decisions

Decision makers act as bottlenecks within an organisation.

Often when a decision needs to be made, it can be made simply by talking it through with a fellow team member. No further action is required. If you think it is the best course of action and it is in line with the principles contained within this Blueprint, then take it.

Try not to overrule the decisions of other team members unless you have information which renders that decision debatable. If you have an alternative method or solution to propose, ensure that you can debate the given issue from both sides of the table.

Try to follow Bloom’s pyramid when working towards an important decision:

“Bloom identified six levels within the cognitive domain, from the simple recall or recognition of facts, as the lowest level, through increasingly more complex and abstract levels, to the highest level which is classified as evaluation.”

- Rhetorical functions in academic writing: Writing critically

By identifying which level of the pyramid you are currently on, it helps solidify when you have reached a sensible decision. Obviously while still understanding the problem and gathering understanding on available solutions, you are still in the early stages.

Provided all parties inside Purepoint have spent some time working through the available information and have reached the top of the pyramid, they can ‘evaluate’ all possible solutions clearly, thereby enabling them to reach a good solution.

In a structure where you generally cannot just defer to someone ‘above’ to solve the problem, this is an important process.

Internal communication - Stand-ups

Within each project we do have morning stand-ups. Because of the nature of flexible working hours, these are not always in the morning, but we try and arrange times that suit everyone on-board.

Stand-ups generally last no longer than 10 minutes per project. Some people may be involved in more than one project. As a result, they might need to attend more than one stand-up.

Teams can choose how they set up stand-ups to best suit their needs. A fixed time or a flexible time can be decided by all members.

We follow free-form stand-ups, giving each person a couple of minutes to speak and ask questions. A broad format we follow is:

  • Let everyone know how yesterday went
  • Let everyone know your plan for the day
  • Raise any concerns related to the above
  • Ask any questions that are relevant to the whole group (though you may not get an answer in the stand-up)

Everyone should try to avoid getting into technical discussions, or answering complex problems during stand-ups. These matters should be dealt with separately afterwards.

Anyone can join stand-ups, even just out of interest.

Meetings

It is safe to say that as a company we think meetings should be used sparingly.

There are two distinct types of meetings; internal and external.

Meetings - Internal

These are defined as meetings between Purepoint team members.

Use the daily morning stand-ups to your advantage. Address the team with quick questions or plans. If you have questions for specific people do not involve the whole team.

Try to stick with email and Slack as much as possible. Give people at least half a day to respond and use the method of going to others in the company only once you have checked other information sources like READMEs, Internal documentation and files.

If you need to use a meeting for planning purposes (something which typically occurs at the beginning of sprints), then try and keep meetings under 20 minutes. If they look like they are longer, break them up, or question what is so complex that required multiple people synchronously. Prepare beforehand. If possible, do them standing. Use whiteboards and paper. Take photos once you are done and let each person take notes in their own favoured style.

If meetings of longer than 30 minutes occur semi-regularly, it may be worth trying to identify the root cause of that. From experience, those meetings occur when team members have a lack of information from the customer, are faced with complexity of a proposed solution, or lack domain/technical knowledge. Sometimes they are the result of poor management, or a bad flow of information.

Do not be afraid to go outside your team to management or other employees if you feel it will help.

Meetings - External

These are defined as meetings involving prospective customers, customers, and other third parties external to Purepoint.

If you think that an external meeting lacks a clear goal and purpose, do not be afraid to say ‘no’.

When planning external meetings, try and set a fixed goal for the meeting and a duration which allows that goal to be achieved. If possible, organise a meeting via web-conference or tele-conference rather than in person. This ensures that all parties involved can perform the meeting from their preferred location, thereby limiting overall impact on your schedule for the day.

In-person meetings should be saved for exceptional circumstances. Some examples include developing specifications, understanding a customer’s users, or presenting project proposals. For general day-to-day things such as clarifying questions or working out details on specific features, try to keep meetings digital and under 20 minutes in duration.

We understand that some customers favour traditional face-to-face meetings and we cannot always follow our desired structure.

Meetings - Monthly company catch-ups

Every month we do a virtual company wide catch-up meeting. The goal is just to let everyone know what the company is up to, new people, new projects, goals and updates. We try to be as transparent as possible.

Purepoint: People

How we interview and hire #

Don’t be normal

We do not use recruitment firms. In our opinion recruitment is an ideal marketplace to be thoroughly disrupted by software. There, we said it, and possibly made a couple of enemies in doing so.

Joking aside, hiring is a game of relationships and reputation. The best recommendations come from your existing network. After that, they come serendipitously; a meeting at a conference, a chance friend-of-a-friend encounter, or someone you meet unexpectedly. The point is that usually, the best hires come from places you do not expect.

When recruiting, we cover a very large area: Western Europe, Western Russia, North and South America. This enables us to recruit from a large talent pool. We then make sure that teams are comprised of members in overlapping time zones. As a result, tasks where team members need to collaborate are not negatively impacted, helping with team morale and velocity.

If you only look for someone at the exact moment you need them, you are confining yourself to a very narrow time slot and only the people who are looking for work right now. You must then concede to traditional methods of recruitment like paid job ads and recruiters.

So, our approach is to always be open to new hires. We are not always able to hire, but we try and be pragmatic about it and try to treat hiring in the same we treat looking for customers - as an ongoing process.

The larger your exposure, the larger the chance you bump into a good hire. Conferences, events, talks, and meetup groups are all great network multipliers. Also, a common mistake is to try and scope these just to the tech industry. As is the way with serendipity, you may meet the next great hire at a photography meetup rather than a programming meetup.

We try and look for ‘T-shaped people’. It is a silly term - but it basically means people who are great at one thing but also familiar and experienced with a whole bunch of other stuff.

In practical terms that means developers who are also well versed in all the other areas our business extends into.

Interviewing Engineers

Our hiring and interview process for engineers can be broken down into 6 steps:

  1. CV, portfolio and presence evaluation
  2. Initial exploration emails
  3. Phone call & coding project task
  4. Video conference technical interview
  5. References and checks
  6. Founders interview

We spread responsibility for each step over several team members, and use a fixed scoring method at each step to build an overall candidate score. We try to keep our pipeline somewhat asynchronous, so steps may happen in different orders or even overlap.

If a candidate is looking strong then we try to get them to interact with our teams as much as possible as they go through the later steps.

1) CV, portfolio and presence evaluation

We evaluate all applicants in the following key 4 areas, scoring each internal quality from 0-2:

Communication

Weighting Quality
2 Candidate writes in a clear and concise way
1 Demonstrable spoken English (online videos)

Disqualifying features:

  • Too energy consuming to read
  • Likely that they could not interact with a customer or other team members fluently
  • Spelling and grammar issues

Technical

Weighting Quality
1 Level of seniority achieved in their field
1 Active contributor on sites like Stackoverflow
1 Github sample codes (Open source or otherwise)
2 Quality of company apps
1 Quality of personal apps
2 Prior companies worked at techincal standing

Disqualifying features:

  • No relevant experience
  • Only worked on their own project(s)
  • Code samples are low quality, or poorly documented
  • Apps are low quality

Education & Skills

Weighting Quality
2 Quality of academic institutions
1 Progressive approach to learning new skills

Disqualifying features:

  • Technical skills only acquired after attending a coding workshop

Leadership & team

Weighting Quality
2 Teaching experience
1 Talks at conferences
1 Created online courses
1 Actively maintains a blog (or similar)
1 Trained others in previous roles
1 Time spent leading a team
1 Contributes to open source projects

Disqualifying features:

  • None

These metrics are all recorded in a spreadsheet. A final score out of 100 is automatically calculated taking into account the various weightings. If any of the ‘disqualifying features’ are present then the candidate isn’t scored.

2) Initial exploration emails

We always have a set of criteria we are looking for at a high level. Correct level of experience, salary expectations, location, availability, and interpersonal skills all rank highly. These vary in importance depending upon the position. We don’t measure this step in the same score driven way we do the first step - we go largely on gut and how interactions go.

3) Phone call & coding project task

For each language and position, we have designed a small coding test that should take around one hour to complete. These are very lightly specified, and designed to test several things:

  • Interpretation of requests and specifications
  • Overall approach to a problem
  • Quality and readability of code
  • Consideration of potential future issues or requirements

We always accompany these tests with a quick phone call so the candidate can ask any questions, and to give a quick reassurance that getting to this point means they are in consideration for the position. These calls generally only last a few minutes.

4) Video conference interview

These are highly informal in their flow and generally last less than 45 minutes. There will usually be 2-3 relevant people passively listening in and evaluating, with one person leading.

The first part of the interview follows a set of questions constructed around building a very simple theoretical application. The questions are not technically difficult at all and many candidates are surprised at how ‘programmatically simple’ this step interview can be.

However, we are really trying to assess how the candidate approaches the questions in terms of rational thinking and key skills. It is surprising how many experienced programmers will overlook very simple fundamentals when answering these questions.

The second part of the interview moves onto more general knowledge. This tests more computer science theory if relevant, and takes a broader language-agnostic approach.

The third part deals with tooling and team workflow.

The final part of the interview focuses on coding problems and algorithms.

We assess how they respond to being challenged and to being pushed to explain their answer to a seemingly very simple question in greater and greater detail. This reveals the depth of their knowledge and understanding. This process involves asking ‘but why’ over and over when starting with a seemingly simple answer.

Depending on the specific role, and how the candidate is doing various steps may be extended or skipped.

5) References and checks

We use a third-party service to check key details of applications such as references, employment history and education.

6) Founders interview

The final step of every hire is an informal chat with the Purepoint founders. This is mainly to get to know the candidate, evaluate cultural fit and talk through expectations, questions, and reservations openly.

‘Developing’ is only a part of the job engineers do daily. Time management, planning, team interactions, balancing priorities and managing customer relations are all hugely important. So, we try to get a good feel for all those qualities during this final step.

The candidate will get a final score out of 20. We do not simply pick the candidate with the highest score. We also evaluate notes and talk through the hire with everyone involved.

When we have selected a candidate, we present them an offer. We also reply to all other candidates with an explanation of exactly why they did not get hired. We give more detailed feedback depending on how far along the process they got. We think this is an incredibly important step as it reflects on your attitudes towards staff as a company and often the people who narrowly did not make the position may in fact be ideal for another position further down the line.

Interviewing other positions

When recruiting positions outside of engineering the flow looks very similar to the engineering flow. We just change out parts of the process.  Because we hire outside of engineering less frequently we tend to design each process per-hire and then vary it from role to role.

Building effective teams #

Teams at Purepoint

High performance teams are extremely rewarding. Both to the individuals, and to the team as a whole. However, building a high performance team is far from straight forwards. Beyond the simple requirement that the members must be talented and motivated, they need to understand each other and their relative roles, respect each other, and build trust and energy.

Based on the Tuckman model

It is easy to dismiss these sorts of graphics as management nonsense. However, when it comes to teams there is a very real pattern which is captured here perfectly.

By understanding these phases, and guiding a team through them, members can better understand where they are and what they need to help make happen to improve the team and move it forwards.

1. Forming

  • Team is polite, people tend to work on their own
  • Task is often not fully understood, false starts and misunderstandings are common
  • Some people may be anxious or overwhelmed
  • People slowly start to work together

2. Storming

  • The team starts to tackle the problem in a meaningful way
  • Roles begin to emerge, leaders, followers, specialisations
  • Relationships form, tensions can grow, but trust is built
  • People start to understand each other on a more personal level

3. Norming

  • The team gains an identity. There is consensus built around rules and values.
  • People develop a stronger belief in the goal, including previous doubters
  • As tasks change and progress is made, teams often go backwards and forwards between storming and norming
  • Individual team members take responsibility for outcomes, but in the context of the whole team

4. Performing

  • Trust is built, leadership is respected
  • People are energised, the task is well understood
  • Relationships are strong, though there may still be tensions
  • Tasks are delegated throughout the team

The psychological element of teams is often ignored in software development. But understanding what makes each team member tick and leaning into that is extremely important. Teams dominated by an overly-extrovert leader, or that don’t give more introspective members their platform are doomed to never reach the fourth stage of the cycle and realise their potential.

When a project ends and a high performing team moves on, it is often quite a sad moment, and the whole process must start again with different goals and members.

Structuring projects and teams

Operating a flat structure means that team members’ roles can change on a per-project basis.

Everyone has their strengths and weaknesses, as well as their own personal lives. While it may have made sense to have someone be the lead architect on one project, we do not think it should be a certainty that they would also be lead architect on the next project.

Teams perform best when they have challenging work, and a good team dynamic. If you take either of those things away you start moving away from a high performance team. The diagram above shows how team dynamics can shift as you change the level of challenge or the team cohesian.

Revolving team members in this style gives everyone a different perspective into the challenges and rewards of different positions in the company. It is a perk of project-based or feature-based teams.

Management typically decide who works on what projects and how many people are allocated to a project. Team members can most certainly express a desire to be allocated onto a specific project. All things considered, we must perform a balancing act and remember that team composition for a project is a choice largely dictated by budget. Additionally, having unassigned team members sitting on the bench is not ideal. We therefore must plan and assign people to projects early-on and depending on their skills.

Understanding ‘cloud based’ teams

Cloud based teams need to be managed differently to co-located teams. Though there is much overlap, it is important to at least understand the key differences.

Benefits Challenges
Enables access to specialisations that are globally dispersed Distance makes building trust and purpose more challenging
Enables access to localised knowledge Communication and coordination are more complex
Cultural diversity brings different mental models Cultural boundaries can lead to misunderstanding
Expands the working day through time zones Time zones create management challenges
Increases flexibility and agility Distance makes picking up on social cues more challenging
Allows for focused working environments More difficult to socialise and build relations outside of working hours

Purepoint was founded as remote-first, so we have many years of experience, tools and processes geared towards supporting cloud based teams. Obviously not all our teams and projects operate this way, but for those that do we have to guide our customers through what may be a new way of working for them.

Purepoint: Engineering

Engineering Principles #

Before dealing with the practicalities of building software, it’s important to understand the broad 10 principles we follow when approaching any project.

  1. Understand the user’s needs
  2. Design with real data
  3. Use feedback, Iterate rapidly
  4. Build services, not tools
  5. Understand context
  6. Favour simplicity
  7. Be consistent
  8. Embrace Reuse
  9. Document
  10. Deliver with confidence

1. Understand your users needs

If you don’t know who your users are you can’t build the right thing. Users come in many forms: end-customers, to companies, through to other developers.

Do research, collect data, and don’t make assumptions. What users ask for is often not what they actually need.

Breadth is often just as important as depth when it comes to understanding users. It is rare that any service is used by only one type of user.

2. Design with real data

Data should drive your decisions. Not hunches or guesswork.

Analytics should be collected right from early prototype stages so you can understand the strengths and weaknesses of the service.

Using the correct data, and the correct tools is vital. Data analysis should always be tied to a business-goal, or user-goal.

3. Use feedback, Iterate rapidly

Using agile continuous delivery and rapid prototyping lets us start small, test, iterate and improve constantly.

The goal should always be to put a service in the hands of it’s users as soon as possible. Consider the true MVP. Do alpha launches.

Avoiding big releases, avoids big failures. Using feedback and data lets us catch problems early.

4. Build services, not tools

We build services that help achieve a goal. Those services may span many platforms, and manifest in many different ways.

At the end of every service, there is a user trying to achieve something. It is our job to guide that user to success as invisibly and simply as possible. When we stop thinking about individual websites, apps and APIs and instead think of broad, harmonised services it becomes much easier to focus on addressing the underlying user needs.

5. Understand context

Don’t build for a single device, or screen. We are building services for people.

Where they are, what they are doing, what their goals are, what their expectations are and which devices and tools they are using all come together to create context.

Without understanding that content, it’s difficult to know why we’re evening targeting a specific device or addressing a specific problem.

6. Favour simplicity

Making something simple is much harder than making something complex. That’s because most systems are inherently complex, so abstracting that complexity away and presenting a simple model of the system to the user can require a lot of thought and work.

This is true on many levels. Not only in tackling how end users interact with a system, but also with how we architect solutions.

Complexity breeds complexity. Often the simplest solutions are the most elegant.

7. Be consistent

This extends over many areas. From documentation, to user interfaces, to coding patterns.

Consistency reduces the cognitive load of having to try and understand something new. Humans think and understand in patterns. Users consider consistent interfaces to be intuitive. Developers can navigate consistent codebases faster.

Technologies and features change, so we must be pragmatic about consistency - but breaking a pattern should be a measured decision, not an accident.

8. Embrace Reuse

This goes far beyond writing DRY code. It econmpases using open standards, open sourcing entire projects and cross-pollinating ideas between teams.

If we don’t reuse tools and ideas we can’t build on past lessons and improve upon them.

A good rule is the rule of 3s. If something seems like it is being used 3 or more times in the business or codebase, then consider finding a way to harmonise this, and bring visibility to the solution.

9. Document

Having reliable documentation is crucial. It helps with troubleshooting, lowers onboarding friction, and improves confidence.

Documentation comes in many forms, from inline comments, to readmes and wikis. Documentation should follow 7. Be consistent. Fragmented and out of date documentation has little value.

Writing documentation takes time, but it’s an upfront cost that will pay itself down over time.

10. Deliver with confidence

Delivering with confidence comes from building within a good process.

From understanding underlying needs, to designing solutions. Following Quality Assurance guidelines and delivering and iterating quickly. Each part of this blueprint lays out ways we increase confidence in delivering the right solution, at the right time.

Planning & prototyping #

Understanding requirements and writing specs

This is Joel Spolsky’s excellent definition of functional and technical specifications:

A functional specification describes how a product will work entirely from the user’s perspective. It doesn’t care how the thing is implemented. It talks about features. It specifies screens, menus, dialogs, and so on.

A technical specification describes the internal implementation of the program. It talks about data structures, relational database models, choice of programming languages and tools, algorithms, etc.”

- Joel Spolsky, Painless Functional Specifications - Part 2: What’s a Spec?

We develop technical specifications in an Agile fashion. First, overall technical architecture is specified and second, a more granular per story level of detail is specified.

Our approach to functional specifications is ‘just enough’.

We want to understand the customer’s needs and their domain, but we do not want to over-specify things for the sake of it as it generally goes against the ideas of Agile and continuous delivery.

A functional specification can be thought of as a document that records the choices the team make - it is an ongoing process. It supports the key things upfront that we have decided to develop as a minimum viable product (MVP) and then builds upon that as we go.

Understanding the company’s business is the largest and most important part of getting specifications ‘right’. If we design an elegant solution to the wrong problem, then the solution will fail regardless. Often the problem is not obvious - companies may be looking at symptoms and trying to fix those. It is our job to identify the problem rather than merely introducing patches for symptoms.

Given this approach, people are normally the most important component. Gathering knowledge of the customer’s employees, processes, and working patterns is key. To achieve this, we typically send a small exploratory team to be introduced to the customer’s team. We look to understand the entire working day of the people who will be impacted by the software solution. Sometimes in larger projects this is broken down into several sessions. We try and understand where the customer is and where they want to be - fundamentally a Gap Analysis, with proposed solutions flowing from that.

Before we start writing functional specifications we should be able to clearly define the goals of the project, what we think the return on investment of those goals will be, and have the customer agree with this.

The functional specification should cover the following points:

  • Define the goals of the project
  • Define the user control flow
  • Define the system architecture
  • Define the system infrastructure
  • Define the database model
  • Define the interfaces to APIs and other systems
  • Define the target platforms
  • Define the non-functional requirements

A specification should have one lead author. Several people may be involved in gathering knowledge and putting together the solution, but one person should oversee coherently putting the document together. There may be other editors but one person has final responsibility. This ensures that a specification reads with clarity.

“But no one reads the spec”

Keep things simple. Do not bamboozle the customer with unexplained acronyms or verbose prose. Trick people into reading it by presenting it in small pieces. Gather feedback. Do not use templates, they force linear approaches to nonlinear problems. Review often. Keep ROI in mind. We always balance the breadth and depth of a specification with the size of a project. Specifications are time intensive processes, but a necessary process to define the scope and capabilities of a piece of software.

Prototyping in code

Although we are a very design-centric company, we do not have any dedicated designers. Why? Because we believe it creates a disconnect between the realities of the implementation and the design process itself.

Carefully crafted static designs might look nice on paper as something to present to the key decision makers, but for us, they fail in three distinct areas. First, they are fundamentally incompatible with an Agile process. Second, they usually fail from a user experience perspective and third, they add a lot of complexity to implementations.

Instead, our design skills are scattered amongst our team. Some team members, we admit, should never be let near a colour palette! But that is fine, they agree too! Others in our team have strong design and interaction roots.

From the customer’s perspective, frameworks are so powerful nowadays that they shouldn’t be paying for lengthy Sketch mockups. We build design into our entire process and implement it with the same tools we program with. Frameworks allow us to create working prototypes and designs directly in code. This is by far the most efficient way of approaching this task.

The clear majority of our deliverables are cross platform, which only compounds the efficiency of prototyping straight into code as soon as possible. Our approach is to prototype for the platform we have identified as the key platform first, then iterate those prototypes down or up in size to other platforms only once all the key problems have been addressed on the main platform. This ensures that designs are adapted to play into the various strengths and weaknesses of different viewport sizes.

So why do we prototype?:

  • To challenge our preconceived ideas about how well solutions will work
  • To reveal potential problems in our solutions
  • To test the visual look and feel
  • To identify problem-areas far in advance

Whom do we prototype for?:

  • The key stakeholders
  • Internal Users
  • External Users
  • Customer
  • Developers

We embrace a process of rapid prototyping, combined with continuous delivery. Rapid prototyping is a methodology of creating ‘working prototypes’ as early and as fast as possible.

Our process through to final product generally looks a lot like this:

Each stage of the process is driven by the rapid prototyping methodology involving the customer and key stakeholders.

Low Fidelity Medium Fidelity High Fidelity
Pen and paper Rough code rapid prototype Interactive functional prototype
    Final polish

During the prototyping phase, we find it important that we work with data that is as realistic as possible. Sometimes we must work with ‘lorem ipsum’, but where possible we work with the customer early on to get a feel for the kind of data we will really be working with further down the line. This helps reduce misunderstandings or bad choices early on.

Getting Prototype feedback

The value of prototypes is greatly reduced if they are done in isolation. For a successful rapid prototyping cycle, the ‘review’ phase is critical. This means gathering feedback from various stakeholders, often primarily the customer.

Present mock-ups in the right context. If you are at the low or medium fidelity stage, getting feedback on the colour of buttons isn’t of much value. Getting feedback on what those buttons do is critical.

Here is our process:

  1. Define up front if you are testing form, function, interactions, or a mixture of these. Lay this out to the user.
  2. Have a clear goal for your mock-ups. Challenge your assumptions.
  3. Collect enough feedback to be able to act.

Using judgement is critical. Design by committee typically results in weak design. In the interests of simply adding feedback for the sake of it, people often ask for changes that detract from the design. Do not be afraid to say ‘no’ if you feel strongly about it.

The more people we collect feedback from the better.

It is important not to get hung up on getting things ‘perfect’ - the nature of Agile is that we can adapt and improve later in the cycle once we put things through their paces. Prototype testing can only go so far.

It is important to note the clear distinction between ‘feedback’ and ‘user testing’. ‘User testing’ comes later in the process and we have dedicated an entire section to this later in the Blueprint.

Designing #

User experience

There is a lot of overlap between understanding a company, writing specifications, and user experience (UX). Design and UX define how the user interacts with the product, and this greatly impacts what the product is and how it is built. It is not something you just bolt on at the end, it is something you work on right from the point of starting to understand the customer’s needs.

If you’re not developing your UX alongside specifications and prototypes then you are doing something very wrong. But in the same vein if you are jumping straight in and trying to design the UX before fully understanding the customer and their domain, you are also going down the wrong path by leading the solution without a full understanding of the problem.

User interface

In a simplistic sense UX is where the button is and what the button does. User interface (UI) is what colour that button is.

There is often an odd disconnect in that while UI is vastly important, customers tend to place an unduly large focus on it compared to the actual functional value the application should be generating.

We pride ourselves on excellent visual design and implementation of beautiful and modern interfaces. That said, it is undeniable that in most large and complex projects this design element is only a very small part of the total workload.

We try to work on UI iteratively. Delivering it gradually as part of the continuous delivery process means that as we keep working on a product, it will change in appearance as it matures.

It is important to include customers in this process. There is a large temptation with design work to hold off presenting it until it is ‘final’. We prefer ‘good enough’ combined with ‘setting expectations’.

Once feedback has been collected and functional ideas are proved to work, we add final touches to take the design through to finished.

User testing & feedback

User testing should aim to observe users ‘doing’ actions you want them to achieve in the application.

It should not aim to ask questions like ‘is this button in the right place’ as that means very little without context. It should ask users to complete ‘business tasks’ then observe how they go about using the software to try and achieve that task. This will highlight pitfalls, misunderstandings, and successes along their journey. For example, one observation might be that they could not find the right button or that they were looking for the wrong button altogether.

You should use preformed questionnaires so you can follow a standard format with everyone tested. Do not ask leading questions. Do not ask for advice (e.g. what do you think we should do to X?)

Find real users. 5 real users are worth 50 random people found who have no real connection to your product beyond the fact that they are roughly the right age and demographic. How you define ‘real users’ will vary wildly depending upon the project and so this has to be tackled on a per-project basis. Sometimes, it may be as simple as using the employees who will be using the final system.

Developing #

Light Agile & continuous delivery

Agile is a development methodology. For those unfamiliar with the methodology:

“Agile is a time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.” - Jonathan Rasmusson, Agile in a Nutshell (2015)

For the more visual reader:

Traditional software development:

Agile software development:

We believe that a full Agile SCRUM based process is often too cumbersome for small, nimble teams. It makes sense when you have 30-40 people all working on a project at once, but under our method of keeping teams small, it adds more overhead than value.

Agile methodology

A simple overview of our light form of Agile is:

  • Daily 10-minute morning stand-ups
  • 1 or 2 week sprints
  • Continuous release cycles supported by CI
  • A pull-based work backlog, with tickets brought into the iteration in a free-form manner
  • Feature-centric deliverables

Beyond this we think it is best for teams to simply expand or collapse the Agile process to suit them best.

The reality of project based work is that contractually, we are often scoped to a fixed set of deliverables outlined within a fairly fixed specification. We try to make the best of this and provision a minimum feature set, milestone based delivery, and continuous delivery even well before the full specification is met.

We also try to provision for a certain level of flex in the specifications. As a project progresses, a customer will often express a desire to deviate from a specification. Sometimes, it makes sense to try and accommodate those changes if they do not impact detrimentally on the delivery timeline or any work already completed. Our focus on an Agile development approach gives customers a greater insight into their project as it progresses.

There is often a more realistic ability to perform true Agile style development with our long-term, ongoing contracts. This is where we can add the most value for customers through continuous improvement and rapid changes that arise from feedback.

Continuous delivery

Beyond the light Agile method above, continuous delivery is an important part of how we run projects.

Continuous delivery means the constant addition of tangible features or blocks of functionality to the master branch of development, such that the software could be deployed at any time (released to the public). Continuous delivery allows for continuous deployment - however they are not quite the same thing. Continuous deployment is an extension of this.

The opposite approach would be building as many features as possible and having a ‘big bang’ go live date. What could possibly go wrong with that…

As shown here, when combined with rapid prototyping, we may loop through the 5 stages of development several times for a single feature. Once this feature is a releasable state, it can be packaged up and shipped out straight away.

We encourage customers to embrace continuous delivery and to start using the software we are building as soon as possible, even if they only use a small set of the final functionality. By doing this, it helps us avoid mistakes as we continue, iterate faster, test the current application, and set everyone’s expectations about what the software does and does not do as early as possible.

Continuous delivery relies on good test coverage, good infrastructure, good team ethos, and good application architecture.

We do not always use true continuous deployment. Depending upon the customer’s preferences, we might use an ad-hoc deployment method instead. As each phase happens, we choose to deploy or not deploy.

Writing code

Writing code is a subject that could have its own book. Many books have already been written on that subject. Here, we shall just cover some high-level principles we follow:

  • Do the simplest thing that could possibly work.
  • Follow these four simple design rules:
    • Avoid duplication
    • Express your intent
    • Minimise the number of classes and methods
    • Fulfil the test criteria
  • Follow SOLID:
    • Single-responsibility principle
    • Open-closed principle
    • Liskov substitution principle
    • Interface segregation principle
    • Dependency Inversion Principle
  • Aim for high cohesion but low coupling
  • Tell do not ask
  • Do not lump things together; aim for cohesion. Group resources by their actions not by object types.
  • Always consider open source (in both directions, consuming and publishing)

The top 3 books we aim for every new Purepoint employee to read are:

  1. The Mythical Man Month (Frederick P. Brooks Jr.)
  2. The Pragmatic Programmer: From Journeyman to Master (Andrew Hunt)
  3. Code Complete (Steve McConnell)

Code style guides

We stick to fixed style guides company wide. It helps keep code readable and generally does not present too much of a problem for programmers needing to adopt a style.. The style guides for each language are as follows:

How these are enforced is set per project.

Testing

Testing is just as important as programming if you want to deliver a quality application.

There are various types of testing to consider:

  • Vulnerability & penetration testing
  • Exploratory testing
  • Load & performance testing
  • Acceptance & unit testing
  • Accessibility testing

It’s not always practical to test everything all the time. Testing must be done pragmatically. In an ideal world everything would be tested all the time, but resources are limited and delivering working software is the goal. The level of test coverage depends largely on the nature of the system.

  • We aim for a high level of test cover but 100% isn’t necessary. Be pragmatic.
  • Use automated testing as much as possible
  • Testing should be done iteratively to fit in with continuous delivery
  • We take a best-effort approach to testing

We follow the best practices of Test Driven Development (TDD) and Behaviour Driven Development (BDD).

Run your tests often. Always aim ‘to add just enough to fail’.

Smoke-testing and manual testing still make up an important part of the testing process. Automating everything is not a nirvana and should be balanced with other types of testing where it makes sense.

Code reviews

We have a strict rule that no code hits master without being reviewed. We try to do code reviews in an asynchronous fashion - based on pull requests. This enables the reviewer flexibility to review in their own time and the writer can address concerns in their own time too. A code review that takes a couple of hours may therefore happen over the course of a couple of days. This lowers the pressure associated with code reviews that happen in real time between both parties.

Code review - Reading other people’s code:

Code reviews should focus on the follow areas:

  • DB schema
  • Code schema
  • Style
  • Fulfilment of specification
  • N+1 problems
  • Optimisation
  • Tests

We consider code reviews to be ‘best efforts’ in that they cannot always be perfect. There is a big factor of getting ‘close enough’. They take time and require someone to walk in someone else’s shoes.

While conducting code reviews, try and keep these principles in mind:

  1. Review manageable blocks. If a pull request is too large ask for it to be broken up.
  2. Keep reviews under 1 hour. If they are going on for longer than that, refer to the first principle.
  3. Be positive as well as simply highlighting and catching errors - code reviews are as much a time for identifying areas of merit and praise as they are for finding problems.
  4. Try and follow a standard flow for each code review.

Code reviews should be used pragmatically. Not everything needs reviewing. New, complex features, and changes with wide implications should be reviewed. Lots of day-to-day nuts and bolts programming will not benefit hugely from structured code reviews.

Refactoring

Before engaging in refactoring, stop and ask - why am I doing this? What is the return on investment?

Cleaner or more abstracted code for the sake of it might appeal to the pure programmer in you but often makes little sense from the customer’s point of view or that of the team.

Refactoring carries a weight as well as a benefit in the form of time. Additionally, there is a consequential impact upon everyone else who might be working around that code.

In cases where refactoring makes sense, for example when large changes have happened within a system, setting up solid tests beforehand is a good idea.

Keeping the principles of SOLID (See the ‘Writing Code’ section for an explanation) and ‘Don’t Repeat Yourself’ (DRY) in mind will help. Try to avoid over-abstraction. A good rule of thumb is the rule of 3. If something is repeated 3 times then consider an abstraction, otherwise keep it simple.

Abstraction carries a similar weight to refactoring, mostly the impact on other people coming in to work on the system later.

Optimising user flows

Where possible we favour multi-variant testing over plain A/B testing. It allows for more flexibility and given enough data, provides more decisive results.

A good overview as to the advantages of multi-variant testing can be read here.

Multi-variant testing is not without its flaws, but when used correctly it can be a powerful tool.

It is important to test the ‘right things’ that we can control. Testing the effectiveness of different implementations of the same goal is a good use of multi variant testing. For example, testing 3 different approaches to a user ‘adding an item to their basket’ and recording which one results in the most successful progressions to the checkout. It is important to collect enough data to have statistical confidence in the result and to design tests in such a way that you are testing the things you mean to be testing. In the example above that would mean making sure you are not inadvertently testing which colour button converts more highly when you are really trying to test which cart format works best.

There should always be a good business case for why a test is being run.

The process of simply trying to optimize random things for the sake of it often has little ROI if it misses the larger picture of ‘is the application functioning in the best way overall’.

Version control

Git is our version control tool of choice. In the words of the Git project:

“Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency.”

Git is a complex tool. So, we stick to some basic methods of working with it across all our projects:

  1. Use feature branches (Generally running for no more than 3-5 days)
  2. Master should always be in a releasable state
  3. Use pull requests for any reasonable size feature branch to enable code review
  4. Rebase on master
  5. Use continuous integration where possible

Delivering #

Platform Support

For our engineers we support the following platforms:

  • MacOS 9+
  • Windows 10+
  • iOS 9+
  • Android 5+

(Current as of: June 2017)

Any other environments can be used, but we do not centrally support them - you are on your own!

We are moving towards container-based development methods for future projects, but despite the burst of growth around products like Vagrant, Docker, and Otto we do not think they are quite ready for prime-time development purposes just yet.

In some situations, we may accommodate additional support requests at additional cost. We are not in business of building or supporting legacy software unless it is prohibitive for the customer to upgrade.

Environments

We generally use 3 environments:

  1. Local
  2. pre-production
  3. production

These make up a fixed flow.

Some projects may have additional environments, but we’ve found that simplicity often wins here.

We script the setting up of environments to different degrees. Currently we do this with bash scripts, Heroku Toolbelt and AWS CLI. Ideally we would use a single and compact tool such as Terraform or Cloudformation. We feel that the current state of the technology does not allow us to do this yet. It is an ideal we shall work towards as cloud-interoperability matures.

Hardware

We are a cloud-first company. We are not in the business of managing hardware.

Our most used services are Heroku and AWS. We believe that using these cloud services increases efficiency and helps us focus on writing code rather than doing system admin.

Cloud services generally have the following advantages rolled into them:

  • Flexibility
  • Disaster recovery
  • Automatic software updates
  • Lower capital expenditure
  • Increased collaboration
  • Improved security

Logs

It is better to log than not log. There are many tools for filtering and making sense of logs, but nothing will let you see something that was not logged in the first place!

For logging our preferred tool is Papertrail.

We move long term backups to S3. Some customers have very long or even indefinite data retention protocols driven by a need to achieve compliance with their industry bodies.

Data confidentiality

At any one time, Purepoint has access to varying quantities of confidential customer information. Protecting the confidentiality of that information is of the utmost importance. To handle this, Purepoint has implemented several different processes. First, we train all staff members how to handle confidential information. Second, we operate a strict ‘need-to-access’ basis policy. Third, when possible data is encrypted at rest if we are holding it on behalf of a customer.

Pre-flight checklists

We previously talked about keeping your personal to-do lists and checklists in a public Trello. The same applies here.

When undergoing unusual or critical tasks such as ‘go live’ or system migrations, build a pre-flight checklist. Run through the entire process end-to-end and create a checklist. Have a co-worker check it for you. Do not begin until you have done this step. It acts as both a guide and an audit trail of what you have done in the case something does not go to plan and other people must jump in midway.

Security #

Security is of huge importance to Purepoint. We follow industry best practices at every step.

  1. We are Cyber Essentials certified.
  2. We are ISO 27001 compliant.
  3. We strive to stay up to date with and follow the guidance of OWASP on all security matters.

A quick overview of our main security processes and practices:

Security - Applications

  • We use encryption at rest
  • We use encryption in transit (SSL/TLS)
  • We keep up to date with patches
  • We follow good design practices such as 2 factor authentication
  • No sensitive data stored in repositories

Security - Key storage

  • Keys are never shared insecurely
  • Certs & keys are stored in an encrypted vault

Security - Secure storage

  • 256 bit on disk encryption is used to:
  • Store keys
  • Store sensitive data
  • Store passwords (unique per service)

Security - Data protection

We maintain accurate records about employees and any current contractors that are working with us. This includes names, addresses, DOB, payment details. We only keep information that we require and when a team member leaves, we remove the information. We also maintain information on our clients such as contact details, job titles, and names. Some of our software solutions, or logging systems record IP addresses.

  • Data is stored on a per customer basis. Generally in the EEA or US.

Security - Social engineering

  • If ever asked for anything unusual employees are instructed to simply call or video conference the person to get physical confirmation. If they are unsure, check the request with management.
  • Certain things are never transferred externally (e.g. keys, customer data)

Security - Employees

  • All Google accounts centrally managed
  • 2 factor authentication enforced on all accounts
  • We use encryption and strong passwords on workstations
  • All team members provide photo ID on record
  • All team members have active contracts & IP transfer
  • Access and permissions are structured per project
  • No one person has the ability to lose system critical information

Security - Hardware

  • All public facing production hardware is firewalled
  • We run active monitoring and maintain blacklists
  • We maintain asset registers

Security - Incident management

  • We have tested DR plans
  • We have distributed audit trails and logging
  • We have undergone simulated pen testing attacks by 3rd party security companies

Local setup and tooling #

Choosing tools & platforms

We are a programming language agnostic company. We take a pragmatic approach to tooling. Often the unsexy tools are the best tools for the job.

We have used Ruby for large financial portals, JavaScript for data collection, and C# for system integrations. None of which would necessarily be the obvious choice.

There is always a temptation to use the latest and greatest; to deliver a ‘Kool-Aid’ driven application. Always try and consider the underlying requirements when choosing technology. Often ‘boring’ means ‘battle tested’. Especially given the enterprise nature of many business problems.

Key technology is one of the very few areas where we enforce a somewhat top-down structure. This is not because we want to force a solution upon our team, it is because often, the deciding choices in a language or toolset aren’t purely technical, but are heavily driven by business requirements (both ours and our customers). So, we have a phase where we talk through options with everyone involved and try to reach a conclusion about the best technologies to use.

Good developers have several strings to their bow. Although they may be more proficient in some languages, they should be able to change when needed. We do not hire people who can only work in one language or platform.

Programming tools

Different people like different tools. We have some preferences, but we do not think that it adds much value to try and force an entire team onto one tool. In fact we find that it can sometimes be detrimental, leading to a slower update of newer, more useful tools, which people tend to find on their own.

However, here are some of our current favourites:

  • VIM
  • Atom
  • Chrome
  • Sourcetree
  • Sublime Text
  • Tower
  • iTerm

Purepoint: Outreach

Building a meaningful brand #

Our brand isn’t about our logo or colours, it’s about our relationship with our customers.

It encompasses our beliefs, values and purpose, and drives our business – and this Blueprint is part of that. Our aim is always to deliver value and build long-term relationships with our customers. So, our brand comes from our employees and our solutions, not from marketing speak and stamping our logo on things.

A good brand and reputation can take years to build but only hours to destroy.

If our employees understand our core values, and our brand, then they can engage with it and build understanding with our customers. This leads to engagement, advocacy and eventually to new opportunities.

How we generate sales #

Sales come from both new customers and upsale to existing ones

Focusing on the customer’s needs is a core operating principle at Purepoint. In sales, this is referred to as a customer-centric approach. Our goal is to deliver software that provides exceptional value to our customer. We felt that a traditional sales model would be inappropriate. You will not find anybody at Purepoint tasked with cold calling, nor will you find anyone aggressively pushing to close a sale.

We focus on developing genuine relationships. By nature, we’re genuinely fascinated by software and business. It’s easy for us to engage with prospective customers about challenges they are facing. This enables us to understand their pain points and where software-driven solutions might add genuine value.

Once we start working with a customer, we maintain that relationship. We focus on being a trusted source of authority when it comes to technology and automation through software. Naturally, this helps us to unearth further potential to collaborate with our customers. It also helps us to establish domain expertise, which results in further inbound leads.

This problem-solving approach means that we receive a lot of referrals from existing customers.

The sales pipeline

Our sales pipeline is very traditional and consists of the following stages:

  1. Opportunities
  2. Proposal
  3. Refinement
  4. Negotiation
  5. Closed

The sales pipeline - 1. Opportunity

An opportunity is a qualified lead. Once we have gathered the following information, we can make an informed decision about whether this is actually a suitable opportunity or not. We look to ascertain:

  1. Goal - What is the customer trying to achieve? Do we understand their business?
  2. Pains - What are the main pain points for the customer? What will the business impact be if those paint points are unresolved?
  3. Timescale - When is a solution required by?
  4. Decision Makers - Who is ultimately responsible for deciding which solution to go with?
  5. Budget - Are we aligned on pricing expectations? Is budget set aside for this project?
  6. Competitors - Who else are they simultaneously talking with?
  7. Relationship - When choosing a provider, which qualities rank highest for them?
  8. Weighting of decision - By what criteria will prospective suppliers be assessed? How are specific criterion weighted?

If we then decide that an opportunity for Purepoint exists, we will devote time and resources towards understanding the problems in greater depth.

The sales pipeline - 2. Proposal

A proposal serves many purposes. First, it helps the prospective customer to understand whether or not we have fully understood their requirements. Second, it formalises our intention to be considered for the project. Third, it helps the customer understand the Purepoint approach. We introduce the concepts of Agile methodlogy and actively discourage large, waterfall style specifications. Simple, iterative solutions win the day. We collaborate with key stakeholders at this stage to ensure our proposal accurately addresses the challenges they are experiencing.

The sales pipeline - 3. Refinement

Once a prospective customer reviews our proposal, it often inspires questions and further discussion. The customer may realise that they need to gather more information, or that they’ve missed something entirely.

We will refine a proposal when new information is shared with us. We work together with the customer to help them answer some of their questions.

Sometimes, prospective customers require assistance establishing their final requirements. We might sign a pre-agreement which allows us to provide consulting services to the customer. We will then work meticulously to answer unknowns and gather key requirements.

The sales pipeline - 4. Negotiation

During negotiation, price becomes more of a consideration for the customer. We negotiate based upon 3 co-dependent factors; time, cost, and deliverables.

  • When timelines are tight, we encourage stripping back deliverables.
  • When deliverables increase, so too will cost and timeline.
  • When costs need to be reduced, we encourage stripping back deliverables rather than increasing timeline.

Once a verbal agreement has been reached, we will produce a Statement of Work for the customer. This will be sent over along with our Terms of Business.

The sales pipeline - 5. Closed

Once we receive a signed contract, the project is considered won. Mini fist pumps all round.

Naturally, some opportunities escape us and end up in ‘closed lost’. We track the reason why we lost the opportunity. This is very useful information and it serves as a constant feedback loop on our approach.

Ideas

Sometimes we have ideas about ways in which we could help our customers. The idea might be raw, conceptual, and in need of refinement. We then speak with our customers to better understand whether or not an opportunity for our idea exists.

If the customer is receptive to our idea, this flows into our sales pipeline.

Marketing is not a department

Purepoint does not have a traditional marketing department either. Instead, marketing concepts and ideas are generated fluidly by different members of the Purepoint team. Above all, we believe in the long-term effects of the present-day intangibles; delivering free value upfront to potential customers.

What does this mean? This means that Purepoint are active in the open source community, it means we release best practices, books, white papers, guides, and other information that a traditional company would charge thousands of pounds for in consultation fees.

We are not in the business of producing advertising campaigns or tweeting 4 times per day. We are in the business of tackling complex software problems and delivering value to our customers.

If we keep doing that, our reputation and customer base will continue to grow organically.

Pricing full projects

Estimating a project, service or feature correctly is essential. We assemble teams for projects and present pricing in relation to that team’s rate to the customer. This model allows us to have clear insight into day-to-day costs and therefore, total costs.

As a project progresses, team composition is likely to adapt depending upon the project stage. Naturally, customers want certainty around how much they are spending over the lifetime of a project. This highlights the importance of being as accurate as possible with our estimation of the timeline and the required team composition at a given point.

A delicate balancing act must occur when estimating timelines and costs, be it on a feature level or a project level. For some projects, it can take considerable time to assemble that information. Sometimes, the contract is not yet a certainty but it is within our interests to invest time into providing this information so we can move forwards.

We look to gather enough information so that on any estimate we can be 80% confident that our margin of error is no greater than 10%.

The law of diminishing returns dictates our reasoning here. Achieving anything higher than 80% certainty requires a disproportionately large amount of time.

No en-mass RFPs

We sometimes receive unsolicited en-mass requests for proposals (RFPs) and in most circumstances, we decline these.

It is our experience that these kind of project requests come with a monumental checklist of requirements that reads like the organisation has compiled every feature of their closest 5 competitors.

Although that may be a little ‘tongue in cheek’, it is often close to the truth.

We think this stems from a fundamental under estimation of how difficult it can be to get software right and that software can be cheap if you ‘shop around’ with a scatter gun approach. As with almost everything in life you get what you pay for, and genuinely great solutions come from finding the right partner and working through the problem with them.

All companies buying software should look to gain advice and recommendations from a variety of sources, but the reason we do not engage in these large-scale pitches is largely economic.

We try to keep Purepoint as streamlined and high performance as possible. As a result, we are not geared up as a company to create flashy pitches. We have no traditional marketing department and we do not believe in adding one. That cost to us would ultimately translate into higher end costs for our customers, moving our focus from engineering and a less efficient company.

General Topics

Ava - Our software director #

What is AVA?

Ava is our software director. Or, more directly a system that manages several important processes inside purepoint.

It is an evolutionary project - written, maintained and used by Purepointers. Ava handles our phone systems globally, project time tracking, onboarding, employee data, and project data. Ava has a personality and uses machine learning to help us understand what is going on with the people and projects at Purepoint. It integrates into our communication channels, portals and storage systems and helps us work in a more efficient and transparent manner.

We believe in software-driven businesses, and Ava is the embodiment of that. The result of us turning our services inwards and using them to improve our own business.

We have huge plans for Ava over the next years, so watch this space.

Day to day tasks #

Becoming process driven

We aim to document all processes inside Purepoint. From accessing servers, right through to filing receipts.

Nothing in Purepoint should have a bus factor of one. Meaning - will a process fail if the person who usually handles it gets hit by a bus?

Thankfully, we don’t know anyone who’s ever been hit by a bus. But people do suddenly fall sick, get stuck abroad or just move on to other projects.

The goal of sensible documentation is two-fold. It brings clarity to a process - writing it down for others to understand helps identify failure points (accounts only one person can access for example). It also allows others to pick up a process without having to start from scratch.

The hard part is not usually writing a guide, but maintaining it. Processes change, people move around, and ownership of documentation isn’t always clear. Discipline and good management are the best ways we have found of keeping on top of documentation.

Communicating

We use four primary channels of communication:

  • Google Apps for Work (Email, File Storage, Calendars)
  • Slack
  • Zoom
  • Phone

We try and band communications into project driven channels. Each project is assigned a name, and that name is then used throughout our communications. Team lead maintains access rights for the channel. For example:

  • Slack: #project-name
  • Group: [department.project] @purepoint.io
  • Drive store: department > project-name

Communicating - Google Apps

Used for email, file storage, and calendars.

Communicating - Slack

Used for communication amongst teams, communication with customers, and to receive automated notifications from third party integrations. For example, alerts about increased error rates on an application.

Communicating - Zoom

Used for video conferencing, pair programming, presentations and all other streaming video needs. We have tried many solutions over the years and have found zoom to be the most stable system currently avaliable.

Communicating - Telephone

Used for customer discussions, or situations where it is faster than typing, and when other methods of technology fail us!

Purepoint has a dedicated phone system built directly into our software director AVA.

  • Calls to the front desk are only routed between 8am – 6pm UK time
  • Answer phone messages are recorded and emailed as a streamable file
  • Every employee has an extension number that can route to their desks or mobile phones
  • The Purepoint conference system can be used with any customer

Front-desk calls are handled by our office manager.

Email Management

Use reply-all sparingly and curate email lists wisely. If you find yourself in a reply-all email chain with customers that isn’t relevant to you, filter it to skip the inbox.

Our Gsuite mail has features to help you curate your inbox. Automatic labels and filters can be used along with + operators in your email address to bring clarity and structure to your inbox. It’s always tempting to just push tasks like this back, and deal with messages as they arrive. But the benefits of having organised filters and patterns in your commuincation channels is huge.

We have several public-facing email addresses that different teams manage, and integrate into various systems:

Careers

careers@purepoint.io

We use an internal platform to manage recruitment - with direct application forms on our website. This email address is mostly for other recruitment based communications.

Accounts & Services

accounts@purepoint.io / services@purepoint.io

All receipts and payment notifications go this address. All paid services run through these addresses.

Invoices

invoices@purepoint.io

For incoming invoices.

General

hello@purepoint.io

First point of contact. This email is used on all public facing communications such as the website and marketing materials.

Support

support@purepoint.io

Used for customer support requests. By filtering requests through a team inbox, everybody has insight into customer related issues. Issues can then be assigned to a specific team member.

Keeping organised

We use Google Drive for general file storage. Folders are siloed by department groups and customer and permissions granted on a ‘need-to-access’ basis.

Many types of files are not suitable for storage in Google Drive. For further information, please read the ‘Security’ chapter.

All other files related to general customer projects should be filed in Google Drive. This includes contracts, draft documents, pitches, specifications, other legal material, and customer-provided files. When storing files in Google Drive, name them sensibly for the consideration of others, and for searchability.

As with everything related to Google, we operate under Google G Suite for Business, and two factor authentication is enforced company wide.

Improving & making changes #

As we mentioned into the introduction, nothing here is set in stone.

Quite the opposite. The source text for the Blueprint is publically hosted on Github and anyone in Purepoint can simply edit it and raise a Pull Request for their changes to be discussed openly among the whole company and merged.

Our entire ability to innovate and improve as a company depends on throwing away, changing, and improving our processes.

We do not pretend the ways outlined here are the best ways; they are just the ways we currently operate. We often arrive at our best practices in an organic fashion.

If you think we can do something better, or you have a different view on something, then just say so and propose a different method or solution for consideration. Or, even better, show us an alternative method and show why it works better. We are always listening.

Notes

Glossary #

API “Application Programme Interface” A standardised set of endpoints which act as a programmatic interface to an application.

Acceptance test A test conducted to determine if the requirements of a specification or contract are met.

Agile A time boxed, iterative approach to software delivery that builds software incrementally from the start of the project, instead of trying to deliver it all at once near the end.

Backlog A priority ordered list of tickets (or stories) to be worked through in each project.

Branch “Git Branch” A branch represents an independent line of development within Git.

Build The process by which source code is converted into a stand-alone form.

Cloud Cloud computing enables companies to consume compute resources as a utility - like electricity. Rather than having to build and maintain computing infrastructures in-house.

Code Review The systematic examination (sometimes referred to as peer review) of computer source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software.

Customer Centric Selling A model of sales that involves spending time to understand the needs of a prospective customer and thinking of yourself as a consultant as opposed to a salesperson. Once you understand the company, solutions can be positioned that align perfectly with the needs of the prospective customer.

Design pattern A general reusable solution to a commonly occurring problem within a given context in software design.

Domain Model A conceptual model of all the topics related to a specific problem. It describes the various entities, their attributes, roles, and relationships, plus the constraints that govern the problem domain. It does not describe solutions to the problem.

Feature A specific piece of functionality with a solution. Should be able to be delivered as a standalone piece. Ties into the idea of Agile deliverables.

Feature creep The ongoing expansion or addition of new features in a product. An anti-pattern. Ends up in bloated software that is over-complicated and a worse experience to use and harder to maintain.

Functional specification A formal document that details all features and specifications of a project. During the requirements phase a functional specification is one of the key documents created.

Gap analysis Involves the comparison of actual performance with potential or desired performance. Can be thought of as ‘the gap between where we are now and where we want to be’.

Hotfix Code (sometimes called a patch) that fixes a bug in a product. Often deployed in an ad-hoc fashion outside of the typical release cycle.

Integration The process of linking together different computing systems and software applications physically or functionally, to act as a coordinated whole.

LOC “Lines of Code” A number that represents how many lines of code a given application is. Generally, a meaningless measurement as the same programme could be broken into lines in many different ways.

Lean Creating more value for customers with fewer resources. Understanding customer value and focusing key processes.

MVP “Minimum Viable Product” A product which has just enough features to gather validated learning about the product and its continued development. The opposite of an upfront large feature set with no validation of how useful these features will be.

Open Source Software whose source code is available for modification or enhancement by anyone, as defined in their licence.

PaaS “Platform as a Service” A platform allowing customers to develop, run, and manage applications without the complexity of building and maintaining the infrastructure themselves.

Pair programming An Agile software development technique in which two programmers work together at one workstation. One programmer ‘drives’ the development while the other acts as a ‘navigator’.

Pull Request A method of submitting contributions to a project. This is done using a version control system (Git), and forms part of the process of doing code reviews.

ROI “Return on Investment” A calculation that defines the profitability of a project or a feature, based upon the cost of development and maintenance against the expected value generation.

Readme A file containing information about the given software project, forming part of its documentation.

Refactoring The process of restructuring existing computer code (changing the factoring), without changing its external behaviour. Part of decreasing technical debt, and improving maintainability.

Release The distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial generation of a new or upgraded application. With continuous delivery releases should happen often.

SCRUM An Agile software development model based on multiple small teams working in an intensive and interdependent manner. Outlines a set of best practices and processes for working in an Agile manner.

SaaS “Software as a Service” A software distribution model in which applications are hosted by a vendor or service provider and made available to customers over the internet. Often billed as like an ongoing utility.

Smoke Testing Non-exhaustive software testing, ascertaining that the most crucial functions of a program work, but not bothering with finer details.

SPA “Single page application” A type of web application that uses logic on the customer-side to manipulate and display data, often used in conjunction with an API.

Spike A time-boxed research activity. Usually used to explore different options of implementing ideas and systems and their pros and cons.

Sprint A regular, repeatable work cycle in Agile methodology during which work is completed and made ready for review. Purepoint typically uses two week sprints.

TCO “Total Cost of Ownership” The total direct and indirect costs of a system, including build, maintenance, training and operations.

TDD “Test Driven Development” A method of software development in which unit testing is repeatedly done on source code. Simply put specifications are converted into tests and code built to pass those tests.

Technical Debt A concept in programming that reflects the extra development work that arises when code that solved problems in the short run is used, which may not be best for the overall solution. Often goes hand in hand with feature creep, or changing specifications.

Timebox Allocating a fixed time period to a planned activity.

Unit Testing A software development process in which the smallest testable parts of an application, called units, are individually and independently scrutinized for proper operation. Unit testing is often automated but it can also be done manually.

UX “User Experience” Encompasses all aspects of the end-user’s interaction with the company, its services, and its products.

Vanity Metric A metric that inflates a company’s ego but doesn’t measure anything useful. Things like registered users, downloads, and raw page views. They are easily manipulated and do not necessarily correlate to the numbers that truly matter: active users, engagement, cost per customer acquisition, and ultimately revenues and profits.

QCon London

QCon London is a conference for senior software engineers and architects on the patterns, practices, and use cases leveraged by the world’s most innovative.

March 4-6, 2019 Find out more