Engineer supposed to join does not turn up without information

Last month, after around 4 weeks of interviewing we zeroed down on an engineer and gave him an offer letter. He came and accepted it and also accepted the terms and conditons which included a 12 month compulsory stay with the organization. He talked, discussed, shared email ids. He responded with all needed documents to HR but during the 30 days between the offer letter and joining date kept us in the dark as to his intentions.

A day prior to his joining all email-Ids, domain login, machine was setup and this fellow did not turn up. Today after 10 weeks we still do not have engineer on board. This is hugely disappointing. I wish he had been professional enough to have informed us and so that we could have searched for a new candidate.

I have no ideas, how to avoid such situations and I do not want to lift the 12 month compulsory stay terms & conditions as I believe that we as an organization invest enough in an individual that he should commit to this minimal time frame. We do not hide any details as to what we do, what platforms we work on, type of work etc.

My thoughts are weening towards hiring Interns --- at least they assure me of 6 months availability and then give offers to the top ones at the end. By that time the intern has seen the working of the organization and can take a quick decision to join or not. Given the resources that I see during the interviews, I think this is also a good way to give back to the society at large – an engineer who is ready for the Industry. I will blog about the experience later ...

Continuous Learning, and Quicker Delivery

I consider that there is a strong relation between “Continous Learning” and “Quicker Delivery”.

Most of the time projects / products or a company's /team's usage of technologies is a set of few items. With the areas of work defined it should be every team member's endeavour to master these areas so that when new tasks come up the team member's have broad knowledge if not in depth knowledge of how they are to be accomplished.

My peeve against majority of software professionals is that they do not spend this time learning and end of the appraisal we find that we can still not do tasks faster or with higher quality leading to frustration of the “Product Owner” who expects improvements for the yearly financial raise provided. This also leads to individuals who have “gained experience in number of years”, but not in type and complexity of tasks performed.

One of the reasons provided by the individuals is that they do not get any time. Unfortunately, even on teams that I have restricted to 45hrs a week work these reasons are spoken of. I feel it is a necessity of all software professionals to continously learn so that they do not forget the “art of learning” and in the process become obsolete in the times to come.

Should Developers Buffer Estimates?

We use a typical Agile methodology during software development. During Iteration Planning engineers want to buffer/pad their estimates. Their logic is that something may come up! This leads to:

• Obviously, bloated estimates.
• Bloated estimates even on predictable tasks.
• No visibility to what type of issues we tend to miss out while estimating (as everything is lost in the buffers)
• Work expands to fill the time we have.
• Reduction/Destruction of trust with the Product Owner.

My questions against this is How do you know that the buffer you are keeping is adequate for “something may come up? How can you estimate an unknown? My recommendation is to base the estimates on the current knoweldge of tasks and its delivery with Quality. For other things that crop up we manage as and when we see the unknown.

If an unknown does crop up the “rule of the book” is that the Product Owner should be considerate enough to drop the low priority user stories. But the reality is that many of the Product Owners do not agree. The role of the Scrum Master at this time is to convince the PO or move the equivalent tasks to the next Iteration. This does not come easy to non-Agile PO practitioners but is the only way to prevent drop in Quality of tasks or slippage of schedules.

One way to make this scope adjustment easy was used in one of my previous organizations by marking the features as “Must Have”, “Should Have”, “Nice to Have”. My issue with this is that this again leads to “Work expands to Fill In the Time”. The devlopment team ends up consuming most of the time in “Must Haves” and scope adjustment needs to be done there.

The retrospectives at the end of Iteration are the right time to relook closely at those tasks where we did a bad estimate / found unknowns to find what type of issues/work we tend to overlook. This is the learning which if taken forward helps the team to do better estimates as well as points to development/learning areas for a team.

In a nutshell bufferring brings opaqueness to the development process and needs to be avoided.

As a side note one of my engineers came up with – buffering is also done because it is driven by the year end Appraisal process which may have heavy weightage for “Timeliness of tasks”. The fix for that lies both with the engineer and his manager. The manager and engineer should collaborate to see where the estimation errors come from and thus over a one year appraisal cycle we should see statistical averaging helping in some tasks finished ahead of schedule and a few late but overall project timelines being met.

How a new joiner can get to speed quickly...

As per my experience there is a big chasm between the academics and the Software Development industry in India. I have my theory for why it exists (a topic for a seperate blog).

But, I do wish that the new engineers that are recruited (some of them months in advance from campuses) spend some time getting ready for the industry before arriving on their new jobs. I have seen many engineers who may have scored high in aptitude tests etc. arrive on their jobs with no effort put in to get ready for the work. Many of them have the attitude “employers should provide training”. This may be fine with those who join the big companies like Infosys, TCS, Wipro who can pamper them for some months before assigning tasks but for the majority of smaller sized companies in India it is discouraging to see this attitude.

Following is my wish-list from a new joiner:

• Should have basic knowledge of the languages that the organisation works with (this must have been told during the interview or asked/researched by the person).


• Should know and used at least one Version Control System.


