Gary Han - A Nerd Who Tries To Be Cool And Failed Thus Far

    Notice the title is not “How to manage software development teams.” but “How to manage software projects.”

    This is so because developers manage themselves; with agile development approach, developers are no longer the code monkeys of the system, but software designers, taking on tasks in every aspect of the program.

    Remember the good old waterfall development days?

    Spent weeks or even months writing down detailed design plans and specs, then spent months or years trying to get something working, just the find out half way or at the end the requirements had changed. With the change of requirements, programmers went on spending more time on the designs and specs, and spent more time implementing those changes, and then find out requirement changed once again, and the cycle becomes the nightmare loop of doom.

    That is why there were so many software failures in the past. Soon programmers realize that they must become more agile in their ways of handling requirement changes, manage their time better with smaller iterations, etc. For more details check out Agile Programming.

    But in this article, let’s focus on utilizing these agile methods to ensure our project becomes a success.

    Let’s start with an example.

    As an architect or team lead, you are about to start a software project with a team of 3 developers. (Small team? Great! Including yourself 4 people)

    After your team’s discussions with you client(s) and everyone in the team got a general idea of the goal at hand, you hardcore programmers went to the back of your office corner and started taking down notes of necessary framework and libraries you will use.

    Remember, communication is the key to a project success, and talk is cheap.

    After a few hours of discussion, the new graduate in the team managed to convince everyone but one very experienced developer in the team to use a new system for integration testing and scheduled build for the project.

    Everyone is very pleased with the new grads proposal, yet the senior developer rejects ferociously telling everyone we stick with things that worked and stable in the past. The 2 started out in a non-stop argument and slowly you see a conflict will form very soon if you don’t do something.

    So quickly, you tell everyone that we will hold off the build process for now. So your group moves on with other aspects of the project, like technologies to use, framework and potential APIs.

    Thanks to your quick reaction on stopping the raging conflict, the remainder of the meeting went smooth and sound.

    You concluded the meeting telling everyone to continue with the build issue tomorrow.

    Sometime before the upcoming meeting, you privately talk to the senior developer of the team (he could be even more senior than you are), convincing him passively to allow the new grad have a go at his proposed idea, telling him that you will switch back to your old build even if the slightest thing gone wrong. Notifying him that is will be a great opportunity for the new grad to make mistakes and learn. (Since it is the beginning of the project)

    With the senior developers consent, you make your way to the new developer and explain to him why his senior colleague was heavily opposing his ideas.

    After a few talks, they both realized that their action was solely for the benefit of the team. With their conflicts solved, your teams respect for each other grew stronger, and the trust for each other bonds tighter. ….

    Now enough fun stories, let’s get back on track and state the key points of managing a software project.

General Aspects:

1. As the team lead, you must get to know everyone in the team, passively, not purposely bugging them.

2. Know your team's limits, remember quality over quantity.

3. Think like a programmer if you forget that you yourself are another programmer.

4. Try to solve conflict for other teammates before they become a permanent conflict.

5. Always Always take your teammates suggestion positively, and take their say into consideration. Because you ARE the voice of the team to the outside world.

6. Support everyone and try to help each other grow while at the same time learn from others so you will grow as well. (Trust me, there is always something you can learn from someone else)

7. If you see a piece of code need refactoring, do it with the author positively giving constructive feedbacks passively.

(That is all for now, will update when new aspects come to mind, or feedback from someone else)

Technical Aspects:

1. Must have a scheduled build. (Automated test runs and deployment to a testing environment(s))

2. Test Coverage must be at least 90% of the code at any given time, (excluding getters and setters, not everyone is up for test first development, but all committed code must have test coverage.)

3. Must have a utility package in the software architecture. (And any new possible utilities must be in that package)

4. Separate your software into categorized projects (Example: each layer in your application should be in their own projects)

5. Refactor whenever needed using rule 6 and 7 below.

6. Use abstraction smartly while keeping the simplest thing that works (Example: If you just need a car object to turn, then just implement car.turn(), but when you have truck, van, boat AND car, that all can turn. Then implement an abstract layer so that the caller can just do vehicle.turn() rather than specifying each one with if statements.)

7. Use composition over inheritance while keeping things simple. For details please refer to Composition Over Inheritance.

(That is all for now, will update when new aspects come to mind, or feedback from someone else)