Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 85 posts at DZone. You can read more from them at their website. View Full User Profile

Programmers Without TDD Will be Unemployable by 2022

  • submit to reddit
New year is traditionally the time of predictions, and several of the blogs I read have been engaging in predictions (e.g. Ian Sommerville “Software Engineerng looking forward 20 years.”). This is not a tradition I usually engage in myself but for once I’d like to make one. (I’ll get back to software economics next time, I need to make some conclusions.)

Actually, this is not a new prediction, it is a prediction I’ve been making verbally for a couple of years but I’ve never put it on the record so here goes:
By 2022 it will be not be possible to get a professional programming job if you do not practice TDD routinely.
I started making this prediction a couple of years ago when I said: “In ten years time”, sometimes when I’ve repeated the prediction I’ve stuck to 10-years, other times I’ve compensated and said 9-years or 8-years. I might be out slightly - if anything I think it will happen sooner rather than later, 2022 might be conservative.

By TDD I mean Test Driven Development - also called Test First (or Design Driven) Development. This might be Classic/Chicago-TDD, London-School-TDD or Dan North style Behaviour Driven Development. Broadly speaking the same skills and similar tools are involved although there are significant differences, i.e. if you don’t have the ability to do TDD you can’t do BDD, but there is more to BDD than to TDD.

The characteristics I am concerned with are:
  • Developer written automated unit test, e.g. if you write Java code you write unit tests in Java... or Ruby, or some other computer language
  • The automated unit tests are executed routinely, at least every day
This probably means refactoring, although as I’ve heard Jason Gorman point out: interest in refactoring training is far less than that in TDD training.

I’d like to think that TDD as standard - especially London School - also implies more delayed design decisions but I’m not sure this will follow through. In part that is because there is a cadre of “designers” (senior developers, older developers, often with the title “architect”) who are happy to talk, and possibly do, “design” but would not denigrate themselves to write code. Until we fix our career model big up front design is here to stay. (Another blog entry I must write one day...) 

I’m not making any predictions about the quality of the TDD undertaken. Like programming in general I expect the best will be truly excellent, while the bulk will be at best medicare.

What I am claiming is:
  • It will not be acceptable to question TDD in an interview. It will be so accepted that anyone doesn’t know what TDD is, who can’t use TDD in an exercise or who claims “I don’t do TDD because its a waste of time” or “TDD is unproven” will not get the job. (I already know companies where this is the case, I expect it to be universal by 2022.)
  • Programmers will once again be expected to write unit tests for their work. (Before the home computer revolution I believe most professional programmers actually did this. My generation didn’t.)
  • Unit testing will be overwhelmingly automated. Manual testing is a sin. Manual unit testing doubly so.
And I believe, in general, software will be better (fewer bugs, more maintainable) as a result of these changes, and as a result programmer productivity will be generally higher (even if they write less code they will have fewer bugs to fix.)

Why do I feel confident in making this prediction?

 Exactly because of those last points: with any form of TDD in place the number of code bugs is reduced, maintainability is enhanced and productivity is increased. These are benefits both programmers and businesses want.

The timescale I suggest is purely intuition, this might happen before 2022 or it might happen after. I’m one of the worst people to ask because of my work I overwhelmingly see companies that don’t do this but would benefit from doing it - and if they listen to the advice they are paying me for they start doing it.

However I believe we are rapidly approaching “the tipping point”. Once TDD as standard reaches a certain critical mass it will become the norm, even those companies that don’t actively choose to do it will find that their programmers start doing it as simple professionalism.

A more interesting question to ask is: What does this mean? What are the implications?

Right now I think the industry is undergoing a major skills overhaul as all the programmers out there who don’t know how to do TDD learn how to do it. As TDD is a testable skill it is very easy to tell who has done it/can do it, and who just decided to “sex up” their CV/Resume. (This is unlike Agile in general where it is very difficult to tell who actually understand it and who has just read a book or two.)

In the next few years I think there will be plenty of work for those offering TDD training and coaching - I regularly get enquiries about C++ TDD, less so about other languages but TDD and TDD training is more widespread there. The work won’t dry up but it will change from being “Introduction to TDD” to “Improving TDD” and “Advanced TDD” style courses.

A bigger hit is going to be on Universities and other Colleges which claim to teach programming. Almost all the recent graduates I meet have not been taught TDD at all. If TDD has even been mentioned then they are ahead of the game. I do meet a few who have been taught to programme this way but they are few and far between.

Simply: if Colleges don’t teach TDD as part of programming courses their graduates aren’t going to employable, that will make the colleges less attractive to good students.

Unfortunately I also predict that it won’t be until colleges see their students can’t get jobs that colleges sit up and take notice.

