Development Philosophies for Dev Teams

Question

Hi,

I've been developing for a few years now and have been frustrated with how some of the older programmers in my team have proceeded to design and implement without any kind of development philosophy, which generally leads to problems further down the development track, generally due to a lack of flexibility and validation. I raised this irk with my colleagues and they replied by saying "Well then, which of the hundreds of development philosophies do you suggest we use?"

This was a hard question to answer as using development philosophies when working by yourself is a lot easier than when working in a team. I am a bit partial to test driven development as it seems to provide me with the greatest feeling of security that my code is working correctly, however TDD does have its limitations, mainly in the overhead required to write all the tests and also in making sure that there are no gaps in our testing framework (which is hard to achieve when working in a team). A friend of mine swears by the Agile Unified Process (AUP) and refuses to use anything else.

My questions are

• Which development philosophies have you found to work well when developing in a team, and how have they helped you to deliver your product on time and under budget?

• What issues did you come across and how did you overcome them?

• Do you think they are even required at all?

Thanks, Dane.

Answer 1

Its very subjective, but you need to read up on these methodologies, see if your working processes match in some way, then improving things using ideas from all the methodologies. All teams are different, methodologies all work differently depending on the nature of work, ways of starting, maintaining and running projects.

Speak to the team and discuss what they are willing to do/change rather than trying to impose something on them. You will come across the issues of acceptance and change.

Its all about communication, and yes this is required.

Answer 2

My clients use a variety of methodologies (Agile/Scrum/XP etc.). From my perspective I don't see an attributable difference in performance between these.

However, I do see a definite productivity difference between teams using different aspects of these methodologies. Particularly continuous integration (CI), TDD and the willingness to create/maintain tests, and releasing often/regularly. The teams that I've worked with using these tend to succeed (regardless of what they call their methodology, have stand-up meetings etc.), and those that don't tend to struggle.

I'm not clear on whether you use such methods (I don't think you do), but rather than push a methodology, I would suggest that you introduce particular practises (most likely CI/TDD) and work from there. I think that will be an easier pill for your colleagues to swallow, and provide the most benefit. Of course you have to enforce the TDD methodology, and I would get management to buy into this early.

Answer 3

It takes years and years of experience to really understand the full potential (and limitations)of a methodology, and even more time understand when to use what.

The quickest way I think would be to read a rough description of several philosophies, pick the one that seems most fitted for the situation, and really go for that. The most important thing is to keep to one track. Don't try to mix and match. Stick to one paradigm and use it all the way.

And also it is important to train your co-workers and share your vision so they really understand why everyone have to follow these principles. If you already know what the downsides are going to be, share them as well, and make sure you make it clear how the benefits of the methodology outweighs the bad sides.

It's a lot easier said than done, though. The most important thing is to have an open dialog so everyone understand why and what you are doing.

Answer 4

1. Identify the risks that threaten the success of your project, prioritize them, and attack the most serious ones first using short iterations that objectively demonstrate resolution through successful test execution.

2. Make your project's objectives, constraints, and architecture explicit, and be certain that every member of the team understands them.

3. Correct every defect during the iteration in which it's discovered.

The primary impediment is always resistance to change. Lead by example.

Answer 5

As a contractor, you may have little influence to affect a change in development philosphy at a particular company. That's part of the price for being what most companies would consider a temp. For you as a person, sometimes the best you can do is learn to adapt to the current corporate culture and learn what works and what doesn't for when you are in a position to influence.

You can always do the test driven parts yourself so at least you know your code will pass the tests. I wouldn't look at that as overhead either, it is part of writing code to test it make sure it works. There is far more overhead associated with not writing tests.

If a place has no particular development methodology, then there are two ways to get one. First is if the developers mostly agree on what philosphy to use and they just start using it and show management it works and improves the product. Developers are remarkably free to figure out how to do their work, more so than many other professional specialties. Use this to your advantage. Get a small group of like minded folks together and just start using a method you all agree on. Indoctrinate anyone new to the group in how you do things. Show real progress and management wil get on board with it (managers like anything that makes them look good).

The second way to change the corporate culture is from the top down. Change one senior manager's mind on doing this and he can mandate that the new methodology be used. It ain't pretty and people will fight doing it (this is called resistance to change and it is a normal condition and you need to expect to deal with it.) Again build a few successes and it it gets easier, but your manager must have the gumption to stick with the policy through the hard phase of getting people to use the new method and there must be consequences for those who do not follow the new method. Sometimes having a test project with volunteers to use the methodology first can prove the value to the others, sometimes, people are just deadwood and won't change no matter what.

People who, after some time and mulitple chances to change, still refuse to get on board with the new policy will need to be let go no matter how good they are as individual developers. If you can't follow the team rules, you need to move on or be moved on. A culture change can't be accomplished without everyone eventually coming on board.

Sometimes you can use outside influences to get managers to change the way of doing business. We changed our whole development process here in order to get a certification required by one of our largest customers. HIPPA and Sarbanes-Oxley laws are also responsible for many companies formalizing a development process. If you can make a case to mamangement that formalizing the process to get some sort of certification or comply with the law is a benefit that will get them more business, then perhaps they will suddenly see the value.