One of my friends has worked for nearly 10 years, asked me why he needs to learn new things such as unit-testing, MVC, Multi-tier architecture (he creates 3-tier application but designs like 2-tier), Object-oriented programming or etc?
He has worked for a decade without unit-testing, uses code-behind and structure programming and it works for him. He can deliver product to customer and he has a high income.
What benefit will he see from those methodologies?
The most practical answer would be to secure his position.
Even if gets projects for now and all seems fine, there is always a danger of one day falling behind the younger and smarter who know modern tools and technologies.
Another argument is to look out for ideas to make the work more efficient. New tools and methodologies are not invented out of boredom but to take the work to the next level, improve code quality, maintainability and other aspects.
And the last argument is that it is an obligation of any decent professional (not just in IT) to continuously educate himself. If one doesn't do it, one never crosses the threshold of mediocrity.
It sounds as if your friend was in a very common trap for programmers: His employer needs an expert for the kind of code he has right now. As the code he has now becomes more and more outdated, finding experts for that kind of code is getting harder and harder. So he's paying your friend a high salary to keep him from leaving and to keep him from learning something new. This is obviously a very good position to be in: Your friend doesn't have to learn anything new and at the same time, it's getting harder and harder for his employer to replace him. That's why it's so easy to fall into this trap. It's the easiest path for both parties.
Your friend might be lucky and stay in that position until his retirement. But if his employer ever decides he doesn't need that old code any more, or goes out of business or gets bought by another company, your friend will suddenly find himself in a job market where much of his knowledge is over-specialized and out of date. Plus, learning new stuff doesn't get easier if you don't practice it. If this happens when he's in his thirties, he can still catch up. But if it happens when he's in his fifties... Well, just imagine how well someone would do in an average job interview if they didn't know anything that became mainstream after 1985.
IMHO, this effect explains a large part of unemployment among older programmers. I'm not saying there is no age discrimination, I'm just saying that this trap is very real, very dangerous and many people fall into it, as unemployment rates show.
What benefit will he see from those methodologies?
With that kind of attitude, they will see very little benefit.
He has worked for a decade without unit-testing, uses code-behind and structure programming and it works for him
They're simply resisting change. It is just a way to avoid learning.
Many, many changes will make someone better.
But, if they want to resist change, they're free to avoid learning and improving.
If he's happy with what he's doing and has a stable income, there's no reason for him to change.
Even today there are COBOL programmers with a steady income. If the platform is big enough, it'll probably be around until he decides to retire. The catch is that he'll have to work with the same platform and type of problem until then.
If he wants to do something different, he'll have to move with the market.
I dont know if OOP and n-tier are really considered methodologies they way Agile and Scrum are. OOP and n-tier are really programming paradigms/techniques.
He doesnt have to learn such techniques. But his company likely has to compete with companies that do use them. If they can compete without them, more power to him.
Each problem has a perfect tool for it, and as time goes by problem schemas start to change so the old recipies will not fit as they used to, thats why people have spent lots of time to see wich where the new problems and what is the best way to confront them (agile methodologies replacing Cascading, Objects replacing Procedures, with Objects the Layes made more sense, and so on).
Users changed, clients changed and global needs too, so the only way we can make our customers happy is changing as well.
Well keeping updated with the latest technologies is something which is an implicit rule every developer has to stick too, Ignoring this primary concept will not be of any significant help to the programmer/customer.
High income is insignificant compared to sticking to the market standard in developing quality applications sooner or later there will be a point everything will be streamlined to follow the same policy and its better to start late than never. (Fact: Customers do their research well and truly these days before they choose who can deliver their products)
What benefit he will see from these methodologies? More productivity primarily and he can assign same resources with the recent standards to produce more throughput. It's as simple as that.
Now i am beginning to understand why the phrase "Dead as a Dodo" came into place :)
methodologies provide repeatable results, and a process that can be measured and improved
new tools provide more efficient ways of solving common problems
Stone knives and bear skins worked just fine, and in fact, still work just fine. They're just less efficient than other things.
