About Mujtaba Hussain

Software Developer at realestate.com.au. Ardent rock climber, long distance runner and cricketer. Passionate about geometry, algorithms, persian poetry and test cricket. Loves to climb at the Sundeck Valley in Grampians, Australia.

Acquisition, Ownership, and Migration of Legacy Applications

Recently, I presented a talk at the DevOpsDays conference in Brisbane, Australia on how a team of people can utilise the best of DevOPS to deal with legacy applications. Specifically how migration, ownership, maintenance and handover of legacy applications can be handled.

The below video is a tale of such a journey that my team undertook recently.

DevOpsDays Brisbane 2014 – Mujtaba Hussain – Acquisition, Ownership, and Migration of Legacy Applications from devopsdays on Vimeo.

Git as a hiring tool

The greatest resource of any company are the people who work for it. Therefore the process by which you hire the people who work for or with you, is extremely important. At REA Tech we have always been keen on trialling new ways of hiring people. We have played around for years with utilities such as codility.com, sample algorithm questions, and even the one hour pairing session with tech leads and other software developers for a substantial amount of time on a business feature. We in the Media and Developer team decided to try and use Git as a means of sorting out the initial set of candidates before bringing them in for the face to face interview. Git is a wonderful version control system designed by Linus Torvalds and one of its features is the history of changes it keeps. This is the most critical feature of Git we chose to use as a candidate sieve.

The purpose of the initial test is to ensure that the person who has applied is indeed a skilled software developer. Previously we have used Codility for that, but in my opinion, the information that it conveys is limited. You only see a very narrow window of the persons technical expertise and whats worse you are limiting them in terms of time. You want the person to perform to the best of his/her abilities and for that reason, you need to give a bit of leeway in terms of what time can they have to do the test and also, the format of the question. To that regard, we decided to reorder our interview test.

Continue reading

Your build information on your android device!

The healthy competition that prevails in the mobile industry today is primarily between iOS and Android. This competition is mainly fuelled by the number of applications written for both operating systems by developers across the world. Both have their unique features which most applications attempt to exploit. Recently, after coming back from here and hence decided that I should attempt to begin with android and write an application that I would want to use day in and day out! From this thought process, emerged “Blamer“.

We are firm believers in Test Driven Development and one of the main tenets of TDD is quick feedback. Keeping this in mind, I recently wrote the above mentioned Android Application.

It connects to your Jenkins CI server and downloads information about the builds. It does not connect to any other CI server yet but I am working on it!

You can individually step into broken builds and see how, why and when they failed and if the person whose commit broke the build exists in your phone book, you can actually SMS them about the failure.

The application is available on the android market and the source code is freely available on my GitHub account.

Feel free to fork the code and contribute. Any comments and/or feedback will be most welcome.

devops, and associated thoughts!

Here at REA, we have been firm believers in accountability of work, from the inception to delivery! To cement this idea, we instituted the concept of devops here some months ago, were a dedicated OPS person would co locate with the development teams for particular projects and be just like another developer. Conversely, a developer from one of the teams would colocate with the Operations team and experience being a systems administrator. The reasons were to get members of both teams aware of the fine grained issues and complexities that develop within the processes of development and/or deployment. We frequently rotated the personnel through this process to better spread the lessons learnt. Being an observer of this process, I have come to a few conclusions.

1. One person cannot be a ‘devops’ person.

It is not possible to have one person in a position where he/she is expected to do deployment and development while all others are expected to do only one of the above. The responsibility, and thats what it is, has to be shared across the team. It is the responsibility of the entire team to ensure that that the delivered product works in production, and not just one person.

2. It is a mentality, not a position.

It should not be marketed as position to slot one person in, or even rotate people through. A software developer who writes the code should be as concerned about his/her code working in production as he/she is in development. Definitely operations are more experienced with deployment and maintenance of products in production like environments, but that does not mean a developer should not base his software decisions before being aware of implications of deploying it in production, or be unaware of the status of his code after it passes quality assurance. The thinking behind devops is the critical bit of software development.

3. Operations need to be consulted early and often.

Operations are somehow considered as the team to call in last, when you have your product ready or almost ready. That in my humble opinion, is a fallacy. They need to be involved in every inception, every retrospective and every card kick off as any other team member. Their thoughts are most invaluable as they will look at a piece of work, not as whether it can be done, but whether it should be done based on the present state of production; whether there are some inherent dependencies that need to be resolved. Not only will this ensure that software developers will start writing software with production in mind, rather than their own laptop, but also the fact that this will spread the knowledge of state of production to people who might not have it to begin with.

devops is not a magical word that resolves our issues of deployment, dependencies etc, but it does get us started on the road of understanding that we are working to deploy to a production box, not our own laptops; and it is the responsibility of everyone involved to make sure that happens, and not just one lone person.

Innovation Day, March 2011.

At realestate.com.au, we are committed to several core values that drive our business and keep us ahead in the market; both in terms of business value that we deliver and also the quality of the products.

One of our core values is innovation. We, as a company, are committed to innovation and provide an avenue for the entire business to take some time during business hours and try and do something with our products, processes or even the way we think about it, and turn it into something different. As a means of realising this, we have instituted “Innovation Day”. A day and half every quarter to do what you will with existing or new products, processes or tools and turn it into something interesting and/or useful for the business.

Recently, we had our first innovation day for this year, on 31st of March, 1st of April , 2011. The participation was vigorous and all the Q/A sessions involving each presentation were very in depth and illuminating. One of the most pleasing aspects of the presentation was how well thought out the future scope was, for each idea. Hopefully, we will soon be able to put these ideas into business practice.

Some pictures from the event:

Thanks to all the people who participated in this event and to all those who facilitated it.

Special thanks to Sam Weller and Mike Breeze for organising one of the best innovation days this company has had.