We’re a leading technical agency in Sydney, Australia. This page should tell you all you need to know about us and more. To start with, we have a core team of 35 – a mix of developers, designers and project managers. For technology, we use Ruby on Rails and AngularJS. We apply the Agile project methodology.
We’ve been around for a while (+18y) and in that time have worked on a wide variety of projects. Picking up quite a bit of know how and experience along the way. We specialise in creating and building Digital Products.
Spoiler alert: this page goes on for ever. No seriously, it does. You need to be a real fan to read it all. If you’re short on time you might want to check out the 6 questions we often get asked, some things we’ve made, or a handy map in case you need to plan out where you’ll land your helicopter.
OK, so you might have arrived here asking yourself “how are these guys different to X?”. Well, it depends on exactly who or what X is, but here are some “X”s that we run into:
We’ll provide you advice and strategy based on knowledge and experience, rather than some blog we read. And if we’re not sure we take some time to actually look into it (rather than blindly trust technology vendors).
Because we can communicate clearly. We get it. We aim to learn very quickly more about your business or idea than you do. And we can conceptualise and build it.
Especially for complex projects, we know how critical it is that everyone has the same understanding of a project. Agile relies on having meaningful conversations rather than endless documentation, circular conversations and change requests.
Because we can scale. And we know how to build things that do scale. Scale might mean more traffic or higher transactions. Or it might mean more features. Or it could mean different types of team resources – like more developers, more design, or more project management.
We form close relationships with our clients creating dedicating teams to maximise communication and results. Each client has a dedicated team. Everyone on the team is an expert in their respective area. No passengers. The team uses the Agile methodology to deliver ideas, strategy, design and code. They strive to be as efficient as possible – lets not waste each other’s time or money.
Each of the teams focus on delivering projects that we know from experience will work. Our tools back this up.
Often we see ideas and executions from one team being applied on other projects. So that new way of running ideation sessions, that great mobile strategy, or the idea that halved page load time gets re-used once it’s been proven. Team members develop specific expertise, and they get shifted from team to team as those skills are required.
We share ideas and improvements via “standup” sessions and agile retrospectives. Transparency is key.
This all might seem a bit strange if you’re used to dealing with traditional ad agencies or digital agencies. We don’t have junior account people. And we most definitely don’t have people who cause you to wonder what exactly they do again and why are they on your project.
Result = a core set of competencies resulting in timely correct decisions made by knowledgeable staff.
We’ve got some relatively large clients & sites that we’ve been working with for a while. We specialise in a way of building these sites called Ruby on Rails. It helps us make things more efficiently and with greater reliability.
We use it to build
Why should it matter to you how we build a site? Well, there are a gazillion “ways” you could make a web project- WordPress, dotNet, Joomla, etc. Rails is just one. It just happens to be a very good way to build complex projects. Rather than being just OK in a variety of “ways”, we’ve chosen to focus on being experts in one – Ruby on Rails. It turns out that not only is it a great programming language for making web sites, it helps us work in a very Agile way, radically improve reliability and have a fully automated testing process.
Go back 10 years, Red Ant used to dabble in a bit of everything from ASP to dotNet to PHP. We paid many thousands of dollars to be fully certified Microsoft blah blah consultants of this and that. A few of our sites became quite popular, and we realised the tools we were using and our approach really wasn’t cutting it. These sites were failing under load, becoming more expensive to run and more complex to maintain.
We weren’t using these tools out of a conscious choice. Somehow it had just become that way depending on what our clients were already using.
So we stopped, thought about what we wanted, and changed tack. We had a careful look around at how other people were designing and building sites, and what kind of technologies were being used to make really big, really interesting and engaging sites. Spoiler alert: it wasn’t dotNet.
We ended up choosing Ruby on Rails, as it suits the kind of stuff we like to do. Not only does it help us make highly interactive and dynamic sites, it also has a lot of really well thought out processes baked in. These lower our project risk – because no matter how awesome your rockstar developers are, they will make mistakes. Having processes, like automated tests and deployment processes, mitigates this by giving us a way of doing something right, and then repeating it flawlessly again and again.
Read more about why we use Rails here
Ask pretty much any agency if they can help you with digital strategy and ideas, and the answer will probably be yes. Come to think of it, these days you could probably ask anyone you meet and they’re likely to have an opinion about your site and what you should be doing.
But there is a big gap between the talking and the doing. Especially in digital, so much rides on experience and a deep understanding of technology. Good luck to you if the agency advising you has little direct experience in the “doing” and subcontracts the actual work to someone else- I’m sure you’ll get a fantastic looking something.
You might have heard of the story of the Fat Smoker. He is really fat, and he smokes. He’d like to live a long and happy life, so he asks various people what strategy follow. Everyone advises slightly differently, but they are essentially variations of the same thing: he should lose weight and stop smoking.
Unfortunately that is the obvious bit. The glib strategy, the easy part. Knowing the strategy in basic terms is very different from having a strategy which can actually work.
To achieve weight loss and giving up smoking, he’ll need some specific plans and tools. This might need to be adjusted along the way- what worked to help lose the first 5kg might be different to what works for the last 5kg.
So really doing it – losing the weight, keeping it off, and giving up smoking – is the hard bit.
We can help you with that hard bit.
You might have heard about Agile and wondered what it is all about.
Agile is a way of defining a project with the end user in mind. Say we were designing an aeroplane, the definition wouldn’t be about making an aluminium tube with flat things sticking out. Rather, it would focus on user requirement- eg something which can get 300 people from Sydney to Tokyo within a day.
It also involves breaking work up into a series of “sprints” – at the end of each sprint we’re aiming to achieve certain goals.
Agile also involves the client, via a technique called “showcasing”. This is where we regularly meet to review the site as it takes shape, rather than having a big “tadaaa” moment at the end. Instead of putting effort into making a big specification document at the start, we focus on having meaningful ongoing conversations about how things should work. Along with overall strategy, we know the project may change as things develop- something that seemed sensible at the start might be done better another way.
One of the best analogies I’ve heard about Agile is a military one.
Non-Agile: think WWI – the Generals would plan out their campaign months in advance. Orders were written out in great detail along with intricate maps, and sent to the troops. At the designated time, thousands of troops would rally and carry out these orders. Disobeying an order will get you shot. The Generals might not hear about progress and result for hours- sometimes days later.
Agile: think modern warfare, with much smaller, highly trained teams that move quickly. The overall objective is defined as getting to that hill, and this is simply and clearly defined and then discussed. Everyone in the team understands the critical bits, the “nice to haves” and the overall objective. But how the team actually gets to the hill is driven by the guys on the ground. New information might come to light during the day and the situation will change. They communicate regularly between each other, and back to command- all in real time.
Tests are an integral part of the way we work. When I say “test”, you might think that means we check work once it is finished. The easiest way to think of a “test” is as a way of describing how something should be. These get made into automated scripts, and in the course of a project we’ll make thousands of these and we can then check them continuously.
We follow a process called “test driven development”. What that means is rather than starting a project with a set of photoshop images, we try to describe what your site should be as a set of features. These core ideas then get fleshed out into more detailed features and wireframes, which become the start of our tests.
These tests check how something should be: what should happen when I visit that page or press that button? These tests gradually get added to and refined, until we are confident that if the tests are passing, the site works OK.
Think of these tests as kind of like those spikes that rock climbers tie their rope to. You might slip during the climb (the slip being some code change which inadvertently breaks a feature) but you won’t fall all the way back down.
To give an example of a test: your site might have members, and you want them to be able to log in and update their profile image and username.
Off the back of this, we could create a simple test, which checks that a user can indeed update their profile image and username. At the start this test will fail. But then a developer designs and builds a form so that a user can indeed log in and update this information. The test starts to pass.
The actual “tests” are scripts which mimic user behaviour to see if something is working. So one test might check the actual code to see if the form logic means it is editable. And another would fire up a virtual browser and pretend to be a real user- filling out their profile and saving an image.
Several months later, a developer makes a change which inadvertently hides the profile image- so users can no longer update their profiles. Which would really irritate some users. Which would be Bad.
But that simple test we had in place right from the start checks this. That test will fail even before the code is committed- alerting the developer to fix it.
If you’re down this far you’ve either fallen asleep and just woken up, or you’re interested in finding out more. You can see what we look like on our Flickr, you can stalk us on LinkedIn, Google+ or follow our Twitter. You can even walk around our office. Or you can simply pick up the phone and call us on (+61 2) 9267 8300.