A very good colleague and friend of mine were discussing development today. Many of my geek friends are sysadmins, and, while that entails some programming, the conversations are usually heavily weighted in other matters, so this discussion was very refreshing for me.

My friend has most of his experience in Java, and much of my Java experience has been from school, so I asked him a question that no one has been able to answer for me: "Why is it better to have something implement an interface in java rather than just inherit from a base class?" Much of his response is stuff that I had heard already, e.g. multiple interfaces can be inherited (which I don't care for, because I think there's better solutions than multiple inheritance), allowing inheritance from a abstract class and then implementing an interface. All of that was nice, but then he said something that I knew, but hadn't really let sink in. We write code for other developers, not for the machine. The compiler makes sure that your code is readable by machine. If that's what your problem is, fire your compiler, not the developer.

My friend then went on to talk about the concept of Design by Contract, which he originally introduced to me months ago (and I have since elaborated on the concept in my personal time). It was then that he used a word that I hadn't considered using before: culture. He said developers need to get into the habit of developing a culture of programming.

Having lived outside of my native country, and having experienced many different cultures, I can definitely appreciate different cultures and ideas. A perfect example: On Sunday, I like to watch the Denver Broncos play American football. A friend of mine who lives in London prefers the Manchester United. When I lived in the Carribean, everyone watching cricket, and I mean everyone. I love soccer and cricket more than I like American football, but it's a different culture. We Americans are very business oriented, quick and to-the-point, while many other cultures are far more "people oriented," and enjoy knowing about a person long before they sit down to work with them.

What does culture have to do with programming? Simple. My culture is no better or worse than any other culture, but it's something I'm used to. Is it perfect? No. Is it universal? Nope. Does it work in this situation? Yup. It's the same with programming. Having worked as an independent contractor, I've had to learn to integrate into many different development teams. This means that I learn the culture of the team. One PHP team can be much different than another, with different practices, different methodologies, and different implementation ideas. Sometimes, there are better ideas than others, but when you start a project in one culture, it's sometimes easiest for developers to stay with that culture, even if another would have better results in X area or Y implementation. It makes the code easier to read, because that "culture" has been developed.

What are some of the ideas you have used in past development cultures that you find helpful? Is it a mishmash of various Agile practices? Was it a consensus of the team to develop a "best practices" guide, and published in a document or on a wiki? What works for you, and what doesn't?