If you are a potential student looking to study Computer Science/Software Engineering at College I recommend you ignore any college that does not teach programming with TDD. If you are a college looking to produce employable programmers from your IT course I recommend you embrace TDD as fast as possible - it will give you an advantage in recruiting students now, and give your students an advantage finding work.

(If you are a University or College that claims to run an “Agile” module then make sure teach TDD - yes, I’m thinking of one in particular, its kind of embarrassing, Ric.)

And if you are a University which still believes that your Computer Science students don’t really need to programme - because they are scientists, logisticians, mathematicians and shouldn’t be programming at all then make sure you write this in big red letters on your prospectus.

In business simply doing TDD, especially done well, will over time fix a lot of the day-to-day issues software companies and corporate IT have, the supply side will be improved. However unless companies address the supply side they won’t actually see much of this benefit, if anything things will get worse (read my software demand curve analysis or wait for the next posts on software economics.)

Finally, debuggers are going to be less important, good use of TDD removes most of the need for a debugger (thats where the time comes from), which means IDEs will be less important, which means the developers tool market is going to change.
Published at DZone with permission of Allan Kelly, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Barry Smith replied on Thu, 2014/01/09 - 6:34am

While I'd agree TDD is one of the most important skills out there, there are a couple of reasons to question your prediction. I recently read The Mythical Man Month which happens to talk about the vital importance of automated test suites - in the 1970s. Maybe a reasonable prediction then would have been that anyone not doing TDD by 1985 would be unemployable.

Interestingly the author also talks about the observation that complex systems can never be implemented in one go, but are only successful when they evolve from simpler systems - which sounds to me a lot like Agile - again, in the 1970s.

Clearly our industry has a greater capacity to ignore best practice than you realise :-)

Allan Kelly replied on Thu, 2014/01/09 - 12:29pm

Thanks for pointing that out Barry, it a while since I (re)read MMM.

A reasonable observation - one I hope is wrong. 

In 1974 processor cycles were expensive and few people had easy access to machines.  Brooks could see the benefits but the argument didn't catch. Hopefully now CPU cycles are dirt cheap and we all have as much power in our pocket as he had in a room automated testing has more chance.

I sometimes wonder if the while "agile" movement is about correcting a wrong turning the industry took somewhere about 1980.

Karl Peterbauer replied on Thu, 2014/01/09 - 2:24pm

 Ummm yes, TDD is valuable and may become mainstream.

But the rest of your conclusions seem greatly exaggerated. It's a simple matter of fact that any form of testing cannot prevent any exceptional situation which is not anticipated by the developer, or which is knowingly ignored (which happens quite frequently in daily business). Just think of the Y2K-bug: If a system is designed to store year values with only two digits, then it does not make any sense to write test cases for years exceeding the anticipated time range, they will always fail anyway (until they are finally commented out by somebody).

Really bad bugs don't show up in unit tests (testing concurrency is still in it's infancy, isn't it?). TDD will neither make debuggers obsolete (because the code still may have bugs during development), nor will it change the IDE and tooling landscape.

Jarek Krych replied on Thu, 2014/01/09 - 3:02pm

I agree in principle with this prediction that TDD is a must practice that everyone in our profession should master. This is reality now and it is hard for me to believe when hear some people saying, "I don’t need it, I write good code and TDD is a waist of time". IT tells me that most of those people never tried TDD.

Like many, I didn’t learn it at school but simply got into it during my first work, when searching for a way to test my systems. To my surprise, I learned that TDD not only allowed me to test the validity of my algorithms (basic, alternative flows) but that it also comes with the benefits of code refactoring, documenting and great support for regression testing.

I know what many will say, it takes time and money to develop tests. I encourage everyone to give it a try. In a long term, it pays off big time.


Allan Kelly replied on Fri, 2014/01/10 - 4:12am

Thanks for that Jarek,

Interesting to note that in the Twitter stream about this article (no hashtag, you'll have to look at @allankellynet and the interactions) many area expressing pessimism that this will come to pass by 2022.  But from what you, and a few other people say, this is already the norm in many many places.

Mark Clark replied on Fri, 2014/01/10 - 9:38am

 "while the bulk will be at best medicare"

I had no idea the Affordable Care Act was so far reaching.  ;)

Dean Schulze replied on Fri, 2014/01/10 - 11:04am

It would be nice to see some metrics from the TDD crowd instead of the same hype repeated over and over again.  Do you have any metrics, Allan?

