How to persuade on important software development issues

Question

There are a number of concerns in software development that I consider to be important yet find continuing resistance from other developers. Topics such as using automated unit tests, test driven design, thinking about the maintenance end of the SDLC from the moment you start (i.e. thinking of future developers), usability, etc.

I do understand why there is resistance: never enough project time or budget; it may seem like overkill; devs are comfortable doing it the way they've always done it; resistence to change and so on. However, I believe these are still topics worth persuing.

What I'm looking for is advice on how to discuss with and hopefully persuade other developers and managers to the merits of newer or different approaches.

How do we do we persuade other that are natually resistant to new ideas and approaches (wherever they may be)?

What would be useful is to hear of cases from people who have been through this, either with or without success.

Answer 1

Like anything in business/sales you need to present a good ROI story (Return On Investment)

Otherwise the "hey it works, don't touch it" views prevail.

Keys:

• Save Time
• Save Money
• Save on # of QA/Developers needed to support it

Answer 2

I'm in a very similar boat and feel for you deeply. In my experience persuading others to follow any sort of best practice or development structure is next to impossible. Be sure to have plenty of good books around if anyone is interested in learning more about what your doing. Lead by example!

Good luck!

Answer 3

1. Focus on the important. Automated Unit Tests are essential.
2. Avoid religious debates. Test-Driven Design is a religion.
3. Get management buy-in. Without this, you are lost.
4. Be pragmatic. Do what works, discard what doesn't.
5. Encourage and teach, but don't be a know-it-all.
6. Help them get what they want (recognition for improved productivity and higher code quality).
7. Avoid religious debates (did I mention this?)
8. KEEP IT SIMPLE.
9. If you are management, FURTHER THEIR CAREER. Buy books. Offer training. Be committed.
10. DON'T PROMOTE STUPID SH*T. (did I mention this under pragmatism?)
11. Practice what you preach.

and finally...

Offer your thoughts as a solution to a specific problem of which management is keenly aware. Make your business case. Prove that your idea will solve their problem, and they will adopt it (and sometimes they won't, in spite of your best efforts).

Answer 4

There's actually a government agency with an incomplete acronym that is tasked with regulating the things that work in this situation. Bureau of Alcohol, Tobacco, Firearms and Explosives.

In seriousness, the main thing is you need to first persuade them to sit down and talk about it in earnest. Don't try to lay it on them in the middle of a crunch. Lay out your reasons for why you think it's a good idea, and be prepared to honestly answer their reasons of why it may not be a good idea. Don't dismiss their reasons out of hand, because nobody wants to listen to somebody who knows it all and doesn't take them seriously. Especially those of us that are unstable and dream in C++.

Answer 5

One tactic may be to convince management to allow you to undertake a small pilot project, e.g. create unit tests for a problematic area of code. If you can demonstrate the technique, and show it's benefits other developers may be inclined to follow.

I'd never done any unit testing until recently. I didn't know the tools and I simply didn't know how to write and run the tests. It seemed like something I should learn, so I took a weekend and learned phpUnit and began using it on a personal project. Turns out there wasn't much to learn, and the benefits are massive. Had someone on my team already been doing unit tests and/or there was a unit testing framework in place, I would have been writing unit tests years ago.

Jim.

Answer 6

Remember that you can't necessarily predict the future. "...thinking of future developers..." shouldn't try to anticipate the future beyond knowing that any developer will appreciate well-decomposed, DRY, clean code. Especially if that future developer is you.

But YAGNI might be a good counterargument to some of what you're saying.

Answer 7

One thing you might try--organize a "lunch and learn". Invite your fellow developers to have lunch as a group and do a little presentation on a topic (automated unit tests for example) that they may want to know about. This has worked for me, as well as others with whom I'm acquainted, in the past. It's a nice, gentle introduction to a new idea and it might get your fellow developers to think about it without feeling as if you're preaching to them.

Answer 8

This question really comes down to healthy social dynamics in a dev team. It's pretty much never a good idea to go to your fellow developers with the intent of converting them or showing them the light. If they are interested, and more importantly if your practices are truly better than theirs, then they will come ask you about your mode of development eventually, because you will get noticed.

Understand, however, that there are a lot of folks who develop software without using many of the tools that you use, and many of them are much, much better than you are at it. I can personally think of at least 3 guys I worked with who wrote code and never wrote automated unit tests and never had a problem with it. I'm talking about fellows who've shipped hundreds of thousands of lines of functional, compact, well-factored code that was only occasionally (and necessarily, in those spots) arcane. One of them did prototype-to-production development (AKA RAD/Prototyped Waterfall), another one did his own warped version of the Rational life cycle, and one frankly just wrote magical code.

I'm assuming none of those apply to the people you're trying to convert, but please don't make the classic mistake of assuming that the people you work with are stupid just because they don't work the way that you do. Prove your practices work, and let people adopt practices at their own pace. If you're good at what you do they'll come asking about something, and while you're helping them out you can show off a little about your approach.

The only legitimate practice I've found that can augment this in a non-destructive way is a team activity based around sharing knowledge. I asked my team to start doing "Tech Sessions" showing off tools and knowledge they've picked up. I don't dominate those sessions, but once in a while I get a chance to run one to show off something like unit testing or TDD practices or pattern in practical use or just some novel piece of code I've written that I happen to like.

The most important things about those tech sessions are that a) they are voluntary and b) everyone is invited to contribute topics/session presentations. There's no value attached to a particular topic or presenter. We just take a Friday afternoon once a week or once every few weeks (depending on how busy we are) and laze around looking at code as a group. It's funny what you can learn when you actually make the attempt to listen to the people to whom you're preaching.