• Should have a “team mentality” instead of being an individual player.


• Should know when “he is stuck” or “when he needs help”.


• Should interact and communicate with peers and superiors (also helps out in 4).


• Should use the platforms provided in the organisations (meetings, information sharing sessions etc.) to expand his skills.


• Be passionate about any task assigned. Yes, you would some day architect a huge application, but you will have to prove your worth in smaller tasks first.


• Be open to challenging (though with facts & figures) ideas, processes followed.

Unfortunately I find many a times these skills lacking even in experienced candidates. If these points are conciously taken care the person would quickly feel at home in his new assignment and start liking the work and being effective quickly.

The Code Review Checklist

When a new Developer joins a team and is ready to handle tasks the next milestone for him is, to do a commit in the version control system for code. I remember being part of a team in which the code review process was so complex that when a new developer could first get it through what we called Pre-bouncers and Code Bouncers the individual used to treat everyone on the team with a Samosa or chocolates.

Though the code review should not be a very complex process it does have its advantages of preventing build failures with preventable code mistakes that your peer could easily find. Over this advantage I always felt that the greater advantage was - the communication between the engineers. The person whose code was being reviewed started to see what and how the Code Reviewer looks at the code and its side effects. It also helped transfer the coding best practices. In case of a Code Review being done by a Senior Developer it also started to set up a reputation for the junior Developers.

Though the Code Review cannot prevent all the problems it does set a minimum level bar for the code going to the version control system. The Code Reviewer should be called in only after all Unit Tests pass and the developer has done testing and step-through of his code changes. Following are the points that our Code Reviewer takes care of:

1. The code passes the Code Reviewers hallway testing.


2. The code should not be repeated at multiple places. An experienced hand can point to other places where similiar code may exist or can be easily refactored to accommodate the changes.


3. The code does not break the encapsulation of modules or introduce wrong dependencies.


4. The code is maintainable and readable with proper variable/function/class names.


5. The variables/functions and classes are at the minimal scope and visibility possible.


6. The code should be minimal lines without being esoteric.


7. The code should be commented at all places where an average developer needs to think hard as to what it does.


8. There should be no hard coding of magic numbers


9. There should be nothing in the code which prevents the same created build to operate on local machine, staging and production environment.


10. The code does not introduce obvious inefficient constructs.


11. The code written is always internationalized.

As you may observe all these are language/technology agnostic we have applied them with C++ and now in Java enterprise. What else do you think needs to be added without restricting engineer's creativity or making Code Review a complex process?

Inducting A New Employee (Software Developer)

In India there are two category of companies the big ones like Infosys, Wipro, TCS etc. who have considerable strength in their training departments and thus can layout training regimens that make the new joinee confortable. These companies have enough bench strength too, that allows ample time for a person to get up to speed. On the other hand are the majority of smaller size companies which cannot afford such a setup but still have to perform equal complexity tasks on tight schedules and resources.

I am now a days part of an organization which falls in the second category. We aim to quickly provide all data for the individual to start contributing. Apart from the talk that HR provides to the new joinee related to organizational rules and procedures, this is how my company goes about it:

A peer points the new person to where the code of the product , important files (like use cases or task breakups or decision analysis) are on the version control system. He also tells the person the softwares used and their versions. He is also pointed to a document which lists the same. In case there is a difference the new joinee has the responsibility to update it, get it reviewed and commit to version control.

A senior person gives the new new joinee an overview of the product and its functionality.

He also explains the structure and organization of the product modules and classes and answers any immediate questions. The process of code review or unit tests and software development process followed by the team are also explained.

With this background we give around one week to the individual to go through the existing code base. During this time he can ask any question to the Senior Developer who has the responsibility to answer or get the answers.

What we find is that by the end of the week the new joinee is comfortable navigating the project and now he is assigned a few bugs in his area of future working and he is soon up to speed.

Once this is done the next stage is to assign tasks as any other experienced Developer on the team.

Introduction

This blog will mainly concentrate on my journey of the Software Development world since 1992. During these years, I moved from a novice Developer to lead teams of 25+ engineers as part of a product with a 100+ engineering team and then to another young team of 6+ engineers on an Internet Project. I have worked with single site teams and distributed teams with individuals having experience ranging from 0 to 16 yrs. I have worked in programming languages from Fortran to C to C++ and Java and applications from Dektop to Client Server and currently Internet.

So, as anyone can easily guess, I have interacted with many individuals (Engineers, Managers, Sr. Managers and MDs) – observed their actions in various situations and learned a lot from them. Hopefully, I have also been able to impress upon some of them with what my ideas of what good Software Engineer/Engineering is.

The experiences that I had has lead me to forming some perceptions, theories and expectations, which I would be sharing on this blog. I would aim to provide a complete context before I write about anything so that the reader can provide constructive feedback so that my views are refined. Also, I would deliberately not name names or companies so as not to create unnecessary and fruitless discussions.

End of all this if my writings would turn out useful to a few, I would be glad as I know - that I have myself benefited from some exceptional people I have interacted with.