What makes a good programmer?

        The success of any project depends on many factors: strong manager, effective process, good planning, good support… And lastly, an important factor: strong team members. Without good individuals, the confidence about the success of a project will go down. That is why the best people are always chosen for the hardest tasks/projects, like you have seen with the Seal Team 6 recently (although it finally turned out that it was not really a tough battle for them).

1.       Introduction

        In software development industry, good programmers are valuable “properties” of a company. Many software companies treat interviews and tests really seriously when recruiting people, because they want to have the best person out of the bunch of applicants.

        It is the company/project perspective. Regarding personal perspective, if you are a good programmer, you can get your job done in a quick timely fashion; the output absolutely meets your boss’s expectation even though he has given you the toughest task. Then you have very good advantage and opportunity to move fast to success and gain big achievement for your profile. However, not all developers are aware of what makes a good programmer, or what is the “essential luggage” on the road to destination.

        From my own point of view, good programmer should have a couple of core values as below:

• High work quality and productivity
• Good job knowledge
• Good soft skills
• Strong English skill

        Those are my top-of-mind items. I often talked to my new project team members or new staff in my line about them so that they are aware and can prepare a plan to improve those values. So far the outputs of their preparation have been pretty good.

Victory loves preparation
The Mechanic

2.      What makes a good programmer?

         2.1. High work quality and productivity

        This is one of the most important keys to success. The work quality of each member contributes to the success of the whole project. As you know a software framework is formed from various modules, layers and components. Even when 99% of the modules are perfect but only 1% fails, the project is still in a high risk of failing.

        I have read a very impressive study from the “Code Complete” book, which I consider a very clear example of how quality should be taken with high care. The study was done on professional programmers with 7 years of experience in average. The chart below shows the comparison on the output between the best and the worst programmer:

     The result above shows us that there is no relationship between years of experience and quality/productivity of a developer. Number of working years cannot say a programmer is good or bad.

         So how can we have good work quality?

         2.1.1. Equip yourself with good coding skill

        Make your code simple, readable, modularized, layered, well designed, robust, elegant and clear. That code usually runs with high performance and has fewer bugs. There are nowadays loads of books that teach us how to write good code. You should have from basic to advanced knowledge on code refactoring, code smells, anti-patterns, design patterns, coding principles and best practices.

         2.1.2. Always test your functionality with high care.

        Test carefully your functionality yourself before you hand it to testers. Always try to test all the cases. People usually do happy-path-testing but forget exceptional cases, in which most of the bugs appear. Make sure there is no silly or careless-mistake bug. In most of the cases, number of bugs can indicate a developer good or bad.

         Some programmers think that they don’t need to test too much because QC team will always do the full test. This is a wrong idea. Programmers have to be responsible for their functionality first. Several well-known companies have even eliminated the existence of QC/QA team.

       2.1.3. Be responsible for the productivity of your work

        It is very important to keep your work productive especially in project types that don’t have deadline or fixed target. For example you are assigned to work on a list of 300 bugs in 2 months. Your boss didn’t say you must fix how many of them. Therefore you can end up 2 months with one of these 2 scenarios:

         -    Have 40 bugs fixed (1 bug per day, spend most of the time reading news or chat chit, or get stuck for a long time with difficult bugs)
  
       -    Have 150 bugs fixed (concentrate on the task, define a smart strategy to fix as many bugs as possible)

       Both scenarios are still fine for you because there was no target at the beginning. However the more bugs you fix, the more you show your ability to work with high productivity and effectiveness (which is definitely good for your project).

        2.2. Good job knowledge

        A programmer needs to know as much as possible about the system of the project he is working on. Dig deep inside into its framework to know its components, layers, components, understand how each component works and how all of them run together. The more he masters it, the easier for him to work on the task assignments. Once he knows the most important sections of the framework, he will soon be the key person of the project and can gain creditability more easily.

     Besides, invest your time to practice and research on the technologies, frameworks, languages or methodologies required by your career path. You don’t have to try to know everything unless you plan to become Solution Architect or Technical Manager. However, you have to know well the ones you work on daily.

         2.3. Good soft skills

