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?

  • How large are the teams he works on? What kind of software do they produce? – fredoverflow Apr 25 '11 at 18:02
  • @FredOverflow: His team has around 5 programmers, he's working on software for business (sale, stocking, accounting etc). – Anonymous Apr 25 '11 at 18:08

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.

  • 2
    +1 - consider what happened for MS-DOS programmers when suddenly they needed to write Windows-programs. – user1249 Apr 25 '11 at 18:27
  • Or VB6 programmers when they needed to write webapps. Oh, wait, we are still cleaning up that mess (webforms) . . . – Wyatt Barnett Apr 25 '11 at 18:35
  • 1
    This is a great argument in favour of learning all these methodologies; as far as adopting them is concerned, I'm not entirely convinced. For example, some methodologies may make the work significantly less efficient depending on the context (think of hacking together a quick WebForms app with just 3 pages vs. doing a full MVC design). – Aaronaught Apr 25 '11 at 21:51
  • @Aaronaught: That is so but you're only able to say that because you are familiar with those methodologies in the first place. If you were reluctant to get yourself acquainted with them throughout the years, you wouldn't be now in a position to give any judgment at all, right? – user8685 Apr 26 '11 at 7:33
  • That's what I said, wasn't it? It's an argument for learning the methodologies but not necessarily for using them. Right tool for the job and all that. – Aaronaught Apr 26 '11 at 13:35

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 the benefits are attitude-dependent, then perhaps the methodologies are placebos. – ProdigySim Apr 25 '11 at 18:36
  • 2
    @ProdigySim: Learning is attitude-dependent. Benefits are learning dependent. – S.Lott Apr 25 '11 at 18:40

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.

  • 1
    I think that's a red herring. There never were that many COBOL programmers to begin with (because when COBOL was popular, there simply weren't that many programmers) and almost nobody learns COBOL today, so the supply is scarce and stable. Demand is stable too, so the prices are stable. The market for e.g. Java programmers is very different. There are far more Java programmers and their numbers are increasing. There is also far more progress than in a COBOL environment. If you're 10 years behind in that area, finding a new job is a lot harder. – nikie Apr 25 '11 at 19:46

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.