How Can You Maintain Code Quality When Outsourcing?

GET IN TOUCH WITH KMS
 

Outsourcing application development or maintenance promises cost savings and focuses on higher-value activities unique to your business. However, assuring the quality of outsourced software code seems to be a great fear of many top executives, particularly when they intend to use offshore outsourcing services.

What if outsourcers approach offshore product development with clear, quality objectives, working closely with their offshore team to track those goals through code review and using tools to monitor code quality?

That approach seems simple, but in reality it was almost impossible to make it happen. There are many reasons code review often takes the back seat in software development projects, especially when it comes to offshoring.

What Methods Can Be Used to Monitor Code Quality?

First, let’s get back to the basics. Before thinking about monitoring code quality, it is crucial to train your development team for the code quality level you want them to achieve. Regardless of outsourcing or building in-house, a new hire that will create source code must be properly trained to produce the same quality of code as the other members.

The training process occurs in four steps:

  1. Training on coding convention, coding practices, and processes
  2. Training on architecture of the code base
  3. Training on hands-on coding tasks
  4. Closely monitor and review of all source codes the new person created (usually in the first month of performing real coding tasks)

The process above will ensure the person is trained and coding the way all team members are expected to.

Next, there are three key actions to monitor code quality through a project’s duration:

  1. Regular code review to make sure every member is keeping up the applied practices
  2. Continuously scan source code (by using code analyzing tools) to find coding issues
  3. Encourage unit tests and monitor the test coverage

Suggested Tools For Reviewing Code

Code review does take time and may inhibit the team’s quick project timeline, but as more project members are added, it becomes necessary. The main reason some developers are still unwilling to do code reviews is that they feel the benefit of improved code quality against the pain and time conducting it just isn’t worth it. Imagine how long it takes to extract another team member’s code from source control, print it out, highlight the issues, and then bring the findings to a meeting for discussion with other people.

Using code review tools can help facilitate and manage the process while speeding up the time for doing so. There are now software tools for peer code review that solve above issues of collaboration and source control system integration.

Here are three recommended tools:

  • Code review tool: Crucible
  • Static code analyzers: Checkstyle or Sonar
  • Unit test coverage: Sonar

How Can You Maintain Code Quality With Offshore Teams?

At the beginning of your outsource engagement, provide the offshore team with the coding convention your team is trained on. From day one, have your team do code reviews of every line of code written by the offshore team for the first month of the project. Often, this is enough time to get the team trained to produce the quality you expect.

Once you feel confident that your offshore team is well trained in your coding convention, the code review task can easily be passed to an offshore team lead. That person should be charged with training new members of the team and periodically reviewing code to ensure that quality is maintained.

In engagements with our clients, Checkstyle is often configured in each developer’s IDE and it can report any non-conformed code. Sonar is installed both offshore and onshore to scan source code for potential problems, as well as run and report unit test execution and coverage.

Additionally, all team members are encouraged to raise issues they find in the code, or to refactor areas that they work on to improve the quality. We still assign a software architect from our clients to do random code reviews to make sure the team continues to maintain the high quality of their code.

By applying the practices above, you can be certain that both your onshore and offshore teams are writing code that is consistent in quality. Putting systems in place now allows you to expand your team as the project grows and achieve better end results in your product.

GET IN TOUCH WITH KMS
 

Is University The Only Way to Become A Developer?

In a career talk with Ho Chi Minh City University of Polytechnic’s students, I was asked a question: “What do the scores on my transcript mean to recruiters?” I answered that when you are just out of school, it is the only evidence of your ability to complete what you started. The next question was, “what if there are no scores, or a candidate did not go to university, or didn’t complete school, what does it mean to recruiters?” I can’t speak for all recruiters, but I will share my opinion about it.

There are countless success stories of dropping out of university, like Bill Gates or Steve Jobs, but traditionally in Vietnam, everyone must go on to university. Typical reasons for not attending include not having the intelligence required, or not having enough money. While these are sometimes true, there are many other reasons a person might choose not to go to university or to drop out.

Let’s say you don’t feel that you have the talent to learn math, physics or science. You tried hard but could not pass the entry exam or could not graduate. My advice is to find another profession. A programmer needs logical thinking skills and passion for science. If you don’t have these skills it will be painful to invest time studying and working, and still struggling while your classmates can do it with just a finger snap.

