Group Code Review :

As part of CodeCAT (an area under the umbrella initiative we have at Mindfire called Catalyst – an initiative to improve competency of every person involved in software development) we have been doing code reviews regularly. After every review we post the findings in GPS (our company’s intranet) so that everyone else in the company can go through the review and get to learn from that.

In the beginning the enthusiasm was there but over time what we observed is that mostly people do not go through other’s code reviews. So the intent of spreading the knowledge of one code review (which is typically a one to one session) to many others was not being met. I started taking awareness sessions for all people in batches – things improved after that but not as much as we would have loved it to be. Something had to be done !!

Since we were clear on two basics things – one is the quality of code review being done was good and second was we were sure what we needed to improve,i.e spreading the knowledge of one review with others. This awareness of our strength and area of improvement helped us in coming up with an effective solution. We decided to start “Group Code Review” – call 5-10 developers to a room and have 1-2 code reviewers, pick 1-2 projects randomly and start doing a code review there itself. The intent was to spread knowledge and sensitize people not to repeat silly mistakes.

We anticipated that people might object to this way of review so what we did is we started collecting opinion/views from the codeCAT team members(of 25 persons). We had a lot of discussions on the pros and cons of having something like this – people might like it or might not.

After a lot of discussions we finally agreed that since our primary intent is to spread knowledge among more people and at the same time ensure that reviewees take up code review comments seriously and work on improving their code quality – what we decided to do is have the first round of group code reviews done team wise and by the team lead (the team lead had the flexibility to call other reviewers too). So instead of the earlier plan where we thought to call randomly 10 people working in one technology (but in different teams) and have 1-2 codeCATs assigned who in the meeting itself pick out few people for review, we called people working in 1 team for review. Since the concept was new to start with – we realized the earlier approach will not work because people might not feel comfortable. So we called 7-8 people working in 1 team to a room and got the code of 1-2 persons reviewed by the team lead (if he happens to be a CodeCAT – in the first phase we called teams whose team leads were CodeCATs). The review session was used as a forum to not only identify mistakes done by developers but also was used as an interactive discussion forum where people got a chance to ask questions and understand why something will not work and what changes need to be done to make it work.

So far the feedback from the team members, who participated in the reviews , has been positive and people seem to be liking it. Ofcourse the next round of reviews will be a little challenging when we pick groups of 8-9 people randomly and assign a reviewer who they have not worked with. I will keep you posted on what our findings are after we do that plus things that should be taken care of to make group review more successful.

Author – Atma Prakash Ojha

I have often been asked why we are named “Mindfire” – what does it mean?

When I decided in 1999 to create an organization focused on software development, several candidate names cropped up. I was very clear that the name had to embody the factors and spirit of software development success, based on my observations of this industry that I was and am so passionate about.

Numerous names were tossed around. I felt “Mindfire” hit bullseye.

In any field of human endeavor – bull-fighting or buildings, singing or software – nothing succeeds unless you have a balance between “mind” and “fire” – between the smarts required to do something and the action orientation required to do anything. However the criticality of this balance is perhaps the most intense in the field of software.

In software organizations, I had observed two causes of failure. On one hand, you had young and intelligent people who had the raw “intelligence”, but didn’t have an adequate action orientation toward actually doing things, learning things, delivering things – that killer instinct would be missing. On the other hand, you also had a terribly large number of people who would run around being “visibly loud”, doing things and lot of things with a lot of “fire” – but who perhaps did not have sufficiently sharp minds required in software development.

Obviously, I wanted everyone who joined Mindfire to succeed greatly in their careers. For this, our organization had to constantly remind them about this balance between mind and fire that was key for them to succeed in their chosen career. And what better way than to name ourselves accordingly!

Hence, Mindfire.

PS: Having observed hundreds of software engineers in the last 11 years at Mindfire, I have come across a new rare species which makes me feel the name needs an addition. A couple engineers had both the mind and the fire in place, but thoughts and movement in the wrong direction! So today I would perhaps call ourselves “MindFireArrow”: to succeed in software development you need to have mind and fire in equal measure, and both pointed in the right direction.

Author – Chinmoy Panda