Hard skills will get you an interview, soft skills get you the job (and help you keep it).

       You can’t be good programmer by just coding and coding. Soft skills take an important role in your success. This value helps you make the difference and can be a very strong point of yours if you have really good soft skills.

     Soft skills include many individual skills such as: communication, time management, problem solving, decision making, critical thinking, team spirit, presentation, delegation… Every skill has its own importance.

       Apply your soft skills to work the following things:
       -    Manage your time to complete the tasks on time
       -    If you can complete task before schedule, it is brilliant and is a plus sign to your manager.
       -    Don’t keep silent in meetings. Make the meeting productive by contributing your ideas.
      -    Be active in your work. Communicate with PM when you are overload or feel the project plan has problem. Let PM know when you run out of work (don’t just sit and play games).
       -    Willing to support others
       -    Always treat any colleague with respect.

        Each programmer should know which of his skills are good and which one should be improved. The skills can be developed on an on-going basis through trainings, reading, observation and practice.

          2.4. Strong English skill

        This is a highly important skill required by software companies in Vietnam, especially the outsourcing ones. Good English helps you to have more confidence in communicating with English-speaking people. In other hand, bad English speaking and listening skill will reduce the productivity of your work when you have to talk directly to customers frequently. It may even make the customers feel unhappy whey they work with you. You may misunderstand their idea and cause things to go wrong. Furthermore, if you are good at technical but bad at English, you still can’t move fast to success.

       Learning or improving English is a time consuming work. It takes years and requires everybody’s patience. No one can be an English master over night. So if you think your English skill needs serious improvement, don’t hesitate to register English classes. From my experience, English classes are the best places to improve the skill. And as I mentioned above, it needs years of continuous learning. But you will gain benefit from what you invest.

3.       Conclusion

         Coding skill is just a small part of good programmer’s skill set. In order to get your job done well, you need to prepare for yourself some important core values. They will make the difference. You may find some of my points are useful, but you may also have your own ones. My points are very basic ones that target the junior programmers. With higher levels, there are a lot other values waiting out there.

4.       About the author

Cuong Luc
Principle Software Engineer
Harvey Nash Vietnam

Steps to Kick-off a new Project – the Act of using Project Charter

One day, your manager comes to talk to you “I want you to do this project, let’s start!”, then what’s next?

In principle, in order to kick-off a new project, all stakeholders need to be aware of two things. Firstly, you are the Project Manager (PM) and what authorities you have. Secondly, what the project to be executed looks like.

1.       Introduction

In reality, I have seen that some PMs just unconsciously follow what the manager has asked and try to do as much as possible as being considered … it’s starting. As the result, these PMs may meet some difficulties such as:

·         Relating functional managers are not aware of the new project and the assigned PM (sometimes it is the new PM in the organization). So, they may question when receiving requests on human resource, computers, repository etc.

·         The project team members feel uncertain when joining the project because they don’t have enough information on what the project is about.

·         Sometimes, even the manager who assigned the project needs the project information but it’s not ready.

·         Sometimes, client requests progress information, but it is not ready.

Ex 1: Peter has just been assigned to be the PM of one new project although his current title is a Senior Software Engineer. Peter submits the request to the resource manager to ask for project team members and to the IT manager to ask for creating a new SVN repository. After a while, he receives two rejections from these two managers. The common message is that, Peter doesn’t have permission to submit these requests. They’re not aware that he has just been assigned to be the PM for one new project.

Ex 2: One day, client changes the main contact person to work with Peter’s team, who is Ben. He asks Peter many questions about the project such as “What is the start date and end date of the project?” “What are the main features of the product to be built?” “Who in your team can I talk to?” “Can I have a weekly status meeting?” Not to spend much time to explain, Peter sends the whole project management plan. However, Ben is not happy with reading a 50- page document of this plan which has a lot of information. There’re many sections which he’s not interested in.

2.       Project Charter