Answer 9

One of the nice things about unit testing is that the less testing you're doing, the more each individual test can help. Write tests for your own code. Write tests for code you have to debug. Soon you will have a body of tests that will quickly accelerate your own development process. If some of your coworkers notice the benefit you reap, they might give it a try too.

Answer 10

I'd say the key here is to get people to realize that some changes now and then is good for the company, the business, the employees etc. Changes in some form is completely natural and they have always been there. People are comfortable and changing something means they have to rethink things. They want it to be "like it always has been". But there's no such thing. Somewhere back in time a change was made to make it become "like it always has been".

No changes leads to stagnation. This is the worst enemy of the business, since if competitors embrace changes more than you do, they are faster to adapt to new situations, to changes in the market etc. This is a very good argument to the sales people, apart from a good ROI story.

Stagnation can also be applied to code. If you keep doing it the way it always has been, the code will not evolve, will be harder to modify and adapt to new patterns, techniques and new types of solutions to future problems. I'm talking about a long time perspective here. For the nearest one or two months it might not be important to introduce TDD or unit tests, because it takes a while to get them going and to make them become part of the natural development cycle. But in the long run they might do miracles.

It's impossible to predict the future, but it's fairly easy to realize that things will change in the future. And if you are reluctant to change with it, you will stay in the past.

Answer 11

The first thing is to be absolutely sure of what you're promoting. Ask yourself (and make sure you have really good answers for) not just is this a good idea but why is this a good idea in this workplace and on this project.

There are very few absolutes - someone above said that automated unit tests are essential but I've heard very persuasive arguments from experience programmers as to why they're often little more than a distraction.

Just reading about it on a blog or hearing about it on a podcast or whatever doesn't mean it's a good idea for you. People often say "it's obvious" when asked why something should be used but then can't elaborate - if it's that obvious then the explanation should be easy. If you can't give a convincing 30 second pitch on why it will help then you're not ready to sell the change.

So:

1) Ask what benefit derives in your work place, on your project from the change. Because Joel says so isn't a good reason.
2) In particular what benefit derives specifically to the people who will be impacted.
3) Sell it softly - it should never ever be even an implied criticism of what is happening at the moment as the people there have time and effort invested in that.
4) Alternatively if you're going to impose it rather than sell it, don't pretend you're selling it, just say this is how it's going to be. Don't pretend people have a choice if they don't.
5) Start with a pilot or even just having it as a guideline or recommendation - this will give you more data to help you sell it and allow people to come on board at their own speed.
6) Be open to criticism of the idea. Even if you think that the comment is motivated by something else, treat it as a genuine suggestion/thought and tackle it as if it was meant in the best spirit. Be happy to change your idea if it seems appropriate or will help you gain acceptance.

Answer 12

My suggestion is to consider introducing a little bit at a time and don't go overboard on all the changes you want to make. Be prepared to deal with both justifying why something should be done and that how this changes things is accepted by managers, both administrative and project.

Where I work we have made a few changes over the past year, introducting pair-programming, test-driven development, unit tests(nUnit), web tests(WatiN), automated builds, Scrum, and this seems to be working great. Another point is that when you bring in something new, it may take a few times to sink in as there may be lapses and errors that should be excused initially but if they keep popping up then there may need to be talks to get that person on board.

Another point was to bring in outside help in the form of consultants for a short period of time, only a couple of weeks, and see what happens. It is really something to see how self-organizing a team of professionals can be, and I do mean that as a compliment given I was expecting chaos and other problems that didn't happen.