What if you have the ability to learn and are passionate about those subjects, but your coursework grades don’t reflect that? Thought it might seem that if you’re passionate, you can still find a career as a developer, recruiters don’t necessarily see it that way. They can’t be sure they can give you assignments that you always love. In business, many times you have to do what is needed for the business, even if it is boring to you. My advice to you is change to “love what you do” not “do what you love.” Find motivation in contribution and achievements you made for the company and society, rather than only being motivated by things that you personally like. The value you create is much more important than the difficulty of the code you write.

If you have the ability, but your lack of motivation and self-discipline kept you from graduating, my advice is to give yourself a second chance by starting over with something else. It could be a project with a group of friends, or participating in an open source community, or even go back to school and get your degree. If you can follow maintain consistent performance and contribution, recruiters will have faith in you, and they may believe you will consistently contribute to their organization. Sit down and start working seriously on something. This process will train you to focus and complete something to the end – what recruiters want to see and what you couldn’t do with your degree.

Did you drop out because you had an idea, or saw an opportunity and couldn’t wait until completing university? It is reasonable but there are two things the recruiters would consider:

  • Are you a responsible person, did you throw away your family investment and expectations, for your own hobby and desires? One day, if you have a brilliant idea, will you just quit the job?
  • Do you have long term commitment to the company, or this is just a temporary job until you mature your personal plan?

If the answer is no for both questions, the company will not give you important positions, nor invest in or plan for your career, because you might quit anytime you want. They will just use your skillset, but wouldn’t be surprised if one day you’ll take off.

If you thought university was a waste of time, or there are too many impractical courses, you will have to prove you have another and better method to develop yourself in programming. The recruiters will be very concerned that you may have a tendency to reject a plan or program that you don’t agree with, while you are unable to point out a better plan. You should understand that in programming, there is never a perfect solution, there is only a “best solution possible.” A person who always points out the negative things in policies, decisions or plans without suggesting a better approach will be a major pain in the organization. To ease this concern, you should be able to explain how you successfully learned and mastered technical skills without a university. If you can do that, recruiters have a better chance of believing you are the type of person that thinks outside of the box, with creative ideas, that can turn them into a satisfying result.

If you have financial difficulty, that left you unable to complete your university education, recruiters will want to know how you compensate for those missing years of learning. If they decide to give you a shot, they will carefully evaluate your skills. If you prove you can learn and master coding skills without going to the school, you may get a chance.

These are all real world cases from candidates I have reviewed and interviewed. Having a university degree provides a competitive advantage – it proves you have gone through the exams, that you can complete projects assigned to you, and that you have basic knowledge in sciences and software development. But if you can prove that you have your own way to obtain this knowledge, your own challenge you wanted to tackle, or you can develop your skills and contribute to the company, not having a university degree shouldn’t deter you from applying for programming jobs. My best advice to you is to be completely open and honest with yourself and with the interviewer. Failing an interview might be bad, but to be hired into a position where you struggle is worse for you and the company.

How Should a Software Engineer Prepare Their CV for a Successful Job Search?

A CV should be clear, concise and professional, but still express your personality. For software engineers, a CV that highlights your strengths while providing details about your past experience can help you stand out from other candidates. It will also help the recruiter determine whether they want to schedule an interview with you. Failing to take time to create a proper CV can be detrimental to your job search – it indicates that you can’t express yourself well, don’t fully understand the industry you are in, or that you don’t take your job search seriously.

From my experience, a CV in Computing should have the following five sections:

1. Personal Information

Include name, year of birth, address, phone number(s), email address, and if you choose, an ID picture. Personal information like marriage status, gender or hometown should not be included as they can create discrimination and should not be part of the recruitment process.

2. Career Objectives

Clearly state what you are looking for in your career. These objectives can change over time, but it’s important to show the recruiter your goals when applying to their company. Here’s a good example of career objectives: “Looking for a professional and friendly environment where I can maximize my contribution with the J2EE experience I have learned in the past five years. I would like the opportunity to work directly with U.S. clients. A leadership position is preferred, but a technical position where I can gain a deep understanding of current technologies is also great.”

Only list what is really important to you (for example, the person with the career objective above is quitting a job where he is coding HTML and JavaScript, which is not his strength.) Don’t list ambitious career goals here, stick to what you want to learn and do right now. For example, if a newly graduated engineer, without any evidence he’s a superstar, writes down in his objective section “to be a project manager after two years working,” will very likely be rejected at the screening round because the possibility of that candidate failing to meet his objective is extremely high, and he will not be happy with the job.

3. Skill Sets