The only attempt at TDD metrics that I know of is this study which, incredibly, didn't track development time.  They report a 40% - 90% reduction in bugs for a "subjective" increase in development time of 15% - 35%, but that's hardly compelling given that they guessed at development time.  The studies only comparison was development with TDD against development without TDD.  It did not compare how TDD stacks up to other forms of testing.  An obvious question is if the increased development time for TDD gave better results than increasing traditional QA time, but they didn't consider that.  Maybe they decided after the fact to turn their projects into a study of the effectiveness of TDD, but it's a poorly designed study.

Here's another perspective on TDD.  TDD alone isn't enough, but TDD advocates don't mention how TDD relates to other forms of testing or how various forms of testing could be combined for greatest benefit.

The word that comes to mind when I hear TDD advocates talk is parochialism.

Mark Clark replied on Fri, 2014/01/10 - 11:23am in response to: Mark Clark

 Nice article BTW.  I don't think they'll be unemployable.  I think they'll be doing some form of TDD!

Thai Dang Vu replied on Fri, 2014/01/10 - 11:40am

 I think the author got mad with the bugs in his company, so he wrote this post :-)

Eric Owens replied on Fri, 2014/01/10 - 3:03pm

 Can't say I agree.   While many companies talk about doing TDD, I believe the reality is something different.  I've yet to work anywhere that TDD has been mandated.  Even the companies that said how important it was, when I interviewed with them, didn't really practice it.  In my experience, maybe a couple developers would take it seriously or maybe some people would create a few unit tests for a project but I just haven't witnessed anything that would lead me to believe the authors claim.

I'm not saying there aren't companies that take it seriously, I just don't think there are enough organizations that serious about it to make, otherwise talented, developers have to worry about finding a job if they don't practice TDD.

Serguei Meerkat replied on Sun, 2014/01/12 - 1:13pm

Test Driven Development is not just about writing automation tests. It is about driving the design by testing (as the name suggest).

I believe that writing tests is the future and it is not going away. Why? Because it make sense, it is not a "methodology" (unlike TDD) but simply a measure to ensure the quality of ever-changing code.

On the other hand driving your development by test is a fad that will pass the same way as many other IT fads did.

Lund Wolfe replied on Mon, 2014/01/13 - 1:00am

I do like the phrase "design driven development".  I also like the idea of designing the application for testable chunks.  These are a huge value add.

Regardless of TDD, it would be interesting to know if the quality of software has improved over the last 10, 20, 30+ years or will improve over the next x years.  Have OO, new languages, development/management processes  (like agile), patterns, frameworks, or libraries even had an impact ?  We can certainly build much larger and more powerful systems, and build them much faster.  Supply has increased rapidly but demand/expectation is still right behind it.

I expect there will still be many different companies hiring for many different qualities.  Two and four year colleges will still be happy to produce programmers that understand data structures and algorithms.  Companies will still be happy to hire programmers with logic skills.

The only constant is change, but what and when is anyone's guess.

Loren Kratzke replied on Mon, 2014/01/13 - 6:40pm

 Everything will be test driven the day that requirements are all in UML (a giant printed out hard copy that is 18 feet long), every client understands everything about the final product before it is created, and every edge case and every possible scenario has been planned out and accounted for in advance. Of course at that point, you can pretty much push a button to generate code because all of the work has been done.

I will hang on to my debugger for the moment just in case that doesn't work out as planned, thanks anyway.

Allan Kelly replied on Tue, 2014/01/14 - 4:41am


Oleksandr Alesinskyy replied on Wed, 2014/01/15 - 9:44am

I would strongly disagree with the prediction. While automated testing is very important the "tests first" approach does not suit all. Many people prefer to develop not in small increments but in "cohesive batches". For them TDD becomes a major productivity brake. So it is a matter of personal preferences. And note that TDD not necessarily results in a better code than a properly applied "test after" approach.

The good thing is that both approaches may be used in parallel inside the same team - depending on individual developer preferences. As far as at the moment of commit all necessary tests are present.

Steven Dearborn replied on Wed, 2014/01/15 - 9:29am

See the next entry.

Steven Dearborn replied on Wed, 2014/01/15 - 9:28am

I have implemented automated test-driven development for several products and have done test-driven design on a few fixed-price enhancement and maintenance projects - it has been a positive, enriching and rewarding work experience every time!  Make the commitment, it really works.

Automated tests free-up scarce testing talent to focus on strategic, high-value "Exploratory Testing".  One of the testers at Google gave a terrific presentation on this topic, demonstrating the tools he uses.  The battery of automated unit, service, component, functional, security and performance tests serve as the "quality gatekeeper"  for products under development or change: they serve as a constant monitor and reminder to those involved.

Automated testing requires up-front investment and recurring costs to maintain the test with code changes: there is a cost that the product development organization, its stakeholders and decision-makers need to understand and act upon.  I would add this to the costs of developing and further maintaining the product.