Ever wondered why idol worship as a concept came into existence. If as our scriptures say that GOD is omnipresent then why was a place of worship created and why inside that a figurine of God put ?

I think it was done because to imagine God and pray in open space was not working out for people, they needed a face to imagine and a symbol or idol to look at and then attach the same reverence and awe that they had for the internal belief called God. In short we as human beings externalized our internal belief and source of inspiration so that we can easily connect with it on a frequent basis.

Point is why am I saying all this ?

I wanted to draw a correlation to another place (which is also called as a place of worship) and the need to externalize our social recognition so that we derive pride from it easily and regularly. All of us work at some place or the other and might be all or some of us would be proud to be working at that place. We are convinced that it is a good place to work and we feel proud to be there. Problem or insecurity creeps in when the name of the work place is not famous in the outside world. Whenever you move out of office and talk about your workplace and the work that you do and do not see the respect or pride in other persons eyes or behavior your social ego is badly hurt. Some of us who are more mature and who do not need someone else’s appreciation to move on in life and be happy, manage easily but for the rest of us self doubt and frustration creeps in. We tend to distrust the company/office and feel cheated or we might just decide to leave since it does not give us the recognition that we are craving for. Hurts all the more when your near and dear ones hesitate talking about your workplace because they do not feel proud saying it.

Here comes the need to externalize the brand and the values or things that you like about your office or workplace. As the brand building gathers momentum and becomes famous in itself you realize that it makes your life all the more easier. Now your social ego is massaged nicely – you just say the place you work and rest of the things are taken care of by the person you are talking to.

Even though technically it is still the same place and the same values and work standards that you are maintaining but suddenly you feel more worthy because others feel that way. Of course for the persons who were matured enough to feel good without the brand externalization hardly see the difference, they felt good earlier and would continue feeling that way.

The intent of my writing this article was to explain the concept of brand building keeping in mind the effect it has in boosting morale of people. Of course there are a host of other areas for which brand building is used for but I have tried to explain only one aspect of it.

Now the question I want to ask is – do we actually need to externalize our self respect so as to derive social recognition or just let the way things are and convince ourselves that it hardly matters what others think about us ? Please share your views.

Author – Atma Prakash Ojha

The pace at which technology is advancing and tools are being built I think in future the role of software engineer will go through a major change. Smart tools will ensure that you need not know the syntax of a language or the inner workings of how it will interact with the database server etc etc. All you would need to be a good software programmer are tons of aptitude and a thorough understanding of the business for which the application is being built.

A typical developer would not necessarily be someone who has worked on a particular technology for 5-6 years rather it would be someone who has worked in a particular business domain for 4-5 years. Unlike at present where we need people to learn and keep themselves updated about the technology they work in, say someone who claims to be an expert in .Net should know what new features .Net framework 4.0 has , going forward a software developer would need to be updated on all the applications of every technology that are in the market and which one has what good feature – from usage in business point of view. He would not be required to learn the nitty-gritty of a technology rather he would be required to learn and be updated on the features that any technology has and should have the aptitude to use the one that suits the requirement best. Every company would have only a handful of network/IT support guys to take care of the system configuration needs.

In such a scenario the role of a typical tester (in terms of the work that she does at present) gets blurred somewhere. Since the developer’s scope of work would encroach upon the testers work she has to innovate to be of good use in the software development process. In fact the future would be more favorable for testers because of their expertise on application knowledge, of course only those who have build a thorough expertise on the domain they work in and have kept themselves updated on all the different technologies that are available in the market will excel. The fact is there would not be separate roles of developers and testers – we will have only system and application specialists. Anyone who is abreast of new technologies and has a strong knowledge on 1-2 business area will rule.

Keeping such a scenario in mind I think the current testers should start preparing themselves for the future by focusing on broad system knowledge rather than knowing the syntax of only one language. Someone at present who is into testing a banking application which is built in .Net might think she has to learn about banking domain as well as something about .Net to be an expert tester but that need will no more be there in future. She would need to know about banking domain and in addition should know what the system architecture demands and which technology in the market caters to it. Development of tools and addition of developer friendly features ensure that you need not be an expert syntactically to write your application using their language rather all you need is aptitude and awareness of the features of the technology itself – so learning about these things would help.

Author – Atma Prakash Ojha