I just finished reading a fantastic book that I highly recommend any level developer that works in an enterprise-level PHP team environment or manages a PHP team to read.

PHP Team Development
https://www.packtpub.com/web-development/php-team-development

It may be a little dated, but it’s not a straight coding book but rather more of a philosophy books with applicable principles that are very applicable in today’s development environment.   Sure some of the technologies listed to help enforce certain fundamentals such as CodeIgniter for an MVC framework or Bugzilla for a bug tracking tool may be dated but the process, leadership, and core idea of tracking bugs and working in an MVC environment still holds true today.

Some of the big takes I’ve learned and is re-enforced in this book are in the following areas:

• Need for team
• Using and enforcing a process
• Design patterns as solutions
• Effective communication
• Implementing MVC as a team
• Frameworks to simplify complexity
• Expectation of a framework
• Enforcing best practices
• Documentation
• Commercial Support & Licensing
• Successful team with frameworks
• Common fears among developers
• Mutual trust and respect among developers
• Principles of agility and agile development
• Challenges in a team
• Ensuring process effectiveness
• People development

Here are some of my take-away paraphrased notes from the book that I found valuable.

• Process rigor – The idea of taking an idea, theory, process and adapt it that makes sense with your team. You don’t have to follow everything as-is and by the book if it isn’t pragmatic to do so. The whole idea is that the theory, idea, process, etc.. is to help build better software, not hinder it. p10
• Using a design pattern without fully understanding it may cause ‘creative chaos.’ It is highly recommend for a developer to take the time to learn the principles behind a particular pattern. p20
• Communication is extremely important in a team. The smartest (high level of competency) team will fail if communication is bad. p25
• Framework exists for many reasons such as separation of concerns and specialized areas of focus. It allows developers to focus on the customization and business logic of an application instead of spending time re-inventing the wheel on generic aspects. p45
• Some cons of using a framework is that without gaining expert knowledge in a specific framework, flexing a framework to do what is needed may be time consuming. Bugs that are in the framework could be difficult to find a fix for. And lastly, can provide a lot of bloat if only a fraction of the framework’s feature is being used for a given project. p48
• Expectations from a framework checklist p49 and its always desirable to have a framework that has a small foot-print.
• Best Practice is defined as a process, method, or technique that is more effective at delivering a positive outcome (one with fewest problem and unforeseen consequences) than any other process, method, or technique.
• One error in evaluating documentation is to judge good documentation with one that has a lot of samples. While having a lot of sample is useful, there needs to be more than just samples. p57
• For a framework to be successful in the adoption of the team, it has to make the developers feel comfortable with it rather than being an hindrance. Sometimes, all it takes is to have a positive tone among the team members at the beginning of a project. p62
• Developers take pride in what they do. And to keep that momentum as much as possible they should feel that they are doing something valuable. The tasks given should provide them experience that they can gain and be accepted and valuable in the industry. This provides that the job security and the need to not be concerned with how usefulness of learning something that may not be applicable to future opportunities. As the employer, using a technology that is widely acceptable is typically preferred, and this does not have to be a zero-sum issue. Both sides can have a win-win scenario. p63
• “People are the most complex component in a software project.” p69
• Members of the team may be more motivated in learning new things, adding new logic, and exploring ideas and less motivated in fixing bugs and test cases. These traits must be carefully managed in order to get the project done right and on time. p70
• Not Invested Here (NIH) – A bias in a culture or company that avoids using or purchasing existing products, research, or knowledge because of its different origin. Avoid this bias. It’s important to reuse everything around at all costs. By doing this, you can avoid problems that evolves from writing too much new code, that may require rigorous testing ,and sometimes may lead to overly complicated software. p70
• Process will be more excepted if team members participates in the creation, improvement, and defining a process rather than being enforced on. p78
• Some people may have a problem with working within a process, even if they fully understand the meeting. But the goal of a good process is quality in a reasonable time. Some will think it’s a hindrance because they rather focus on getting things done and quickly. Others may see process as a way to limit their creativity and quality and push product out the door. It is always good to have both kinds of peoples and get the best out of both types as the group can achieve quality on some and reaching goals in a given time in others though good process. p81
• Fears among developers: producing the wrong product, product of inferior quality, being late on a project, too much work in too little time. p100
• In an agile process, the process in itself is much more sensitive to the team’s competence than traditional software development approach. The reason for this is because each member is entrusted to delivery working software at any given time and with expected quality. Members must be motivated and the team is built on a layer of trust. p102
• When dealing with each other, trust is important. Trust that everyone will deliver. Respect is as important, and that encourages people to express their alternative and views which is the success in a technically-excellent design of a system and comfortable as an active member. p103
• Agile process recognizes that plans are short lived and what’s more important is to meet user requirements. Plans have little meaning in an fast pace, constantly changing world. p105
• Pair programming – Someone may ask why have 2 people do the work that can be done by one. But this is an inaccurate saying because it is not really true that two people are doing the work of one. The actual coding is not the most important of a project. It’s writing the right PHP code that is important. So in pair programming, while one is writing the PHP code, the other one is thinking ahead looking down the line for potential problems and foreseeing things. This will help reduce bugs and increase quality. p116
• “Putting together some smart people in a room will not deliver the results that we wish. The team members need to work with each other and organize themselves together for the team to operate as a single unit.” p124
• If team members are repeatedly skipping a step in the process, this may be an indication of an ineffective step in the process. We must then take steps to improve in these process or will end up left with an improper process. p152
• Team members may not want to do the same things over and over. It is important to try to balance out R&D with regular development and maintenance. Not all areas of a project will be novel and exciting. There will be tiring and boring work. Mixing exciting work with less attractive work is the only way to keep all PHP developers excited. p156
• “Quality assurance is a skill. It is often taken for granted that anyone can do it. “ p156
• “Simplicity is an art. It is tempting to go after elaborate designs, and think and argue about what is right and wrong. But from the user’s perspective, the most important thing is to get something working and get it improved step by step. Therefore, keep it simple and make it usable. Do not ever try to come up with the perfect design in the first iteration.” p158