Add to Watchlist

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

2 views

Citation of segment
Embed Code
Purchasing a DVD Cite video

Formal Metadata

Title Will I still be able to get a job in 2024 if I don't do TDD?
Title of Series EuroPython 2014
Part Number 30
Number of Parts 120
Author Bache, Emily
License CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
DOI 10.5446/19966
Publisher EuroPython
Release Date 2014
Language English
Production Place Berlin

Content Metadata

Subject Area Computer Science
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.
Keywords EuroPython Conference
EP 2014
EuroPython 2014
Series
Annotations
Transcript
Loading...
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
Computer animation
Term (mathematics)
File format
Element (mathematics)
Software testing
Process (computing)
Machine code
Test-driven development
Mereology
Family
Formal language
Group action
Flock (web browser)
Computer animation
Scientific modelling
Open source
Attribute grammar
Computer icon
Serial port
Computer animation
Uniform resource name
Amsterdam Ordnance Datum
Bit
Average
Variance
Emulation
Web page
Process (computing)
Computer animation
Software developer
Profil (magazine)
System programming
Process (computing)
Scalable Coherent Interface
Coding theory
Computer animation
Decision theory
Electronic mailing list
Virtual machine
Machine code
Information security
Local Group
Metropolitan area network
Computer program
Process (computing)
Computer animation
Personal digital assistant
System programming
Prediction
Test-driven development
Maxima and minima
Point (geometry)
Coding theory
Process (computing)
Computer animation
Software
1 (number)
Bit
Right angle
Test-driven development
Test-driven development
Computer animation
Universal product code
Line (geometry)
Software developer
1 (number)
Software testing
Software testing
Line (geometry)
Object (grammar)
Test-driven development
Units of measurement
Machine code
Maxima and minima
Mapping
Computer animation
Term (mathematics)
Phase transition
Software developer
Multiplication sign
Bit
Test-driven development
Units of measurement
Point (geometry)
Web 2.0
Computer program
Computer animation
Java applet
Normal distribution
Feedback
Distribution (mathematics)
Connected space
Point (geometry)
Computer program
Computer animation
Multiplication sign
Software
Right angle
Theory of everything
Reading (process)
Physical system
Graphics tablet
Computer animation
Mathematics
Computer animation
Internetworking
MIDI
Right angle
Bit
Extension (kinesiology)
Term (mathematics)
Condition number
Routing
Trail
Computer animation
Internetworking
Forest
Content (media)
1 (number)
Line (geometry)
Theory of everything
Freezing
Point (geometry)
Touchscreen
Multiplication sign
Software developer
Counting
Bit
Machine code
Incidence algebra
Proof theory
Computer animation
Integrated development environment
Universal product code
Doubling the cube
Analogy
Software testing
Data type
Local ring
Proof theory
Implementation
State of matter
Feedback
Feedback
Sound effect
Machine code
Test-driven development
Sequence
Machine code
Computer animation
Estimation
Utility software
Code refactoring
Software testing
Software testing
Theory of everything
Units of measurement
Read-only memory
Computer program
Machine code
Context awareness
Vapor barrier
Bit
Machine code
Ordinary differential equation
Sequence
Test-driven development
Functional (mathematics)
Sequence
Writing
Frequency
Coding theory
Computer animation
Universal product code
Personal digital assistant
Function (mathematics)
output
Software testing
Divisor
output
Integer
Boolean algebra
Product (category theory)
Complex analysis
1 (number)
Laurent series
Machine code
Functional (mathematics)
Local Group
Coding theory
Loop (music)
Computer animation
Device driver
Ideal (ethics)
Software testing
Integer
Units of measurement
Condition number
Social class
Writing
Randomization
Computer animation
Lattice (order)
Enumerated type
Feedback
Software testing
Machine code
Test-driven development
Machine code
Local Group
Row (database)
Multiplication sign
Feedback
Time zone
Compiler
Online help
Machine code
Test-driven development
Test-driven development
Vector potential
Maxima and minima
Computer animation
Complex number
Infinite conjugacy class property
Software testing
Software testing
Cycle (graph theory)
Error message
Surjective function
Product (category theory)
Computer animation
Universal product code
Multiplication sign
Software testing
Test-driven development
Functional (mathematics)
Condition number
Computer program
Product (category theory)
GUI widget
Line (geometry)
GUI widget
Machine code
Client (computing)
Test-driven development
Mereology
Test-driven development
Machine code
Computer animation
Universal product code
Database
Database
Software testing
Condition number
Graphical user interface
Units of measurement
Asynchronous Transfer Mode
Condition number
World Wide Web Consortium
Machine code
Machine code
Test-driven development
Mereology
Test-driven development
Revision control
Mathematics
Computer animation
Envelope (mathematics)
Software testing
Software testing
Implementation
Units of measurement
Mathematical optimization
Units of measurement
Trail
Scripting language
Gender
Java applet
Machine code
Test-driven development
Maxima and minima
Process (computing)
Computer animation
Condition number
Software testing
Scripting language
Right angle
Local ring
Local ring
Condition number
Area
Computer animation
Electronic meeting system
Software testing
Software testing
Machine code
Test-driven development
Machine code
Point (geometry)
Scaling (geometry)
Mountain pass
Multiplication sign
Unit testing
Machine code
Test-driven development
Test-driven development
Subset
Category of being
Loop (music)
Computer animation
Object (grammar)
Software
Software testing
Software testing
Units of measurement
Social class
Metre
Machine code
Software developer
Software developer
Multiplication sign
Collaborationism
Sampling (statistics)
Test-driven development
Test-driven development
Syntaxbaum
Subset
Latent heat
Computer animation
Integrated development environment
Software testing
Software testing
Implementation
Extension (kinesiology)
Units of measurement
Loop (music)
Point (geometry)
Electronic data interchange
Constraint (mathematics)
Sine
Machine code
Extreme programming
Test-driven development
Wave packet
Image resolution
Flow separation
Constraint-Propagierung
Propagator
Goodness of fit
Process (computing)
Computer animation
Bit rate
Internetworking
Blog
Computer science
Software testing
Whiteboard
Abstraction
Task (computing)
Classical physics
Algorithm
Constraint (mathematics)
Machine code
Unit testing
Test-driven development
Group action
Test-driven development
Writing
Propagator
Word
Computer animation
Analogy
Software testing
Software testing
Machine code
Implementation
Machine code
Group action
Likelihood function
Machine code
Computer animation
Software testing
Software testing
Damping
Implementation
Units of measurement
Units of measurement
NP-hard
Java applet
Electronic program guide
Online help
Machine code
Unit testing
Group action
Machine code
Formal language
Computer animation
Internetworking
Code refactoring
Software testing
Software testing
Units of measurement
Axiom of choice
Computer program
INTEGRAL
Disintegration
Machine code
Unit testing
Roundness (object)
Error message
Computer animation
Personal digital assistant
output
Software testing
Software testing
Code refactoring
Units of measurement
Error message
Physical system
Abstraction
Units of measurement
Physical system
Spacetime
Multiplication sign
Function (mathematics)
Machine code
Unit testing
Open set
Number
Revision control
Data mining
Optical disc drive
Video game
Process (computing)
Pointer (computer programming)
Computer animation
Personal digital assistant
Function (mathematics)
Statement (computer science)
output
Software testing
Software testing
Game theory
output
Position operator
Operating system
Computer program
Read-only memory
Software bug
Sound effect
Function (mathematics)
Unit testing
Revision control
Proof theory
Computer animation
Personal digital assistant
Function (mathematics)
Statement (computer science)
Cuboid
Software testing
Software testing
Units of measurement
Units of measurement
Writing
Task (computing)
Revision control
Suite (music)
Goodness of fit
Computer animation
Personal digital assistant
Function (mathematics)
Multiplication sign
Software testing
Software testing
Unit testing
Function (mathematics)
Computer program
Machine code
State of matter
Set (mathematics)
Function (mathematics)
Machine code
Revision control
Computer animation
Function (mathematics)
Revision control
Software testing
Software testing
Units of measurement
Units of measurement
Machine code
Multiplication sign
Similarity (geometry)
Bit
Function (mathematics)
Machine code
Test-driven development
Tangent
Revision control
Computer animation
MiniDisc
Software testing
Implementation
Units of measurement
Point (geometry)
Software developer
Multiplication sign
Goodness of fit
Software testing
Integer
Information
Process (computing)
Theory of everything
Units of measurement
God
Metropolitan area network
Machine code
Computer
Feedback
Bit
Extreme programming
Test-driven development
Group action
Process (computing)
Malware
Computer animation
Personal digital assistant
Software testing
Data type
Metropolitan area network
Slide rule
Computer program
Cybersex
Feedback
Machine code
Test-driven development
Test-driven development
Peer-to-peer
Goodness of fit
Process (computing)
Computer animation
Uniform resource name
Quicksort
Surjective function
Cybersex
Machine code
Test-driven development
Group action
Test-driven development
Machine code
Writing
Loop (music)
Process (computing)
Computer animation
Doubling the cube
Software testing
Software testing
Surjective function
Stability theory
Condition number
Scalable Coherent Interface
Rapid Prototyping
Point (geometry)
Computer program
Multiplication sign
1 (number)
Mereology
Computer
Food energy
Field (computer science)
Video game
Mathematics
Software testing
Subtraction
Task (computing)
Addition
Machine vision
Software developer
Shared memory
Machine code
Residual (numerical analysis)
Proof theory
Process (computing)
Computer animation
Integrated development environment
Software
output
Right angle
Iteration
Bounded variation
Resultant
Loading...
Feedback

Timings

  699 ms - page object

Version

AV-Portal 3.8.0 (dec2fe8b0ce2e718d55d6f23ab68f0b2424a1f3f)