Only list what you really know or have experience in, not what you heard is a valuable skill, or the products you worked on used them. Explain the level of expertise for each skill. A newly graduated engineer with C/C++ level 4 of 5 will impress the recruiter, but if he has more skills listed at level 4/5 (for example Java 4/5, Oracle 3/5) it’s likely the recruiter will reject the application. It takes at least 5 straight years to really reach level 4 of 5 of a specific skill, so the fact that a student has several skills at level 4/5 means that the person has a very narrow knowledge of that skill and cannot self-evaluate.

If you don’t have a lot of experience, let’s level it base on the number of years you worked on it.

Example:

  • Level 1: Knowledgeable (self-research or trained/learned).
  • Level 2: Real experience under 6 months.
  • Level 3: Real experience under 2 years.
  • Level 4: Real experience under 5 years.
  • Level 5: Real experience more than 5 years.

You should include the above leveling method in the CV so the recruiter understands the way you rate it. You should also be honest with your ratings. If you have 1 year of experience as a JSP/Servlet/Java developer who developed software using Struts for only 2 months, rate 1 year for your JSP/Servlet/Java, and 2 months for Struts, because you only really touched Struts-specific code in very limited cases (same goes with the database.) The recruiter should clearly understand that most of the time you worked on web pages and JSP/Servlet/Java.

Don’t list non-relevant skills (for example, if you are a programmer, don’t list Microsoft Word or Excel) unless you are really an expert in these skills.

Throughout my recruitment experience, I have skipped through this section in 90% of the CVs I screen. This high percentage reflects the common problem that candidates could not evaluate themselves or could not properly express their skill level.

4. Work Experience

If you have held jobs at more than three companies in the past, you should have a list of companies – accompanied with the time you worked there and your title(s).

After that, list all projects or groups of projects, starting with the most recent. Each project should include the following:

  • Project Description: Besides the general description of the project, explain what purpose the project served. For example: Web application XYZ for hospital management provides all workflows and functions for a private clinic in Vietnam. The project took 5 months to upgrade XYZ to support chain-hospital model and moving from LAN hosting to Amazon EC2.
  • Project Size: In order to give the recruiter an idea how big this project is, provide man-months and number of resources.
  • Assignment Length: months/years you worked on that project.
  • Your Role in This Project: Don’t just include title of the role, but explain in more detail what you did. This is important because the project can be huge, but if you only worked on a tiny part – you should say so upfront. Or, if it is a small project but you held a very important role that led to the success of that project, you should say so.
  • Skills You Achieved from This Project: Only list the skills that you really used and the time you worked on them. Don’t list all the technologies used in the product if you didn’t directly work with them.
  • Achievements: List your personal achievements in this project, for example, you joined and required only 15 days to start effectively working on the project, when the average ramp up time is normally 1 month. Or, you found a solution that helped double the overall performance. In general, list everything you are proud that you were able to do for this project.
  • Leadership and Management: Number of staff you managed.

Clearly describing the project is very important because it helps the recruiter learn what you did in the past and then imagine what you can contribute for their organization in the future.

If you worked on multiple small projects, group them together as a table (each row is one project, each column is one piece of information above.)

5. Other Information

  • Degrees, certificates, trainings.
  • Awards, private projects.
  • Don’t list your hobbies, favorite sports or social activities you joined.
  • Similar to sex, marriage status, etc., you should only provide relevant information to the job opening for the recruiter.

Getting a dream job does require some good luck, but what it needs more is thorough preparation. More importantly, it is an opportunity for you to stop, assess your skills, and plan for your future.

I hope with this advice you will be able to create a perfect CV that helps you find a job where you can contribute and grow in your career.

Flat Titles at KMS

What good is a title?

  • A tool to encourage people to do their best, to learn and earn the title. Recognition.
  • Categorizing people in different levels – so we know who is at which capability level. Separation.
  • To look better when meeting external people. Hollow effect.
  • Promotion is the way to earn bigger salary raise. Money.
  • To bring home and proudly say – mom, I’m promoted. They don’t actually know what you’ve been doing in the past 5 years but well, it’s supposed to be proud of. Sharing with family.
  • To proudly tell your ex-coworker, colleague friends that you are promoted. Everyone in the field is fighting to climb the ladder. We should do the same. Competition.
  • To create a history of achievements so your Resume looks good and you are safe if you want to find another job. Job security.

Why flat titles

