Merken

Will I still be able to get a job in 2024 if I don't do TDD?

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
so I make it very quick because we are 5 minutes past minority this is only behavior from um she a term the uh testing parte using just remove allotment for these 10 years as given various talks at conferences about it uses several languages ranging from pi from where metal in 2004 come Drew uh scholar Ruby and all kinds of things is currently working with the um company in Sweden and 1 thing that is interesting is that she's also doing coding draws and has written the coding Dogil Handbook which is a special format where you actually sit together and you have people coding and from and everybody else commenting the that great elements of the so of somebody Russia looking forward to some families of insights about testing will and if we all always still get jobs but in a few years from any few when you hold the UN very pleased to
be invited to be here talking on this topic so when they predicting the future is good to have a model so this is a model of disruptive technology adoption that
Geoffrey Moore came up with in his book crossing the Chasm like in the 19 and he I noticed that the kind of attributes of a technology that amazing early adopters flock to it were different from the kind of activities that made that the broad mainstream the biggest the markets come to a new technology and he this idea of the chasm between the technologies can be very successful amongst early adopters and then not make the transition to the mainstream so I don't
understand this quite an interesting idea because what about you but I'm personally a bit of a serial early-adopter new shiny technologies and I'm sure there's many people here who can be this but I did stop programming Python in 1999 which was fairly early maybe know that this I also wanted more evidence and early adopter this is a letter I got from Reid Hoffman in not 2011
congratulating me on being 1 of the 1st million members of linked when they reach the 100 million members said I was on Linked In but yet it was new but about this time for about 2011 I noticed they started running these
little adverts next your profile page they weights and find some company that some of your contacts work for and this not
protect yourself you can have a new job working this company the thing is the company that they happened to pick up this 1 I was thinking how that's my worst nightmare under the job I have something to do not want and the thing is what they if if I can characterize bureaucratic cooperation which is of course a figment of my imagination does not exist
and that this this company I know that they have this group of all architects who don't like coding and they make all the decisions about what tools you to use so it is not on their approved list you can't have
it in fact you can't even download it because the machine is tightly locked down and you can't install on thing that they have approved so basically this company is pretty much guaranteed to use only use only
technologies so so when I'm talking about whether I'll be of all in 2024 I'm
really said we have built to get a job I actually want will only be able to to get a job where everyone is a technology laggard imagine some I don't want to work so is test-driven development is going to be very important to get a
good job in 2024 while I noticed another commentator Alan Kelly made this prediction already in fact he said by 2020 that it will
be the case that programmers who don't practice test-driven development will be unemployable it will not be acceptable to question TDD or claim that it is unproven and if you can't use
unity in a job interview exercise you will not get the a job so I thought this was this was early start and stop the honest I mean I'm a bit of a final tedious you may have gathered but I thought is if this right could it be that TDD is going to be
absolutely ubiquitous in less than 10 years because I as I see it TD is a disruptive technology and is subject to this problem of
crossing the Chasm it's and I think it's disruptive because it is a very profoundly different way to develop software compared with the way the most people have been doing it so far and at this point I think I need to probably defines a little bit more
closely what I mean by tested in development so i'm gonna go through a narrow definition here of T well you have to write a test drive pretty much every line of production code the
unity of tests of testing on completely isolated and not mining using mock objects and so on you do you're designing in tiny increments you you build up the coded very very gradually using a lot of refractory to collect pull together the design and you end up with hundreds of tests that will run in less than a 2nd and when they failed pinpointing exactly whether failures lines so this is a very narrow definition of
TD and last but not least when you get this to work it feels so good you feel sad to develop and and be productive and this is the kind of DVD that you might have some demonstrated by can back off Robert Martin Kevin handy this is the kind of thing that get show conferences in in short term and many developers to use this and and I think if I look at this very narrow definition detected at
the I early adopters using them but I don't see the white majority and mainstream developed developing this way most the time so what about in 10 years time I think I might need a bit of evidence to back up my place in this in the in the early adopters still and and I found a quote from ken back in 2009 when he was developing J. unit max which is a tool which
is only useful if you really doing that kind of minute-by-minute very tight feedback to the and he decided to stop developing a tool that point because he estimated the global markets of Java programmers doing this kind of TTT was only a few thousand people so that mean that was 5 years ago but I I still see this this kind of very narrow connectivity is not being very widespread so where we gonna be in 10 years so this is another normal distribution which I found
picture of on the web which I thought was kind of interesting and if your blind you might not be able to see the amount of women on this graph but that I assure you that that's a problem for the rest of us to and but anyway I was at a conference and it wasn't in the US actually he was in Europe but the the distribution of people at the conference on freight was fairly similar and I was chatting with this guy and he was really interesting and he was talking about all the cool technologies and stuff I have to close down at his feet and I was a bit surprised and he she is I
thing at this point I you never really seen a pair of shoes like this before I don't you see them with the little toes and they look quite also course about
cheese and it turns out that he wasn't just an early adopter of all kinds of programming technologies he was also an early adopter of running shoe technology this is a pair of advanced running shoes as so that the use of the time I was running around and when I go jargon is in a pair of shoes like
the 1 on the on the right here with the reading fix all and the shortest system when I bought them assured me that this was the best kind of running shoes it was going corrects my pronation and my running style and was going to be preventing during the Great and then this guy and that had a pair of the minimal 5 fingers she's to completely different and he was clearly an early adopter of this and he explained in with great
enthusiasm all the benefits of the she's so he was like saying what's got no padding on the heels whatsoever and that's a good thing because it changes the way you run and makes you don't shock you ladies and so it's really
stands also you can feel what you're running on an adaptive stride to terrorist can spread out because they've each got their own little town and gives you better lift off the really like this place down and of course the killer feature people will start to feet so this is what it's about for an early adopter so I I I
listen to listen I did some research on the internet and I became convinced some of course I bought some new running shoes I'm an
early adopter right so I was really happy with this pair of shoes online but I had to learn how to run again to some extent so I had to start going on really quite short
runs to adapt to my stride these new shoes because I was used to the kind the guy on the left you see is that to strike ground with he'll 1st when you got these really thick soles on your running shoes that feels really really good I was doing that for the with these really think issues you have to run like the guy on the right you have to put the whole foot down once and this is a bit of a change of style and took you know a few weeks to get used to it and that
actually eventually when I I got used to the shoes I was really happy I was running around the and my usual routes and enjoying the light for to us and they have to feel that when I was running on it was great thing is it and lost after a few months so I think what the technical term for it I think it is on important Swedish important
and it turns out that minus user practically invisible and just consists of very light fabric separating every turn into a kind of a waterlogged home not you can't really cold feet and this was really difficult running
around my forest track Swedish also having freezing toes so so what would you call that the Internet might do some research I find the latest content knowledge and by some new running shoes so here I am
with my at my new running shoes that have no you padding they have things all my toes can still spread out so there there is actually a separated toes on these ones this story lines and of course they all waterproof so this is the the killer feature for 1st also running but unfortunately people no longer so that the so this is a story about
disruptive technology adoption and my points from this is is basically 2 points early adopters like counts and have people ask them about what's
up close and you call and early adopters will also try out this new technology that very much proof that has an advantage I mean I just discussed were really some guys on the internet local and so when
you're looking at the technology going to the mainstream and they actually have a little bit more conservative 4 we don't want to stick out quite so much and they probably want a little bit more proof that there is actually vantage in this analogy before so that I want to relate this to test environment goes up and of course I was an early adopter of tested in development and I remember this this feeling of you and sticking out because constellation incidents where I was sitting coding in guy comes off me something he's from the next heat and he says and ask something and then he looks at my screen because double time to the test and development I've never seen anyone do that in production code she wants to watch so test environment is I think disruptive technology and I think to reach the mainstream and this more conservative types so in my needs to
adapt slightly become more practical sequence of losing the toes on issues but after do that without losing the essential benefits all the other things that we need TTG for and just like you want to keep themselves that maybe the toes were not the crucial most crucial feature that was just that was just helping them to stay can drive early adopters use it so when I'm making it to the D I think you there are some very essential benefits to its when you're doing this narrow definition of TDT you get a lot of feedback from the tests on the design and how the design is progressing are you managing to have an isolated units and you managing to you have a decoupled design you want to get this effect of self testing because that that is code that way you can push a button and it will check that is it's still working and that they're aligned itself tests in and give you that feedback about whether broken it's and that's what you need to enable you to refactor the code and of course as I mentioned before TED feels really good critical reproductive when you get out of that state just
concentrating 1st on analyzing the test I've got my attention on that and then I get to right implementation of my grandparents just focused on how to do what I want to do it how should do it so this this kind of uh essential benefits of I'm not sure how many people really have experienced utility in the narrow sense and I would encourage you to you could it wouldn't take you very long practicing a code costs to experience this now
I should explain the concert and this is an idea that Dave Thomas came up with watching his son doing karate where he was practicing these context exercises where you take a sequence of moves that you repeats until you can do them flawlessly I mean puts those moves into your muscle memory so that when your sparring in more random situation these new user just come naturally and you can do that can better so he like this 1 encoding perhaps we could do small coding problems and repeat them until we could do them flawlessly and then there is no use of test-driven development which we can actually in a more production code situation so an example of a code cost to which I have
done a bit this a very simple 1 write a function that returns true or false depending on whether the input into Jason EPA or not and period is divisible by 4 would not otherwise visible by 100 and also that is both like 400 visible you have to code it helpfully it comes with examples and these examples you test cases so this for began activities this is very it's a very is this function to write in then programmer really and but you should be able to write this PTD barrier test cases 1 by 1 and get
how loop feels and how it how is the that's how I want to feel like freedom and productivity and this this is a very simple code concept it will teach you how to test drive a simple function that returns a boolean and then of course you need to probably do another Carter which would help you to learn to test driver unit a more complex functions or or class of and cooperating classes so there and this easier and harder ones of these but they will help you to experience GTD in ideal conditions TDD when it's really working running churches retirees and 3 summers when it really works so this is a great idea but of course you have doing occurred Carter by yourself is not half as much fun as getting together with others in the calendar which just like in
karate you go to the stage you practice you across the with other people you get to the code integer to to learn about coding in a group and it's much more fun this is due to French guys who came up with the idea so it's basically
you try and do this value semi regularly and you get together maybe your team from work or for your Python user group in your town or maybe a conference just some random people and of course you he writes
encouraged code Carter's you practice TDD you can read discussed feedback and it can be it really fun and I don't actually want to go into a lot of detail now about Coding Dojo afferent book the whole mentioned that some enumerates exactly what is different about a coding data compared with any other kind of meeting record is get together and have which is also a funny but it's a little different but 1 thing I want to pick out is the the way that you could use it to a to
help you to get feedback about the people of the Territory feedback on how well you doing TDD you can also get a tool like cited this actually every time you run the test it recalls that whether they passed great failed for there was a syntax error and it couldn't actually executing test and then you can see how often you're running the tests and whether you can see those cycles to produce cycles and this is is this is a bit irregular and there's not virtuous cycles but also you
know this is example of the real part this is not me this is some again as I had in 1 of my code intelligence and then after 6 stages of similar that and you can see that it's changed the running the test more often there's a lot more green and you can start to see those cycles so that's something you can do to to fight you get an extra feedback am I doing to now and that you understand the potential
benefits of it because that's really what I want you to know when to experience what he did TED feels like when it's working and to be able to recognize problems suited to so when
you're not working your production code and you realize all i gotta write a function that's going to return a variance and that a test drive 1 of those and this gives
you the tools you need to in your production time and then you will recognize how to adapt to the dual condition because this kind of activity in the narrowest sense I think that she is only really appropriate in quite narrow conditions well and
in actually in production mode of production code is really quite hard to do and you can end up in a lot of really writing program to and so I think you need to be able to
adapt to local conditions you might be your you could but let the databases called widgets and the reason which clients and asynchronous code and everything else where it gets harder to do this kind of pure TDT so I start
thinking about TDD in a much more general sense of well actually what what are the essential parts of it it's it's and working you go retain that feeling of productivity that's kind of
essential you gotta learn to work incrementally that's 1 of the big parts with an incremental might not be quite such small steps as in the narrow version it's important to have testable units but they might not be quite as small and isolated is in that really purity yeah you need to think about designing a penalized separately from designing implementation and and probably beforehand but maybe not quite maybe your unit tests I don't you more more granular tests and this idea self testing code having code that you can ask it to the has passed optimality change and you can have self-testing code without those tests
being fast enough to run and that's really tight minute by minute late and I can still be really useful even if initial test take 10 minutes or an hour or overnight it's test self-testing code and that is was something so I I can affirm I wanted to go to talk about not just this narrow definition of TDD but what of the essential benefits you can get without actually doing that and then apply carries book here because I've been reviewing the test envelopment with Python
and he's done a good job I think of shown you demonstrating that a lot of code have to do to the when your local conditions on gender and you got jobs script and all of that stuff so I I do recommend that then I wanted to
take this a step further whatever your conditions not just Swedish or whatever but if we
talking winter and I'm looking at my running track and thinking am I cross-country skiing this is a much better idea is there are situations that he did just isn't the right
approach because I think there are some areas where TD just doesn't really do it for me and I've got 3 of them here I want to talk about the 1st 1 is city problem of requirements I don't actually know what the user needs
so I could write a bunch of tests expressing what I think they need but I don't actually know all I could write a test that I have no idea how to implement this or I've got some spaghetti legacy code of the test and I do that so these 3 problems i'm just going to look at that so this problem of
requirements I have built this beautiful teapot that I think is exactly what the user needs unfortunately I made it with chocolate and it doesn't work
so this is the problem of not knowing what the user actually this is only a problem if you are not actually use yourself so other commercial suffer falls into this category so the TDD here with unit tests and has
been some people have suggested really prolonged time that you should augmented this with a failing acceptance tests so this inner loop is you go around and over here minute-by-minute coding activity and actually is the scale of hours or days to get the whole feature working not test classes in the whole future work to the point with the acceptance test is that you can't write them in
isolation of the users were released from the US who to store users you have to talk to somebody else and there are various
methods behavior-driven development is 1 that got here with 3 meters discussions you've got specification like sample on you got an just acceptance test environment all ways to extend to not just be a thing that developers to but the teams do and I think that's kind useful when the user is not the same as yourself so when I look at
although these all the the benefits of the TDT that I put up before and I think you double the has all the same benefits because if you fundamentally doing TDD at the inner levels but if you have additional time to your hopefully building something the user needs so this is a useful extension to KDD the
next situation I had was when you realize you have no idea how to implement this and then I've put Sadaoki board here because there's a very famous example of an boron Jeffries 1 of the originators of extreme programming's rates articles in his blog where he was showing how he was going to test drive a solution sedately solver and he invited several articles device also task but the code is just know that this is is getting nowhere solving this problem he clearly has no idea how to solve this problem or a if he does he hasn't done a very good job of showing and then this is another example of Peter Norvig doing Sadaoki solve Python and the code is absolutely beautiful and if you've seen it but it's really spot on and he is using concepts like constraint propagation and backtracking search he understands the computer science of this and is a really good job without test-driven development so the point is really if you don't know how to solve the problem to is not going to lead you to the solution I don't like in my opinion it is a problem don't
find somebody knows how to solve this kind of problem and get some training or mentoring research on the internet but what are the
concepts that the next the from the start of the run Jeffries should have known about if the spike solutions and this is the by analogy with woodworking you've got a piece of wood that is a kind of never worked with before you don't really understand you just get us back in this talk hammering at the word and playing with it and try to understand how this piece of wood works and then you that it to 1 side and you take some more of this would you build your new cabinets once you learned how the thing works so this in the same way with code if you if you've never built something like this before don't try and do test-driven development just hack about play with things to try algorithms and just get to know your tools when you know enough to build the thing properly for what used to packed together to 1 side start over and then start doing TDD so that's the the classic AT and xt approach more recently some guy down
often is key and others have been talking about supply can stabilize so he started this with a spike solution and you get to know your tools you try algorithms you read up on backtracking search and constraint propagation and try and understand them and but instead is then throwing away your work you refactor it into something that can be tested with with unit tests another test so this is this is not a test-driven development because you start from code that works and that tests afterwards so if you look at
all the essential benefits of TD and you're getting most of them if you getting these testable units and because you do right the tests eventually but you're not forced to design your likelihood by API before your implementation so it's a different display different but of
course has this benefit you might go faster and more productive than if you started from scratch so this is spike stabilize the 3rd
situation where classic maybe doesn't work so well when you have spaghetti code and you can't find any units to extract and my unit tests for
and this is this is a hard problem and Michael Feathers wrote this book 7 about a decade ago in fact and he has lots of helpful
advice and spoke about how to get this code under test when doesn't have any the thing is the title of this book I think it's kind of misleading what he really should have called this book and you guys in Internet agreed with me was
this should be called unit test and the a guide for Java C + + and C because all the examples in the book or in those languages and it really is focused on adding unit test and that is really quite hard work because I unit test you have
to take risks and in the book is all about minimizing that but you still have to take some risks when you haven't gone the test you have to make some refactorings to extract some units the unit test round and as you doing that you might make the the wrong choices and just started making units that are there in the code that actually have really poor abstraction because this is legacy code and make it harder for yourself to refactor Towards better abstractions because of course if you're writing unit tests that maybe integration errors between units extracted and your unit tests when pick up on so although this is a this is a good approach is hard to do well and I would I would start start with simple system more integration testing instead basically but that would be my starting point get get the self testing code even if a self tests take hours that's that's a more stable and safe situation to be in
so this is a useful technique I find for but this kind of full-system test is approval testing now this is something you may not have heard of because at this is the case for not actually an early adopter someone innovators for this technique and so on this I really want to talk about this and so I'm gonna talk to about it and so let's say I've got a little program for a command line program that I'm calling minesweeper and it takes on standard input a text
file open and what are the odds representing the position of some mines on the minefield of the stars and reduces the standard output outputs a similar to ask you lots of augmented with this clear numbers how many minds and expertise this space of life you now some of you may remember a certain operating systems that came with the game somewhat like this in a few years ago that was kind of addictive but and you you'll notice that these kind of clears could be useful in the that game of this isn't like and this is a much much simpler version which is much easier to test this technique hence firefighters it so how you test this having check that this little command line tool is working where the unit testing approach you you come up with a little minefield and you Dusan assertions about certain positions on the output of the clues were correct and this position so you might have some code this is job stock and In approval testing you don't write set statements we rely on gathering the actual output so the approval testing approach is saying well OK this is the input data when I feed and this the standard input I get based on standard output and I will inspect that the 1st time I see it check that it's correct and I will approve it and say OK now I have a test case this input produces this output and so long as it keeps doing that everything is fine of course the
some pointers test testify the the new outputs will be different and the
test will fail with the data and show you know you you programmers using tool for this is a very clear that some zeros that that when there before the approved version matching the actual motion but is this a block or
feature well memory we can't tell so let's say this is a box
and this output is not wanted and we've got this test failure now and
I can go fix the problem until the proof outputs matches notice if I had to write research statement I might not remember to write research statements for all of these kind of edge cases and maybe my unit tests would just passed the knowledge nonexistent so this is actually real effects when I'm using this kind of testing by reason we often find defects that I didn't anticipate whenever a task and just the fact that I wouldn't have found with my unit tests so that's that's no vantage of course the other scenario is
that this is the feature and now I have a test the needs updating I want to approve the new version but the and that's fairly
with a good tool that should be pretty straightforward I just say OK I prove this new version test now passing this is very straightforward just with with the he just got 1 test failing you could imagine doing this with the unit testing tools you can imagine taking that new output and placing it
into a test case that works and he got about 3 tests and then he suddenly start thinking on this is boring and think this this text over the time you need to all support approval testing really only works with good tool support that helps you with this managing the behavior of the whole test suite with many test potentially failing in similar ways and this is the tool that I'm a contributor for which is the text test how can and approval
testing so just to summarize it about different the actual output against approved outputs updating approve versions of finding defects in state so the
Vandal king at the benefits of TDI mentioned before you don't get all of the with this kind of testing you don't have to design a as before you implement them you don't have to design test will units you just have to have testable programs and these this is different from the but has the advantage that you can test spaghetti code these tests don't care what's on the inside how well designed the thing is inside
disk has about the outputs and the so that's approval back to the the essential question of this talk having gone off on a bit of a tangent line and so as I said before the
TD in the narrowest sense has not yet crossed the Council and well will be in 10 years time but I think you probably gathered by now that I think it's more useful to talk about TDD in
a more general sense and this 1 that I showed you before with these other and advantages with similar advantages little to so when I look at these this more general version of the I can pick out self-testing codes
as something which I think actually has already crossed the council I think he ever most genes I go to our house itself tests for the occurred that probably too slow to use in the TDT and they're probably not testing isolated units and all of that but they also this is still useful and I think by 10 by 10 years time this will be pretty much of IQ test that every and every reasonably sized codebase will ship with self tests so the other the other aspects of more general TD is this thing to work incrementally running the tests often and then the test you have to run a bit faster and you can't tolerate more than a couple minutes for the test to take 1 you're developing and this is this is really more much more widespread I think than than narrow TDT but still this is not across the chasm yet but I think you will get that I think that the benefits of working incrementally all have really and people realize that I think even that the conservative majority will realize that where he incrementally is a better way of working then only running tests once a day and God is the computers yes so that would have a good point tests were run more quickly because it is not really fast again but so this other thing this thing that I think characterizes anti in the narrower sense is about using tests to drive your design and get design feedback this is not to cross the chasm and having said that I said that I'm not sure it's ever going to cost to the majority this is a very specific way of doing designs that sees some people and not others and some people like to I mean acts like a stabilized does not have a using the test drive the design approval testing does not have the test driving the design and I think that maybe this is like the toes on the running shoes works really well in some situations but actually for the majority it's just a little bit to the extremes and that people will continue to do designs in the ways that they've into what's announced to design and maybe not in this room type TD so maybe that's controversial and that's the case so
when you we still get a job in 2024 of course if you're going to have integer annual improving your skills this could really help because then your on your on your learning about how to do
TDD and that's gonna be a good thing and in interview situation if you can do a code costs that's gonna be so of course is not just about to give can and all sorts of other programs so this is my last slide I wanted to just someone I would have said it will it will be able to get a
job see if you can try to learn
DVD in the narrow sense even experienced that get to like so you give get some feedback from peers experience what it's like so you understand the essential benefits of this
technology and can apply that your local conditions I've talked about double loop test-driven development talked about spiking stabilize kind of design and approval testing these techniques which may be up-and-coming extending TDD so that it works more conditions and to answer the questions I think of course you get a job in 2024 can write self-testing code she can work incrementally and you can do design you know if you don't do your design with test 1st thank you very
minimalism residual immune to it once you have a muon because water levels in the we are going to I think about much more than 5 minutes and I just would like to move the the addition to the audience not just called according to what about all the people would be and is especially that fall where the people in Germany visually environment what you wrote with all of that would be particularly weak some of the year and other parts to the floor value just according to to use vision for all the giver of life I guess I have that character traits it's set to be released Sunday I'm also recommended over the but a question about approval testing you you have a lot of approval testing and all the benefits that came with it 1 of them was working incrementally but at least with your example it's it's not really working environment we can you explain how horrible testing an incremental development work in I didn't get that from right I glossed over that you're quite right and the thing is if you've got and you know hundred test that with all different variations of inputs and outputs you find that when you when you get when you change something in the carriage you get so that if you change too much at once all of those tests fail in in so many ways and it's really hard to clean up the mess so you find yourself closing into working in just making 1 change at a time so that you can say you can approve the new results causal those task and it's really clear that it's just that change introduce something unexpected so it's it's not it's not obvious you're quite right but my experience doing approval testing is that you do have to work incrementally doesn't work but but how do we get to the point where you can run the tests without having written the entire program at that time all right so you and you start improving the results when there incomplete so you write a program 1st adjusted has this so you start with alliance with you have this and that's the 1st iteration just which has the same amount of and you through that and then you write something that will just like the ones around all of the points you prove that and then he writes the code that will put to use phrase things in the proof that says you you do work incrementally let's assume there aren't thank you again for this wonderful talk and I have 3 things actually but we will be really quick so 1st thing and approval testing on what I reminded me of something it's it's not that you because when I think of software that's the chemistry program that calculates some some energy they did this in the seventies because they have to make sure that when you start on computer and it calculates the same values that that to be forced be put all the trials and then when you run the test we actually think differently and comparing the actual results with some fire register prepared beforehand through but I mean doing that in this kind of approach kind of knew that the the 2nd thing you can get that evening and there's another scenario that I wanted to point out where you don't use you really and this is in my opinion when you do rapid prototyping because that would slow you down you know you just want to get the current hour so about the that didn't come out with your your freedom and you have brought another question I have moved on to convince my right to do it I mean I'm I'm I'm kind of new to the testing field but it will take more time to write a program and will be more expensive and I think that's 1 of the reasons why the majority has got to get through what do you think you and you write the majority needs no proven benefits before that adopts a technology and I think the benefits of self test encodes all obvious and and I think most most people will accept that and so that's why self testing can be really already has cost thousands and the thing with which incrementally that it becomes clear when you realize how much more effective it seems to work when they're sharing occurred more often and yet you have to I don't have to finally adopted destroy stuff and I was going to convince the majority of ulcers that you just have to make the right about there was like and you have 1 more question please could you just for 1 minute still hold produced observing on the part of the different things so 1 question other so you don't have any for the top and then you just make a quick show of hands who was already using DDT in their everyday jobs In this talk I should say this is that if we need to conferences the proportion of early adopters is not so much higher 1 of the major conferences other reasons thank you all those that have a little and his life
Softwaretest
Maschinencode
Code
Formale Sprache
Mereologie
Familie <Mathematik>
Dateiformat
Element <Mathematik>
Term
Computeranimation
Metropolitan area network
Informationsmodellierung
Gruppenoperation
Vorlesung/Konferenz
Schar <Mathematik>
Computeranimation
Attributierte Grammatik
Chipkarte
Metropolitan area network
Bit
Serielle Schnittstelle
Bildschirmsymbol
Computeranimation
Metropolitan area network
Router
Systemprogrammierung
Softwareentwickler
Prozess <Informatik>
Prozess <Informatik>
Profil <Aerodynamik>
Vorlesung/Konferenz
Computeranimation
Homepage
Virtuelle Maschine
Maschinencode
Gruppenkeim
Vorlesung/Konferenz
Mailing-Liste
Computeranimation
Entscheidungstheorie
Metropolitan area network
Systemprogrammierung
Prognoseverfahren
Prozess <Informatik>
Prozess <Informatik>
Test-First-Ansatz
Programm
Computeranimation
Metropolitan area network
Bit
Punkt
Software
Prozess <Informatik>
Rechter Winkel
Test-First-Ansatz
Computeranimation
Eins
Objekt <Kategorie>
Softwaretest
Softwaretest
Universal product code
Code
Softwareentwickler
Gerade
Computeranimation
Eins
Metropolitan area network
Bit
Einheit <Mathematik>
Extrempunkt
Phasenumwandlung
Vorlesung/Konferenz
Softwareentwickler
Term
Computeranimation
Einfach zusammenhängender Raum
Metropolitan area network
Distributionstheorie
Rückkopplung
Benutzerbeteiligung
Normalverteilung
Punkt
Applet
Programm
Vorlesung/Konferenz
Computeranimation
Metropolitan area network
Software
Punkt
Rechter Winkel
Programm
Physikalisches System
Weltformel
Computeranimation
Lesen <Datenverarbeitung>
Vorlesung/Konferenz
Hebel
Computeranimation
Graphiktablett
Bit
Rechter Winkel
Mathematisierung
Vorlesung/Konferenz
Maßerweiterung
Computeranimation
Internetworking
Vorlesung/Konferenz
Routing
Term
Computeranimation
Portscanner
Weg <Topologie>
Wald <Graphentheorie>
Gefrieren
Inhalt <Mathematik>
Hebel
Weltformel
Gerade
Computeranimation
Eins
Internetworking
Softwaretest
Bit
Maschinencode
Punkt
Universal product code
Stellenring
Zählen
Inzidenzalgebra
Computeranimation
Metropolitan area network
Beweistheorie
Datentyp
Vorlesung/Konferenz
Delisches Problem
Softwareentwickler
Programmierumgebung
Analogieschluss
Touchscreen
Soundverarbeitung
Softwaretest
Rückkopplung
Folge <Mathematik>
Maschinencode
Softwarewerkzeug
Implementierung
Weltformel
Computeranimation
Einheit <Mathematik>
Softwaretest
Rückkopplung
Code
Aggregatzustand
Softwaretest
Lineares Funktional
Maschinencode
Folge <Mathematik>
Bit
Teilbarkeit
Universal product code
Programm
Kontextbezogenes System
Ein-Ausgabe
Frequenz
Computeranimation
RFID
Gewöhnliche Differentialgleichung
Ganze Zahl
Funktion <Mathematik>
Code
Festspeicher
Ein-Ausgabe
Test-First-Ansatz
Ideal <Mathematik>
Feuchteleitung
Softwaretest
Lineares Funktional
Maschinencode
Klasse <Mathematik>
Komplexe Funktion
Gruppenkeim
Laurent-Reihe
Ideal <Mathematik>
Biprodukt
Computeranimation
Eins
Loop
Einheit <Mathematik>
Druckertreiber
Ganze Zahl
Konditionszahl
Vorlesung/Konferenz
Boolesche Algebra
Rückkopplung
Datensatz
Maschinencode
Softwaretest
Verbandstheorie
Code
Abzählen
Test-First-Ansatz
Randomisierung
Gruppenkeim
Computeranimation
Softwaretest
Rückkopplung
Vektorpotenzial
Maschinencode
Logarithmus
Computeranimation
Komplexe Ebene
Softwaretest
Test-First-Ansatz
Dreiecksfreier Graph
Compiler
Hilfesystem
Fehlermeldung
Softwaretest
Lineares Funktional
Universal product code
Konditionszahl
Regulärer Ausdruck
Ikosaeder
Biprodukt
Computeranimation
ATM
Maschinencode
Universal product code
Datenhaltung
Programm
Extrempunkt
Biprodukt
Computeranimation
W3C-Standard
Client
Softwaretest
Code
Widget
Konditionszahl
Test-First-Ansatz
Mereologie
Vorlesung/Konferenz
Softwaretest
Maschinencode
Einheit <Mathematik>
Code
Minimierung
Test-First-Ansatz
Mathematisierung
Mereologie
Versionsverwaltung
Einhüllende
Computeranimation
Implementierung
Metropolitan area network
Weg <Topologie>
Maschinencode
Softwaretest
Rechter Winkel
Prozess <Informatik>
Geschlecht <Mathematik>
Konditionszahl
Stellenring
Skript <Programm>
Einfügungsdämpfung
Computeranimation
Softwaretest
Maschinencode
Softwaretest
Flächeninhalt
Code
Vorlesung/Konferenz
Knoten <Statik>
Computeranimation
Softwaretest
SCSI
Zentrische Streckung
Maschinencode
Komponententest
Punkt
Elektronischer Programmführer
Kategorie <Mathematik>
Klasse <Mathematik>
PASS <Programm>
Knoten <Statik>
Computeranimation
Teilmenge
Loop
Software
Softwaretest
Loop
Test-First-Ansatz
Vorlesung/Konferenz
Umwandlungsenthalpie
Softwaretest
Softwareentwickler
Computeranimation
Teilmenge
Softwaretest
Loop
Code
Stichprobenumfang
Test-First-Ansatz
Meter
Softwareentwickler
Maßerweiterung
Programmierumgebung
Implementierung
Softwaretest
Nebenbedingung
Maschinencode
Wellenpaket
Punkt
Web log
Güte der Anpassung
Ausbreitungsfunktion
Bitrate
Whiteboard
Computeranimation
Internetworking
Task
Prozess <Informatik>
Backtracking
Test-First-Ansatz
Ablöseblase
Extreme programming
Informatik
Bildauflösung
Softwaretest
Nebenbedingung
Maschinencode
Komponententest
Algorithmus
Ausbreitungsfunktion
Test-First-Ansatz
Klassische Physik
Wort <Informatik>
Knoten <Statik>
Analogieschluss
Computeranimation
Softwaretest
Maschinencode
Softwaretest
Einheit <Mathematik>
Dämpfung
Code
Likelihood-Funktion
Implementierung
Vorlesung/Konferenz
Computeranimation
Implementierung
NP-hartes Problem
Softwaretest
Maschinencode
Komponententest
Formale Sprache
Applet
Computeranimation
Internetworking
Metropolitan area network
Softwaretest
Uniforme Struktur
Maschinencode
Vorlesung/Konferenz
Elektronischer Programmführer
Hilfesystem
Softwaretest
Maschinencode
Komponententest
Desintegration <Mathematik>
Abstraktionsebene
Programm
NP-hartes Problem
Unrundheit
Physikalisches System
Ein-Ausgabe
Computeranimation
Integral
Physikalisches System
Softwaretest
Uniforme Struktur
Einheit <Mathematik>
Vorlesung/Konferenz
Refactoring
Auswahlaxiom
Fehlermeldung
Softwaretest
Maschinencode
Befehl <Informatik>
Komponententest
Ortsoperator
Versionsverwaltung
Zahlenbereich
Betriebssystem
Ein-Ausgabe
Raum-Zeit
Computeranimation
Data Mining
Softwaretest
Computerspiel
Funktion <Mathematik>
Prozess <Informatik>
Offene Menge
Spieltheorie
Total <Mathematik>
Zeiger <Informatik>
Brennen <Datenverarbeitung>
Funktion <Mathematik>
Softwaretest
Soundverarbeitung
Befehl <Informatik>
Komponententest
Quader
Versionsverwaltung
Programm
Schreiben <Datenverarbeitung>
Computeranimation
Task
Metropolitan area network
Programmfehler
Softwaretest
Einheit <Mathematik>
Funktion <Mathematik>
Festspeicher
Beweistheorie
Cloud Computing
Funktion <Mathematik>
Softwaretest
Suite <Programmpaket>
Softwaretest
Komponententest
Funktion <Mathematik>
Güte der Anpassung
Versionsverwaltung
Computeranimation
Gammafunktion
Funktion <Mathematik>
Softwaretest
Softwaretest
Einheit <Mathematik>
Code
Programm
Versionsverwaltung
Versionsverwaltung
Computeranimation
Funktion <Mathematik>
Aggregatzustand
Maschinencode
Bit
Code
Mini-Disc
Versionsverwaltung
Ähnlichkeitsgeometrie
Tangente <Mathematik>
Computeranimation
Implementierung
Funktion <Mathematik>
Softwaretest
Rückkopplung
Softwareentwickler
Bit
Punkt
Güte der Anpassung
Weltformel
Computeranimation
Metropolitan area network
Softwaretest
Einheit <Mathematik>
Ganze Zahl
Datenverarbeitungssystem
Prozess <Informatik>
Code
Grundsätze ordnungsmäßiger Datenverarbeitung
Datentyp
Extreme programming
Rechenschieber
Metropolitan area network
Rückkopplung
Maschinencode
Prozess <Informatik>
Güte der Anpassung
Test-First-Ansatz
Programm
Peer-to-Peer-Netz
Quick-Sort
Computeranimation
Gammafunktion
Softwaretest
Stabilitätstheorie <Logik>
Maschinencode
Computeranimation
Portscanner
Loop
Prozess <Informatik>
Konditionszahl
Code
Test-First-Ansatz
Vorlesung/Konferenz
Delisches Problem
Gammafunktion
Resultante
TVD-Verfahren
Subtraktion
Maschinencode
Punkt
Gemeinsamer Speicher
Mathematisierung
Programm
Iteration
Computeranimation
Eins
Task
Computerspiel
Prozess <Informatik>
Software
Code
Softwareentwickler
Maschinelles Sehen
Softwaretest
Addition
Rapid Prototyping
Ein-Ausgabe
Energiedichte
Datenfeld
Rechter Winkel
Datenverarbeitungssystem
Beweistheorie
Residuum
Mereologie
Programmierumgebung

