My vision of a good software developing team

I found the major problem is that our current software development can not fully meet the customer’s needs: Almost every project is delayed, every one is busy and has a tight schedule; the product quality needs to be improved; the application software is hard to maintain.

I realize that the reason might be something that our management does not cover: our manager only care about what needs to be done and when can be finished, but does not care how to do it. So where there is something is not covered under management, and then there will be problems: no design, no developing strategy, messy code, hard to maintain, too many bugs.

I realize there is a gap between the project manager and the developer:
The project manager just want to get the work gets done, but does not care how to do it;
The project manager cares more about schedule over the quality, and project manager care more about short term benefit over the long term benefit, like maintainability, flexibility, clarity.
The project manager treats the developers as “pluggable compatible component”, based on an assumption that each developer is interchangeable, and can be transferred to another developer to do the same job, does not notice that each developer is unique, and have different skillset and mindset.

And currently our only strategy to get thing done by either adding more resources or by sacrificing the quality, no other strategy; which means we have to work over time, hire more people, spending more money. Can we do that in a smarter way? Can we do that in nice, clean and faster? I think the answer is YES.

We need to do things in the right way. In Chinese, “way” means “TAO”. If we follow the TAO of the software development, then we can deliver the great product in a short time.

Following are my vision for a good software developing team, and what the TAO should be:

- Follow good design
We need follow good OO design principles, and good design patterns. A good design is a foundation of a software product, and a good design is the DNA of a good product.

- Build Quality in
We need to balance between long-term benefits with short term benefits
Our software should be: flexibility, maintainability, and readability.

- Write clean code, constantly keep refactoring, continuously improving design
I like Uncle Bob’s saying” If code is messy, so does the product”.
Bad code slows down the productivity
Only one way to go fast is going well, writing clean code.

- Design for maintenance
The only way to develop maintainable code is to design the maintainability at design phase

- Deliver DRY project
DRY means “Don’t Repeat Yourself”.
Here I would like to mention the definition of what does mean a project is Done:
1. Deliver the product to our customer
2. Developers improve their skills;
3. Team gain knowledge;
4. The design and code is easier for future project
I think all these 4 things together means a project is done, but currently we only focus on No. 1, which cause on the problem in future: since the code is not reusable, we have to rebuild the entire app, or we have to duplicate all the old code, which either by fixing duplicating bugs or by spending long time to fix the issues by adding new codes. Finally we spend more time and money by reinventing the wheels.

- Test Driven Development
We need are not only use JUnit, but also to make sure our design is easier for unit test, our framework is easier to using unit test.

- Build automation
Our build automation should support everywhere, server side code, client side code, and test code.
Everything we need should be checked in the repository, including dependent libraries, config files, property files, database script, build tools, etc.

- Use static analysis tools
Currently there a lots of open source static analysis tools. For example they can find the potential bugs; tell you how complex of your code, how messy your code is, and tell you the coverage of your test code, etc. which will help us improving our code quality greatly

- Foster knowledge sharing and internal training
We need to build an environment which can foster knowledge management in our company, which is called ‘ba’ in “Lean technology”. We need to use Wiki, internal forum, internal training to share the knowledge for all the developers.
Knowledge management is very important

- Following the Agile
We need not only do the agile practices, but need also fully understand the agile principles and its values.
And each team needs to use different agile methods.
Developer needs to follow XP;
Manager team needs to follow Scrum
The whole company needs to follow Lean technology

- Training developer to be professionalism
We need our developers have the concept of:
Professionalism, craftsmanship, discipline, ethics, etc.

Next I want to discuss more about the gap between the manager and developer. I think there is a role we are missing – “coach”. I think a good coach will be a bridge connecting developers and managers, his role is filling the gap.
I would like to make a metaphor: thinking our software team as a sports team- whether basketball team or a hokey team. In a sports team a coach plays a very important role:
- Design the wining strategy for the team
- Instruct each player not only what to do but also how to do;
- start timeout when he found the issue during the game, either by substituting a new player or set up a new strategy;
- Training players and improve their skills;
- Motivate players and find their potentials;

In summary, the job of a coach is to make sure how win a game and how to make a team better, he focus on HOW. In contrast so far I did not find a role in our team that can fit as a coach, either our manager, or architect, or team lead. I think the reason is our management model is "command and control", which is from top to bottom, each manager’s job is dispatching the job from his upper layer to his under layer, then his job is done; the same is for architect or team lead. But if we also have another management channel - from bottom to top, the role of coach is very important. I believe the coach's role is more on the developer side, The coach’s job will focus on how to make our software better, make our developer better. And I believe only the coach can do all the items I mentioned above, because coach himself is a developer, he understand our product’s detailed problem, knows the solution, he knows each developer’s different strength and their skills, once he knows the vision, understand the whole picture, he will play a very important role in our team.

So my suggestion is we need a coach or several coaches in our development team.