According PMBOK v4, you should officially start/kick-off the project with a Project Charter and in Software Development projects it should contain the following information.

2.1.    Project name and description

This section describes briefly why the product to be built is needed. How it interacts with external environment. If the product is complex, break it down into sub-systems.

2.2.    Project Manager assigned and authority level

Depending on project types, the Project Manager will have different levels of authority. Most of the time, PM will have full authority to control the project. However, in some cases, PM is only in charge of coordinating the work between the project team and client. This level of authority should be made clear at this early phase.

Ex 3: In an ODC typed project, there will be often a PM at client side. Client PM will control the work of the project team. If you are the PM of this kind of project, you will not control schedule and milestones, you will not control the testing plan etc. You need to state clearly your level of authority in the project charter.

Ex 4: In an SCRUM typed project, if you are the SCRUM Master you will be able to commit only what you will deliver per sprint. The overall release plan should be controlled by client or someone external to the project. You need to state clearly your level of authority in the project charter.

2.3.    Product scope and project scope

Refer to Scope Management in Software Development Projects

2.4.    Project objectives

Every organization has different set of parameters to be measured and set as objectives. The common objectives can be considered such as Effort Deviation, Schedule Deviation, Defect Density, Defect Leakage, Productivity etc.

2.5.    Preliminary resource planning

Even all resources are not ready for the project yet, but it should be clear on which types/roles of resource are needed and how many staffs are needed for each types/roles. This session is recommended to have sub-sessions such as team organization chart, project roles and responsibilities and staffing plan.

2.6.    Stakeholders

This section lists out all seen stakeholders at this early phase. Beside the project team, common stakeholders could be relating people at client side, upper managers and functional managers (IT Manager, Resource Manager, QC Manager, Technical Manager, etc.). The information of stakeholders which needs to be gathered includes their name, their contact information, their job title and the most importantly their interest in the project. 

2.7.    Communication

This section describes how the information should be exchanged in the project. Normally, it could include sub-sections as below:

·         Communication channels: which kind of information should be communicated and by whom.

·         Reports & meetings: which reports and meetings are needed.

2.8.    High level milestones

This section lists out major milestones of the project. The deliverables of each milestone should also be described clearly.

2.9.    Initial Risks

Initial risk assessment should also be done at this phase. It is not necessary to have all mitigation/contingency plans for all seen risks. Project team should try to analyze to find the plans as many as possible. Later on, these risks will be managed during the project life cycle.

2.10.Constraint and Assumption

Defining constraints and assumptions at this point is very important for the project success. The project team won’t have much time for clarifying everything before giving commitment. In order to move on, for some unclear scope and requirement, it is wise to just define constraints and assumptions to protect the project from changes in the future.

3.       Steps to kick-off a new project

Once the project charter is completed, it should be announced to relevant stakeholders. Typically, someone external to the project such as Program Manager, Delivery Manager, Delivery Director, etc. should do the announcement as an official authorization for the project to be executed. Stakeholders who should receive the announcement of the project charter are the project team, the client and all relevant functional managers.

As the project charter is distributed to all stakeholders with different interests, the provided information should be kept at a level which is readable and understandable to everyone. Making it too much detailed will not only waste effort of PM but also cause it less interesting to stakeholders.

Moreover, keeping the project charter at high level will help to make sure it will not be absolute later on when the project is planned into more details. 

PM now can organize a project kick-off meeting which involves as many relevant stakeholders as possible. In the meeting, PM can either go through the project charter or prepare another presentation and present it.

4.       Follow up

A good start of the project will promise a good execution and a good result. Via the project charter, every stakeholder will be on the same page and have the same goal to achieve. For some organizations which don’t use the project charter, is it recommended that they should complete actions/sections listed in the project charter as above.

Someone asks to me why they have to duplicate the planning information in the Project Charter and the Project Management Plan. Actually, it is not duplicated at all. It’s about rolling wave planning. We plan something at high level first in the project charter at very early phase. We plan for details via Project Management Plan and it supplementary plans such as Testing Plan, Quality Management Plan etc. after the project is authorized. The project planning is not yet finished after the kick-off.