Metadaten

Formale Metadaten

Titel Will I still be able to get a job in 2024 if I don't do TDD?
Serientitel EuroPython 2014
Teil 30
Anzahl der Teile 120
Autor Bache, Emily
Lizenz CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
DOI 10.5446/19966
Herausgeber EuroPython
Erscheinungsjahr 2014
Sprache Englisch
Produktionsort Berlin

Inhaltliche Metadaten

Fachgebiet Informatik
Abstract Emily Bache - Will I still be able to get a job in 2024 if I don't do TDD? Geoffrey Moores's book "Crossing the chasm" outlines the difficulties faced by a new, disruptive technology, when adoption moves from innovators and visionaries into the mainstream. Test Driven Development is clearly a disruptive technology, that changes the way you approach software design and testing. It hasn't yet been embraced by everyone, but is it just a matter of time? Ten years from now, will a non-TDD practicing developer experience the horror of being labelled a technology adoption 'laggard', and be left working exclusively on dreadfully boring legacy systems? It could be a smart move to get down to your nearest Coding Dojo and practice TDD on some Code Katas. On the other hand, the thing with disruptive technologies is that even they can become disrupted when something better comes along. What about Property-Based Testing? Approval Testing? Outside-In Development? In this talk, I'd like to look at the chasm-crossing potential of TDD and some related technologies. My aim is that both you and I will still be able to get a good job in 2024. ----- TDD hasn't yet been embraced by everyone, but is it just a matter of time? Ten years from now, will a non-TDD practicing developer experience the horror of being labelled a technology adoption 'laggard', and be left working exclusively on dreadfully boring legacy systems? It could be a smart move to get down to your nearest Coding Dojo and practice TDD on some Code Katas. On the other hand, the thing with disruptive technologies is that even they can become disrupted when something better comes along. What about Property-Based Testing? Approval Testing? Outside-In Development? In this talk, I'd like to look at the chasm-crossing potential of TDD and some related technologies. My aim is that both you and I will still be able to get a good job in 2024.
Schlagwörter EuroPython Conference
EP 2014
EuroPython 2014

Ähnliche Filme

Loading...