Managing a Software Development Team: Some Experiences

Introduction

Managing a software development team is never an easy task. It consists of 2 sides:

1. technical things
2. non-technical things.

This task is often assigned to the project manager, VP Engineering, Software Development Manager, etc. To be succeed, one has to consider those 2 sides. In this article, I will ouline some of my experiences in managing a software development team. This list is not meant to be complete nor perfect. You may need more but at least you will be in the safety line level one if you do care with these issues.

Decide the tools which will be used by the team

Well, this is a bad news if you don’t have enough technical capabilities. Once you don’t decide the tools, your team will be confuse as they have more than one preferences. It’s not funny to have your team uses PHP with different versions, some use WAMP while the others use XAMPP or maybe PHP which comes from some Linux distros. It’s not funny to have your team uses Notepad, Visual Studio Code, Textpad, Vim, Netbeans, Eclipse, for their IDE/Text Editor. This will waste much time and bandwidth. Consider this, if they use different tools, then when someone says: “uh oh, my Vim always give me a tab and not some spaces, how do I turn the tab into spaces?” and then nobody can answer this and probably think “that is your responsibility, I don’t care because I never use Vim”. Now consider if everybody uses Netbeans (note: I don’t have any relation whatsoever with Netbeans nor a Netbeans evangelist), when someone yell “How do I create a new PHP module in Netbeans?”, chances are some of the guys in your team know about this.

Use a specific software development methodology, probably with some minor adaption

A software development methodology consists of process and modelling. It guides the team through the process and enable the team to model the software which is built by the team to solve client problems. It is important to use the specific methodology so that everyone in the team knows what and how to do the development. If you don’t decide any methodology, then your team won’t have any guides. Remember, you have to use a specific methodology but don’t be too rigid. Your team may consists of people from many backgounds with many level of capabilities. For example, you may use a Unified Process methodology but because your team is limited and don’t have time to learn how to use UML, then don’t push them to use rigid UP methodology. The most important thing here is process. Do use that process but don’t be too rigid.

Make some conventions regarding technical issues

Again, this is important to keep the team away from the state of flux and let the guys in the team communicate with the same language. You surely don’t want your team to have more than one variable / property naming system, right? What if some programmers use “this_is_a_variable”, while the others use “thisIsAVariable”? quite confusing, I guess. You may need to define some coding conventions and probably uses software tool to force this conventions, for example if your team uses Rust, clippy can help you and your team.

Enforce Programming Idiom

Every programming language, together with their ecosystems and development tools are such a complex beast. Usually, in the beginning, the most important thing is "it works!", but turns out that this may decrease productivity since there are more than one thing to do somenthing, reducing readability. Enforcing programming idiom is important to increase source code readability.

Know the client(s) and their problems which are tried to be solved

You must understand this good enough so that you can define the scope of the problems and deal with the problems.

Decide the scope of the problems and insists on this.

Clients basically don’t understand the requirements, so your duty as a leader is to define the scope of the problems which are tried to be solved by the software. You must cooperate nicely with the client and have the information understood by all team members. From programmers’ point of view, the uncertainty caused by scope uncertainty will lead to frustration. Well, I do understand that agile methodologies encourage changes, but who want to deal with changes everytime? What I am trying to say is, a software development leader should understand that changes are possible but this should be done within the scope. Don’t play with programmers’ heart 😉

Have a good interpersonal relationship and don’t be a jerk

I know that this software development task is not easy. Clients always ask the progress and the team is in a stress condition. It really helps to just stay with the team and always willing to help them whatever you can than just act like a jerk who walks here and there and yelling. Trust me, the team will respect you more if you are always willing to help them.

Never let the team in a state of flux

Uncertainty comes everytime. Whenever the team has anything uncertain, your decision is needed to keep them away from confusion. You do understand that you have to have a good grasp in technical side and problem domain to make a good decision, don’t you?

Let the team concentrate on technical matters

Ok, pay attention more to non technical matters so that the team can concentrate on technical side. Don’t let them do any clerical things since programmers (usually) hate to do administrative things. It’s good to have a dedicated person to deal with all administrative things.

Let the team member knows each other about progress and difficulties

Opennes is important. By let them know each other’s progress, you keep them in a fair situation. Low salary probably can be understood, but unfair treatment can not be tolerated.

Inform the team about your progress too

So you think you can hide your progress? The team will surely want to know that you do your jobs too. If you hide your progress, they will lose respect and trust in you.

Communicate. Communicate. Communicate

I can not emphasize this more. This is really important for the team to have them communicate each other. Your tasks will be to communicate with them and act as a liaison between the team and the client. Oh and don’t forget, have a good sense of humour.

Always keep backup of everything

You don’t need to backup everything if you are sure that you always live in an ideal situation. You should keep backup in more than one place. Compress them and have them uploaded anywhere on the Internet or in a storage server if possible.

Use Version Control System

Version control system is a software which can be used to track the software source code versioning. You may use Git or Mercurial for this purpose. With version control systems, the progress is transparant. Also, any bugs and improvement can be tracked.

Use web based bug tracking system, project management software, and/or wiki

This will keep any information handy and on track. All any other members can also see the project’s progress. It will keep each team members informed and any unfair situation can be detected. Usually, they are now available in GitHub or GitLab.