There are great Open Source automated testing tools, so try them out, learn them and add your new skills to your resume!

Burabari Kpai replied on Wed, 2014/01/15 - 11:15am

I am one of those who question TDD.

Why? Because humans write the code & humans write the tests. There is no guarantee that humans wont write buggy tests.

l would rather invest in improving my coders than multiplying points of possible failure.

Jose Maria Arranz replied on Wed, 2014/01/15 - 2:44pm

Ever the same conceptual "bug": identifying TESTING with TDD (one approach of testing)

Allan Kelly replied on Wed, 2014/01/15 - 3:08pm in response to: Steven Dearborn


Thanks for your comment.  What you describe is exactly what I believe.  Its good to have someone else describe it from direct experience.

I probably over did it in my comments on manual testing, I believe there will always be an element of manual testing - exactly as you say after the automated tests.  But I so rarely see true exploratory testing, usually it is manual testing in the absence of any automation.


Allan Kelly replied on Wed, 2014/01/15 - 3:10pm in response to: Burabari Kpai

Burabari, doing TDD is improving your coders.

TDD - and no other method I know of - guarantee's software will be bug free but all the evidence I have tells me it reduces - sometimes vastly reduces - the number of bugs that are there.

If not TDD then what?

Manual Unit tests?

If not manual unit tests then what?

Static analysis tools, code reviews and similar are good but you can use all these techniques, they are not exclusive.

Oleksandr Alesinskyy replied on Wed, 2014/01/15 - 4:27pm in response to: Allan Kelly

I guess you mixed up TDD and CI.

Automated testing doesn't imply TDD.

Serguei Meerkat replied on Wed, 2014/01/15 - 4:40pm in response to: Allan Kelly

Yes, many people make this mistake assuming that TDD is a synonym to automated testing. It is not.

TDD is a methodology that demand the design to be led by tests. It demands writing tests before writing the code and it often puts testability of the code above design considerations.

Majority of developers who committed to automatic testing and always write automated tests for their code don't follow TDD methodology.

Arthur Gorr replied on Wed, 2014/01/15 - 6:26pm

It goes the other way too.  As a developer I would have serious reservations about joining an organization that does not want to practice TDD.  Not doing TDD but wanting to go there is not ideal but doable.  But outright against?  I'd need some convincing.

Aside: Earlier in my TDD career I was in such an organization and was actually specifically instructed not to write tests.  Is there a WTF for that?  I wrote tests anyway on the DL, just did not commit to source control.  In retrospect my tests were technically not unit tests, rather integration tests, but still valuable.

Hendry Betts replied on Wed, 2014/01/15 - 9:33pm

The only _real_ problem with TDD, as others have pointed out, is that developers can see positive and negative cases to their code, they cannot find edge cases. TDD is very important to give code coverage statistics as well as minimizing the potential for straight-out code bugs.

TDD coupled with a SOLID QA department produces top quality code.

Loren Kratzke replied on Thu, 2014/01/16 - 2:06am in response to: Allan Kelly

 You guys are full of shit. And I mean that in the nicest possible way.

Dave Beck replied on Thu, 2014/01/16 - 5:31pm

Nothing against the article, but I'll believe a prediction like this when most shops I see are practicing ANY automated unit testing, let alone full-blown TDD.  It's a great concept in both theory and practice, yet it is still a tough sell in many shops because usually management blows their top when you try to explain the benefit of not coding anything until you've written tests for it.  That's been my experience anyway in both small and large shops, even in companies that are 'technology' companies.  YMMV

Raging Infernoz replied on Thu, 2014/01/16 - 8:34pm

A nice idea, but a design fad, rather like many fad Project Management Methodologies (like the horrible SSADM), and who will write tests for the tests ..... ad-infinitum?  You can't design everything, somethings just evolve much better than anyone could design them up front.

Corporate Management will never agree unless they have a cost+ budget and don't mind paying for extra time; you wish, I'd be bored silly!

I'm struggling just to find time to write surgical automated unit tests for existing code, let-alone new projects, and there are lots of other bigger payoff R&D I could be doing to get better gains.  It is rather like optimisation; early optimisation without profiling, can be a complete waste of time, and even make things worse!

When will people realise that good Development is more like art than production line engineering work?  Developers vary.

I only do automation for tasks which I have repeated, and where automation is practical and affordable.  In some cases, tasks can vanish when I find or devise the correct higher level tool or abstraction; this requires learning, doing, playing, and prototyping rather than stagnant design assumptions.

Dave Nicoll replied on Fri, 2014/01/17 - 3:41am

Interesting article. What do you think this means for the QA role?

Arthur Gorr replied on Fri, 2014/01/17 - 9:47am

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.