Blog

  • Mikel Lindsaar

    Top 10 Reasons to Outsource Development

    By Mikel Lindsaar,

    Today I was asked by a client to give them some reasons why they should outsource to reinteractive instead of hiring an in house team. They needed to convince their Board the pros and cons of setting up an internal software development team from scratch versus using reinteractive. The project under discussion was the implementation a bunch of key features for their platform as well as a partial rewrite of key aspects.

    Unsurprisingly, I've been asked this question several times by our clients, and my response has almost always been the same; do both.

  • Daniel Draper

    Our Code Review Guidelines

    By Daniel Draper,

    Here at reinteractive, we care deeply about the quality of our code. We have many processes in place to ensure that the code we produce for our clients is of the highest quality, one of which is a mandatory code review. Before any feature makes it into staging, it must be reviewed by at least one, and preferably two, other developers.

    To quote Wikipedia, a code review is a systematic examination of source code. It is intended to find mistakes overlooked in the initial development phase, improving the overall quality of software.

  • reinteractive

    State Library – Recognition of Excellence for Innovation & Disruptive use of Technology

    By reinteractive,

    The State Library of NSW’s innovative approach to engage online volunteers has received an Excellence award for Innovation and Disruptive use of technology by OpenGOV Asia in a recent awards ceremony.

    award.jpg

  • reinteractive

    A holistic approach to your web application

    By reinteractive,

    Back in 1976, the idea of personal computing was somewhat different to that of today. The Apple I computer sold 175 units, and was considered revolutionary for its time. It came with one small catch – you had to build your own case.

    A modern comparison to the original Apple I computer would be the raspberry pi, which has sold an impressive 12.5 million units. It too, requires you to build your own case.

  • Mikel Lindsaar

    What Makes a Great Developer?

    By Mikel Lindsaar,

    I must say, it made me smile when I heard of a prospective client who called in last week saying, “I’ve been looking to hire a senior Rails developer and you guys seem to have all the best ones.” Now, of course we will work with her to fill in any gaps and help her onboard new developers, as we have done for many other clients.

    But it really validates our hard work to create a workplace that attracts some of the top talent in the country. We pride ourselves on our approach to remote work, team accomplishment and happiness.

  • Kane Hooper

    Geolocation – Driving Marketing with Personalised Messages

    By Kane Hooper,

    You don’t have to be Uber or Google to make use of the GPS chips that exist in mobile devices. With so many marketing messages vying for attention, smart marketers can look to geolocation to keep their messages relevant and timely — so they cut through the clutter and create conversions.

    iStock-512303306-art-web.jpg

  • Mikel Lindsaar

    Why Ruby on Rails is still the best choice?

    By Mikel Lindsaar,

    why-rails.jpg

    A few days ago a prospective client asked "Why do you use Ruby on Rails?" and I told them a simple answer. Profitability and Productivity.

  • Andrew Jennings

    Transparency in Software Development

    By Andrew Jennings,

    Software has been around for more than fifty years and there have been a lot of learnings generated in how to best manage the process of building software. Before the internet it was quite common for a large software project to be initiated, worked on and completed without more than a handful of people knowing what was going on. This lack of transparency led to many dissatisfied stakeholders and sometimes even the software being taken to the trash upon delivery. How do modern software practices avoid the pitfalls of black box software development?

    At reinteractive we use Pivotal Tracker to get all of the features translated into User Stories that are clear for the developer to implement. Once a User Story is completed by the developer the User Story must be accepted by the Product Owner. The Product Owner is the person who decides what the features should and should not do and has ultimate authority. If the Product Owner rejects the developers work Pivotal Tracker will notify the developer that the User Story is reopened and the developer will then attack the User Story again. It is very important for the User Stories to be accepted or rejected quickly because a developer will only hold a complete understanding of the code for a short amount of time.

  • Kane Hooper

    How do you Successfully Manage a Software Development Project?

    By Kane Hooper,

    A Top MBA Graduate's Experience with Software Development.

    I’ve been with reinteractive now for just over 6 months and it has been both an exciting experience and quite a learning curve.

  • Ildikó Tuck

    What exactly is a UX review? Do we need it?

    By Ildikó Tuck,

    Lately, I’ve received a few questions about what a user experience review / heuristic review or evaluation / UX expert review is and isn’t and when it’s a good idea to have one. I thought I’d share a few of the questions and answers on what it is, what you can expect from it and roughly what sort of commitment it requires from a businesses’ viewpoint.

    Let’s start with the common element in all three of the above-mentioned names for it. Yes, it’s a review. It evaluates an existing system against best-practices in the industry. It is performed by an expert in user experience design or Human Computer Interaction (HCI) and results in a report with key findings and action items that you can use to improve your product. It’s a so-called “inspection method” because it doesn’t involve users but it is based on principles derived from watching users interact with online systems. It results in a list of issues found and ranked by severity - usually a scale of 5 (minor, low, moderate, high, critical), but some UX designers use a different system.