5.       Conclusion

Gathering the information to kick-off a new project is not an easy task. However, following the standard from PMI, it would be clearer and more organized to do with only three steps:

·         Preparing the Project Charter.

·         Announcing the Project Charter as an authorization.

·         Organizing the kick-off meeting(s).

Workload Balancing

When managing a project, you look like a captain of a boat. So your team and you need to sail in the same boat for the same mission – we get goals. And if you race your team along for a long time, your team will be tired and not be able to run any more in next stage. Of course we cannot go slowly due to project deadline. So how come?

1. Introduction

You are a project leader/project manager who is responsible for running project smoothly and successfully. In this article I just express my experience sharing – one of the lessons I have learned during managing several projects in the past.

My story is workload balancing. I think that workload balancing is one of the most important points contributing to a successful project as well as keeping your team working efficiently and comfortably for a long time.

Let’s image you are an athlete on a long marathon race. Surely you cannot always keep racing along very fast and this is not obviously a good way to be a winner. The winner is the person who needs to know how to balance his/her effort efficiently.

In most of outsourcing projects, workload of team members isn’t often balanced because of

· Optimizing incorrectly resource allocation

· Doing unnecessary things

· Unbalanced Endeavour

2. Problems

I think they are 3 major causes of the issues making the workload unbalanced.

Below is the image expressing the workload of project team members (PM: Project Manager, QC: Quality Control, Dev: developer).

Figure 1: Workload balancing issue.

2.1. Optimizing incorrectly resource allocation

To optimize resource when starting a project from requirement analysis and estimation, a few key members including project manager are involved in executing tasks. Of course the number of members depends on the project size.

However, the workload of team members at this time is often too high to perform a huge amount of complex project tasks, such as: analyze & propose requirement and design, estimate based on the proposed solution...

And next stage some designers and developers are allocated to design the architecture, implement the framework as well as develop the detailed design. QC members are usually involved later than others in preparing the test environment, developing test cases and executing the test. So while developers are busy doing their tasks to develop software packages, QCs just start studying requirements and preparing the test environment.

So obviously developer’s workload at that time is increased and very high while QC’s workload is low. Then when developing software package is nearly completed, QC’s workload will be increased due to preparing and executing test.

At the last stages of project, PM and QC are busy performing their tasks (PM: controlling the quality, monitoring and tracking, preparing reports; QC: executing test cases, writing bugs/test reports…), while the main tasks of developers are fixing bugs.

2.2. Do unnecessary things

Due to misunderstanding in communication, task assignment, reading project documents or unclear requirement, a member can make unnecessary output. Certainly this needs to be executed again in high pressure. If the mistake is often occurred, it will make the project go down and behind schedule as well as this team member has to work very hard to complete the assigned task on time.

2.3. Unbalanced Endeavour

And one more main reason that makes workload of team members unbalanced is not good working mindset. He or she often does his/her tasks slowly in case task duration is fairly long and when the deadline nearly comes, he/she tries to work hard under pressure. Of course the result will be badly affected in such condition.

3. Solution

It is better to make the workload of team members as the below figure in which their workloads are similar.

Figure 2: Workload balancing improvement.

Let’s apply one of the principles of Agile software development framework, that’s frequent delivery.

In order to do this, members have to be allocated properly to complete project tasks together. Doing unnecessary things can be prevented soon when milestones of project are divided into smaller items for monitoring and tracking. The project manager and stakeholders can easily and soon detect misunderstanding points basing on each release. This helps your project not go too far.

And when milestones are narrower, working spirit and mindset of team members will be kept and prevented from loosen focus because the deadline always goes after them. Please take a look at the below figure to see the differences.

Figure 3: a suggestion for workload balancing.

There should be some controversies on what I presented in this paper about workload balancing. This article is not going deep into how to apply … efficiently. Please find another article of mine focusing on workload balancing strategy to be released soon in the same publisher J

4. About the author

Hoang Phung Duc Software Engineer Specialist HP Software Vietnam