GetInstance Ltd was formed in 2014 by Matt Zandstra. Small and agile by design, the company nevertheless expands to meet challenges for clients. At the time of this writing, we have team members in six countries spread across four continents.
Our approach is professional but decidedly non-corporate. We love writing code and designing systems. We believe work should be playful and creative – partly because it’s more fun that way and partly because that’s how you build a better mousetrap.
What We Do
We build things on the Web. We’re a full stack company, which means we design dynamic server applications and the Web interfaces that talk to them. We also specialise in taking on and improving legacy architecture. There’s a lot of functional but creaky code out there and we know that it’s not always possible – or advisable – to throw it all away and start again.
We create machines that take input, process information, get stuff done, and report back to users. What that ‘stuff’ ends up being depends upon our clients – it could be a purchasing system, a directory management environment, a document repository, a tool for generating writing exercises. That’s what is exciting about what we do – we get to play every day and make that stuff happen.
Development, Testing, Deployment Best Practices
A user clicks a button. A component sends a message. Another receives the message and sets off a process, itself made up multiple messages and actions – a cascade of causes and effects. These are individually entirely predictable but collectively prone to chaos. That’s because as soon as a system grows beyond a few participants, the chances of an unintended consequence begin to grow. We build automated testing and deployment systems to minimise risk at the same time as maximising productivity. In plain English, that means that our code gets put through its paces in all sorts of ways before it goes live.
Improve and Extend Legacy Systems
Like all developers, we love to build architecture from scratch. Very often, though, when we take on a project we inherit venerable stacks of code that have been in place for years – sometimes decades. While it’s tempting to pull everything down and start again, that option is rarely economically or practically viable. Even a deep overhaul of the code can be problematic. Clients understandably want to pay for features and not intangible improvements. So we have become adept at improving code design on a rolling basis. We adopt a strict policy that every commit must make the system safer, easier to work with, more efficient as well as delivering the measurable value a client needs. Over a relatively short time the benefits of this approach become clear as bugs and niggles begin to drop away.
Part of getting projects finished is deciding what gets worked on when and by whom. Like all serious developers we must balance business needs with development requirements, available resources and budget. We are pragmatically agile. This means we work with clients to prioritise the business backlog, create sprints, and then get out of our developers’ way as far as possible. Why pragmatic? We have noticed that in some quarters agile tools and techniques have been increasingly fetishised, making working life a scrutinised, file-carded, acronym-infested hellscape. That’s not our style.
We write documentation. We have also been known to write books about code.
Why We Do It
We do it because we’re good at it, because our work is creative and playful (that’s where we came in). Coding is a craft and what we produce should have both utility and beauty. Good code should ring when you knock it, it should weigh in with just the right heft, it should fit perfectly in the palm, it should be extravagantly sparse. Striking out for that is not a bad way to spend your time.