We’re a technical agency in Sydney, Australia. Hopefully this page will tell you all you need to know about us and more. To start with, there are 30 Ants – a mix of designers, developers and project managers. We’ve been around for a while (15y) and in my humble opinion we do what we do pretty well.
We know that no matter how many rockstar developers & designers we have, awesome systems & processes are what really matter. That’s what drove us to use Rails, embrace Agile, and invest heavily in testing, Continuous Integration, and trying to do things better.
Spoiler alert: this page goes on for ever. No really, it does. If you’re short on time you might want to check out the 6 questions we often get asked, some things we’ve made, which tools we use, or a handy map in case you’ve come to stalk us.
Ruby on Rails
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
- Membership sites
- Reward point systems
- Content management
- Mobile sites and mobile applications
Why should that matter? 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 stuff. 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 5 or 6 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 blah blah 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 (another spoiler alert: we all really like what we 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.
We’re pretty experienced
We’ve been doing this for a while, and have quite a bit of experience in designing and developing interesting things for the web.
We’re always learning and improving the way we do stuff, but along the way we’ve had a chance to deal with lots of different problems and situations. We’re pretty process driven, and whenever possible we automate tasks (eg: testing if something works or publishing your site) so that it can be done again and again flawlessly.
Ideas and strategy
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 I’d argue 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 to do. Everyone advises slightly differently, but they are essentially variations of the same strategy: he should lose weight and stop smoking.
The problem is unfortunately that is the obvious bit. The glib strategy, the easy part. Knowing the strategy in basic terms is very different from having a plan to achieve it.
The strategy might also need to change along the way- what worked to help lose the first 5kg might be different to what works for the last 5kg.
So actually doing it – really losing the weight, keeping it off, and being able to give up smoking – is the really hard bit.
We can help you with that hard bit.
Our team: designers, developers and project managers
One of our strengths is that we can offer a blended team of people to work on a project – of designers, content people, developers and project managers that really know their stuff.
Designers work on the wireframes and visual layout, as well as front end markup.
Developers write the tests and code which runs the site
Content people create and manage both the site content as well as UGC
Project managers look after the process and manage budgets
Why should having a blended team matter to you? Put simply, an experienced, blended team will give you better results. That problem which at first glance seemed like a thorny technical issue might be better solved by a clearer UI. Maybe a better strategy around communicating to users before the update will make them more receptive.
If your team is heavily weighted with “creatives” (as can often happen with an ad agency or digital agency), you can end up with quite naive solutions to something better fixed with some smarter, better code. Likewise, for a team of just developers everything starts looking like a nail to be hit with the code hammer.
Size of team
Although we have a team of 30, a typical project would have a core of 3-4 people working on it. Depending on how you’d like to engage with us, this might be a dedicated or floating team. However, we also know that here on Planet Earth, emergencies do happen and there are situations where it can be incredibly useful to be able to throw lots of developers on a situation for short bursts.
Outsourcing?
Our model is very much that our team do the work- we know our projects inside out and take great pride in that.
Some agencies act as project managers, then use either freelancers or subcontract the actual work elsewhere, or offshore. We don’t, for a few reasons. First, the risk of miscommunication and crappy quality is too much (see the bit below on Agile). The people working on your project are the people you’ll meet in meetings and standups. Second, if something doesn’t work right, we made it and we’ll fix it – without seeming cheesy, our business is about long term relationships.
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 weeks 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.
Agile
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.
Tests
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.
Go live checks
Once a project is deployed, we make sure we keep an eye on things. Some of these checks are automated tests like before, while others involve watching key metrics like traffic, database throughput and overall error rate.
Again, the project team get alerts if something goes wrong, and we often know about issues before users do.
…and we keep on testing
Tests are great, but continuous integration is even better.
We use a process called Continuous Integration. In plain English, that means that every time there is any kind of change, all of the tests are run in a background process. This happens many times a day.
We use a tool called Jenkins to manage our continuous integration. Jenkins watches the code repository, and as soon as a change is made by a developer, Jenkins creates a new virtual version of your site, fills it with content, and then runs all of those tests. So your site is continually being checked and rechecked as the project progresses.
If all the tests pass, Jenkins will publish code to the server. If a test fails, the developer gets a rude email and the Jira issue gets a detailed comment on the various failings of said developer. Things can get quite personal…
What a typical project looks like
Our best projects are ongoing engagements, rather than a one off build. Clearly this won’t suit everyone- you may well have really valid reasons for wanting to engage a developer, have them design & build you a site, and have nothing more to do with them. Except from our experience over the years, these don’t work out that well. This approach might work with say making a TV commercial, where you can get it made and then play it again and again. But a web site is different- you’ll get feedback and learn what works and what doesn’t. An area might need to get redesigned to make it easier to understand, or refactored to make it run faster.
What we’re much better at and provide most value is when we’re involved over a longer period. This gives us a chance to learn and understand your business, your audience, and how things can best work. We can be Agile and continuously improve and refine everything from the strategy to how the site converts visitors. Something that initially seemed like a good idea can be adapted and improved based on what we’ve learnt. There might be new scenarios or competitors that we can quickly respond to.
This might sound like we’re advocating a totally reactive approach. A quick reactive response can help sometimes, but our approach is more about continually refining and improving. Not sticking with an idea just because it was there at the start- new information, experience gained and changed conditions mean ideas and features can often be improved.
A typical project would be a build of between 2-4 months to get to an initial “launchable product”. The actual work for this is be broken into a series of 1-2 week sprints, with a showcase so we can make sure we’re all on the same page. Post launch we’ll establish some key benchmarks and KPIs, and start tracking how things are going (with a goal to improve these over time). We’ll then start planning and working on feature improvements, rolling these out as a series of releases.
We use a tool called GitFlow to manage our development process. Your main project exists as a “master” version, and any small or urgent changes we call “Hot Fixes”. These are made to Master and deployed immediately to the live production servers. Longer work gets done as a “branch”, and as these approach completion they are tested and then integrated into a “Develop” version for final tests, and then into “Master”.
OK- so 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 or Street view, or follow our Twitter. Or you can simply pick up the phone and call us on (612) 9267 8300.