We recognize all the needs above and do have a title system to support the above purposes at the minimum level. But, at KMS we would like to look at each purpose of the title from a different view, beside the obvious above:

  • Recognition: we ensure the recognition of each person works by Management members staying close to every one. We keep exchanging that info around and go through each and every one in PA reviews to not miss anyone.
  • Separation: we only do enough of this for management purpose (and to bill clients correctly). Other than that we still want everyone as a team and no real separation between us. We do appreciate each and everyone’s contribution, from a fresher to MD. Without the work of each of us, KMS cannot be the same today.
  • Hollow Effect: We don’t meet external people much – except Viet Hung I guess. But if you do and feel the need of a better title for this purpose – let the management know and we may approve a title for you.
  • Money: We do have large overlaps in salary ranges – and SE can earn more than SSE, SSE can earn more than SA / EM. You earn by advancing in your ability, not by promotions.
  • Sharing with Family: We would leave this to you – but we suggest you tell them more about your work – what you do, what you did well, what your team achieve, and how good KMS is – to create a better bond with the family. Instead of a promotion here and there but they don’t really know what you did.
  • Competition: We would like to build KMS so that you can be proud only by telling them you are a KMS member. We would like you to be proud that you are working in a good company, you are happy that you can contribute a great amount to that company and you are continue to grow along with the company to a bigger future. That sounds much better than telling them you are a Senior Manager in a crap company – they are going to laugh behind your back. From my experience, happiness and proud of a promotion only lasts 1 week at most. The joy and proud of the new things you can do last much longer. At KMS, you are asked to contribute whatever way you can to the company, regardless of your title. Consider yourself already promoted. Now, what do you want to do?
  • Job Security: KMS is different – we don’t want to be a company with only 13 months of salary. We want to share the success with the members who are with us – starting with benefits – and then with more reward when we make money – very soon. We believe in it and would like everyone to look forward to the same future, to work and think like this is the last company you will work for, and share the success when it comes. If, for a reason, you choose to leave KMS, we want that you will earn respect of the interviewers by the fact that you are KMS member alone, you will impress them by your knowledge and experience, you will make them like you by the maturity and thoughts that you learnt at KMS. We believe you will earn whatever title you deserve – no matter what title you had at KMS.

To conclude, we do support all of the common purposes of the title system – but at the minimum level and we look at them differently. We would not want everyone to rush for it as a goal – we would like the goal to be how much you can do for KMS and speed up our success as a company – and gain recognition, respect, knowledge and rewards in the process.

Why Is Salary Information Confidential?

Why salary info is confidential! This question is the direct result of why we should not compare our own salary with others.

  • Because it only brings you a bunch of negative feelings (jealousy, miserable feelings) and eventually very well take you down.
  • Because it is not helping you, in anyway, getting a raise. Unless you tell the company “if you don’t raise me to $xxxx, I will quit”. You can do that out of the blue without any reasoning though. There always a whole bunch of people receiving $xxxx/month around the world, you don’t need to find a friend that does.
  • Because you are NOT the direct lead of the person and you DO NOT know what the person did well in the past, even if you were their classmate 2 years ago. Your friend might be not a good presenter, everyone laughed at him, but in the past 6 months he implements features 3 times faster than anyone else. You DON’T know that.
  • There is a reason for sharing salary – if you know that guy has higher salary than you, you may try to learn from him. But people don’t do it this way, they do #1 instead, unless the gap is big enough – that’s when titles already differentiate it.

So if you see people sharing salary info and starts feeling unfair – let them know why sharing or asking other’s salary is bad for them. They should deal with their salary by themselves or talk with the company, rather than comparing oranges and apples.

The same thing applies to promotion – except that promotion is not confidential. We often hear “Even Mr. A is promoted to Senior already, why it’s taking so long for them to promote you,” or “Why is that Mr.B can be a Manager, his project does not have a process” …. people simply don’t know what they could and did do.

It could be a sign of “lack of trust.” In this case, it is hard because the management can’t share all the details why Mr. A is receiving that salary or why Mr. B got promoted. We just need everyone to agree to the 4 reasons above and do not do the comparison or complaining about others. It’s not bringing any good.

Key to Success: People, Trust, Integrity

First of all, this is not my invention. I might even have missed it a few times and only finally heard about it in our latest Open Day. In the presentation, our key factors to success were presented as People, Trust and Integrity. I talked to a few visitors and found it’s an interesting topic when we think about it and dig into it. I myself have a few stories that I want to go over with everyone. So, here we go.

