Our ability to communicate over many different channels and distances has changed the landscape of how we work and socialise. When I was a kid we were unreachable until we got home near a landline. Now we have a myriad of ways of staying in touch. While this has annoying, distracting downsides, it opens up a new world for companies to engage in remote work solutions.
I started reinteractive as a 100% remote software development company. While not all businesses are suited to this model, I find that many software developers enjoy remote work.
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.
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.
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.
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.
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.
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.
When full time employees build software it is in their best interest to make sure that the project is successful. So they work hard to make sure the project is delivered on time, built as efficiently as possible and perhaps most importantly, is easy to maintain moving forward.
Often in the early stages of a specific project there is no need (and therefore no plan) to maintain the project going forward. Without oversight, the short term motivations of consultancies can lead to disastrous consequences for dealing with the app in the future. Let me share a story I have heard many times from people who tried to build a complex application on the cheap using a consultancy or contractor:
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.
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.
