As the business is always growing, finding time to write even the shortest of blog posts becomes more difficult, but as we are looking for more staff yet again to help solve our clients growth plans, I thought I cover some of our inventive ways we have dealt with growth, and how we differ from most other software development companies.
Developer driven
When I started the original consulting company over 10 years ago, I focused the work on software development which tried to solve complex problems and deliver maintainable systems that could grow over the years. If we needed design work, it would be either outsourced, or done in partnership with similarly focused companies. This means our business has long been based on repeat business from a group of growing companies
Over the last year as we have grown to three people, and still as busy as ever, that focus has become even more clear, as I have written before, our competitive environment consists mostly of design companies with limited interest in producing quality software, rather quickly throwing trash out the door, getting paid, and moving on to the next sucker.. (sometimes we get to clear up that mess...)
Applying software development to our own processes.
Our business is no different in many ways from our clients, we are always attempting to optimize our processes, reduce time spent on meaningless tasks and ensure that everyone is spending their time adding value to our clients businesses. In software development this involves a number of core pieces of infrastructure, Revision control, review systems, task tracking, time billing and accounting. The result and aim of these are two pronged, ensuring that the quality of work being produced is worth the money we are being paid for it, and making sure our clients are aware of their current and outstanding expenses.
While we have the above processes in place, they often are not applied in exactly the same way that the industry has come to expect. This is mainly due to the way that rather than going for off the shelf solutions to our problems, we have tended to develop the tools in-house (a great way to perfect your skills often). While this smacks of NIH (Not invented Here) syndrome, and I can not say that I do not worry about that sometimes, the result is that our processes drive the design of our tools rather that our tools designing our processes.
At present one of the key differences is our approach to the classic developer focus on task driven commits. As this blog has mentioned before, we do not do task driven commits (gitlive). Every single file save is committed into our revision control system. While this may sound a bit strange, It has significant benefits for all involved. After so many years of working I can not tell you how many times that work has been lost due to accidents. Since we are getting paid for this work, any possibility of loosing it would be costing us money (or if we where not so ethical, our clients, which sadly i suspect happens all to often in the industry.).
I have been considering for a while if we should merge this workflow into a more task driven commit methodology, but as what I though would be a short term fix, seems to have re-in-forced this idea that we should not go down that route. This short term fix was the concept of daily commit messages. In a normal task driven process, the commit that fixed the issue would be appended to the ticket (and frequently emailed for review), it could then be reviewed as the issue was signed off.
We did try this on one project, however what resulted was a constant back and forth on multiple issues, and a very time consuming review process. This using the most expensive resource in the company, senior developers. So in switching to daily diff's there was only the need to review the changes for each project. In this way it was also possible to communicate not only serious code fixes, but also advise on better practices. without having to throw that into a tracking system (Although email in some respects is always a tracking system).
The full stack experience
Our new staff over the last year have grown considerably, comming from a classic Hong Kong software development environment, they had ended up focused on a single area of the development process. They would work on projects for weeks and come back with a result, often having to persude, or wait on information from other teams working on a different area of the same project.
I regard this as one of the worst industry practices out here, so over the period they have been working at Roo J Solutions, they have been thrown in the deep end with every part of the standard development stack, front end, back end and database. Tasks are frequently day or even hour based, however working as a team now, they can pass the learning of the new tools around. Always having my knowledge as a good backup. To the suprise of someone who had worked on that team with them before, they not only did not sink, but swam very well being given new challenges.
So if this sounds like a interesting place to work and you or someone you know would like to be attacking our challenging new projects, please pass on the post or email me at jobs@roojs.com, with the usual information (If I have to tell you.....)
