How to convince team other parts of software development are important?

Question

Sometimes, when I present a part of the software development process to certain people, say the supervisor or the manager that they don't have experience say

1. Automated unit tests and integration tests vs. their manual functional testing.
2. Using code generators, and scripts for repetitive tasks.

I sometimes met with resistance. Some of the reasons are the following:

1. They say that that's the way we do things here. Our system works and there is no need to add in our process.
2. They are busy being busy. They say is their job is to get us projects and our job is to deliver it to them to their satisfaction. They are satisfied when if it is a manual system, repetitive but on time.
3. They are very conservative about code generators. I gave them an estimate that it takes a significant time overhead for the first project to use this and time to train my teammates since this approach is relatively new to them. The overhead for the first project to them overshadows the benefit in the long run, but I explained the convenience it is to us developers, but they are always stuck to do things the old way.

What would be your strategy for this?

Answer 1

"You can get a lot farther with a smile and a gun than you can with just a smile."
- Al Capone

Just kidding, but its the first thing that cross my mind :)

The gun is a metaphor (duh), like for a bug that someone spent days figuring out that with a good process he good spend in a more fun ways.

Answer 2

You have to be a salesman, at the end of the day. You have to tell people why your proposals will make their lives easier.

If you can back up your claims with some sort of time spent/time saved data, you're onto a winner. Another thing is to get yourself a reputation gradually, by agreeing changes be implemented in phases. Implement a simple change on a small piece of the project and prove that it made a difference to them. Then roll it out a bit more, and move onto the next thing like unit testing or code generation. Given time it'll work itself out.

I don't believe you can't force people to read books, they'll shelve 'em and think you're being obnoxious. Best thing is to get small results, and use those as stepping stones to be allowed to aim for higher goals as people realise that maybe there are better ways of doing things after all.

If you're really passionate about it, you can always invest a little of your own time, and prepare a short demo (30 mins tops) that shows them how quickly you can create a tiny app without code gen, then the same app with a couple of bits code-genned. The proof of the pudding is in the eating.

Answer 3

It's easier to ask for forgiveness than it is to get permission.

There's no objective return-on-investment style measurements for "improving" a software development process. Software development is inherently hard -- it's knowledge capture -- there must be unknowns. If everything was known, you'd already have the software in hand.

Consequently, you can't ever convince a manager of anything up front.

You can only demonstrate that you are able to done something better, cheaper or faster. When they ask what the secret to your productivity is, you can show them your tools, method or approach.

Until they ask, you don't really have enough evidence to change anyone's mind. When they finally ask, then you don't need to change their mind, you need to show them your solution.

Since they don't want to derail their "do everything by hand" schedule to invest in your tools, you have to build your tools in steps, one project at a time.

Answer 4

Wait for a problem to show up and then make your move.

Answer 5

I think that only way to convince someone about something is to reveal benefits what it provides.