Integrity

We are not pessimistic. We’d like to think of the bright side of the stories. We’d avoid judgment if we are not directly involved or don’t have ‘enough’ information. I believe most of people, at least most of us – the bright educated minds of the country, are like that. BUT, in more than one company I worked at, I heard people complain (and I found myself did too). Complaining is not the problem, the problem is that no proof or credibility was needed, no critical thinking was done, a person just says it and others are likely to agree. Just a few examples of the complaints so you can imagine what I’m talking about:

The bosses had an expensive party at a luxury bar. People will complain it will impact the company cash flow.

The performance review, salary increase and promotion are just announced. People start spreading the rumors that the amount of increase and the chance to get promoted all depend on a “quota” for their group. The explanation for not getting a good increase or not getting promoted are just something the management made up for their decision. It has never been about the individual performance or capability.

The company decided to put security cameras in the work place for security purpose. People will say it’s for spying on the employees and there’s no freedom.

Let’s face this, these complains can be true, or can be just total fabrication. None of the people who said this or the people were accepting this had any information supporting their complaints (i.e. how do they know the bosses are not using their own money? Were they involved in the salary adjustment / promotion decision making process? Did they get to see how the camera recordings are used?). Yet people still complain about virtually each and every decision or change the management made.

Integrity is very important. If the company is running in the way that when something is put up, it means to be followed, and followed by everyone. When something is said, the person said it really means it. When something is supposed to be done will surely be done. That’s when my examples above have no room to stay. That’s when people can be logical again and go back to base on facts, not the implications or possibilities behind them.

Trust

I hope we all agreed integrity is important and we want to have it. But to build integrity, keeping promises is not always enough since there are many things you say other people cannot verify. For example, if you say “The company’s financial is bad, I volunteer to give up 3 months of my salary, starting today”. Nobody except your boss can verify that you actually give it up, or you are just saying. That’s when trust comes in. If people trust you, if you have been a honest person, if they believe you are not someone who lies for breakfast, they probably believe you and stop asking for salary increase. But if you’re just a manager who only talks when you want something, people will laugh and say “go ahead if you want, you got enough money for the next 3 years already”.

I worked at a company several years ago. The company split into two companies and there had been fights between the two management teams. I was moved to the new company. When it came to the labor contract signing, an appendix was prepared by a lawyer and we were asked to sign it. It was well designed, in the way that it granted the company all the rights over its employees. I don’t remember all of the terms, but I do remember employees have to provide their personal information if the company requests, and there is a fidelity bonds purchased to ensure the employees will be chased down if any damage happen. As if we were the criminals! I knew they tried to protect themselves from the other company, but I didn’t sign it, and nobody else did. A short time later I left the company, left the war that I didn’t want to be in. If the company cannot trust me, or if I can’t trust the company not doing something ethically wrong, it’s not gonna work. The company can have loyal employees by being straight forward with them, by telling them the truth and proving them that it’s the right thing to do, not by a well-designed contract.

How can we build a trusted environment? Let’s go back to the question, who do you trust? The simple answer is we trust honest people. We trust people who want to say the truth, even if the truth will bring to them disadvantages. We trust people who keep their ethic even when nobody knows. We trust people who won’t steal credits, won’t fake achievements, will accept their mistakes, and won’t make up reasons… The company has to be a group of trusted people, from top to bottom, left to right and spare no space for liars.

People

I think it will be easy to get everyone agreed with this. For software companies, people is the single most important assess to their success. Not the laptops, the licenses nor the expensive servers. Actually I mean RIGHT people. The company wouldn’t want people who cannot bring values to the company, or even worse, damage the values it has been building.

There was a team I worked with the other day. There were a few persons who were not strong at technical and couldn’t complete their work without help from others. It was a burden to other team members. When the burden built up, the good people were busy patching and avoiding problems. There would be no time for great success. There would be no reason for optimistic or creative thoughts. Nobody was happy, and to complete the circle (well, I think it’s actually a spiral down), nobody did a good work.

So I think getting the right people on board is very important. The right people will bring up the company core values and get a lot of work done. The wrong person will slow others down and even worse, pulling things backwards.

I want to end this article with an old story about the ants. There’s a piece of bread and a bunch of ants. If the ants pull the bread in all directions, nothing moves. If all the ants pull the bread in the same direction, they will be able to bring it home. And it’s best if all the ants are strong ants, no one slows the others down. That will be the best group of ants ever and success is inevitable.