tag:blogger.com,1999:blog-12948038.post3581789062874627760..comments2023-07-29T09:15:17.416+01:00Comments on allan's blog - Agile & Digital Business: Programmers without TDD will be unemployable by 2022 (a prediction)allan kellyhttp://www.blogger.com/profile/06262139490250478379noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-12948038.post-13107866149233886682014-08-14T23:56:20.014+01:002014-08-14T23:56:20.014+01:00Check TDD is Dead (DHH). Just google it. It is abo...Check TDD is Dead (DHH). Just google it. It is about time the a prominent figure comes out. Even with best intentions good people and good developers become zealots due to radical or extreme methods. A few years ago there was a method called 'Extreme Programming' which saw programming as a pair activity. Unfortunately, it ended up with witch hunting about non social developers (sometime the 'best' of them). <br /><br />So live and let live - the world is full of good developers from different cultures and styles of work. <br /><br />Lastly, development skills are also a result of hard earned experience. Telling a developer that he should change is like telling him to question reality - what he does actually works but he needs to change. <br /><br />The loss will be of the industry. Maybe it will need to 'first test' it in order to wake up and let go.<br /><br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-27418999470256409622014-05-13T06:04:50.246+01:002014-05-13T06:04:50.246+01:00Very Nice post!Very Nice post!mikehttp://www.pmstudy.comnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-4034223419266414902014-05-12T09:43:49.368+01:002014-05-12T09:43:49.368+01:00I am agree with you allen what your conclusion ove...I am agree with you allen what your conclusion ove here.This is gonna help me a lot.Stephnihttp://www.scrumstudy.comnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-47002590972895361442014-05-03T03:29:26.648+01:002014-05-03T03:29:26.648+01:00By 2022 I'll be the employer!By 2022 I'll be the employer!Anonymoushttps://www.blogger.com/profile/09340167158930362305noreply@blogger.comtag:blogger.com,1999:blog-12948038.post-73483159367386963862014-03-06T09:26:09.287+00:002014-03-06T09:26:09.287+00:00Thanks Chris,
> You don't seriously believ...Thanks Chris,<br /><br />> You don't seriously believe your prediction do you? <br /><br />Yes I do, I'm not in the habit of writing blog entries I don't stand behind and nothing in the last 2 months has lead me to change my opinion.<br /><br />I think your observation on OOP fly's in the face of reality: just about all modern languages and systems are object oriented. Except for the functional languages and even some of them support OOP.<br /><br />I do agree with you about systems being more complex than the sum of their parts, in fact I think that supports my case. These big systems are the sum of many parts, if the parts don't work then the system won't work. Simply wiring together defective parts will not fix the defects.<br />allan kellyhttp://www.allankelly.netnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-12767646978753397392014-03-05T17:52:31.806+00:002014-03-05T17:52:31.806+00:00Laughable!
You don't seriously believe your p...Laughable!<br /><br />You don't seriously believe your prediction do you? <br /><br />I have never ever worked anywhere that used TDD. I haven't even heard anyone talk (seriously) about using it<br /><br />There's far, far, too much wrong with TDD (or ANY methodology) that would make it suitable to fit all business needs - kinda like OOP! Look how that flopped, and you still get people preaching it to the roof tops.<br /><br />What it boils down to is systems are more complex than the sum of their parts. I could go on but I'll just encourage you to research it yourself.<br /><br />-- ChrisAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-60043896394993228872014-01-22T09:00:16.901+00:002014-01-22T09:00:16.901+00:00Anonymous, I'd love to see your analysis. Can ...Anonymous, I'd love to see your analysis. Can you provide a link? Or describe it?<br /><br />I'm sure you will understand my reservation in agreeing with you until I've seen the analysis myselfallan kellyhttps://www.blogger.com/profile/06262139490250478379noreply@blogger.comtag:blogger.com,1999:blog-12948038.post-9939289742782351982014-01-22T08:45:29.000+00:002014-01-22T08:45:29.000+00:00Our analysis show that TDD is a poor substitute fo...Our analysis show that TDD is a poor substitute for thinking. None of our top 10% coders to anything resembling TDD. They think, code and deliver.<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-85673095183399616992014-01-19T10:40:52.594+00:002014-01-19T10:40:52.594+00:00Thanks for a well through out reply, Anonymous - I...Thanks for a well through out reply, Anonymous - I only wish you had given your name. <br /><br />I agree to some degree with just about everything you've written.<br /><br />allan<br />allan kellyhttps://www.blogger.com/profile/06262139490250478379noreply@blogger.comtag:blogger.com,1999:blog-12948038.post-25295553742294543272014-01-19T07:35:28.226+00:002014-01-19T07:35:28.226+00:00So black & white...
In 2022 I'd hope comp...So black & white...<br /><br />In 2022 I'd hope companies would expect interviewees capable to reflect on how and when TDD is a good fit, as well as how they use it in their development.<br /><br />TDD is great, but not a panacea. In every project, there's a competition for some limited resource: developers, budget, calendar time, environments, etc. Some are finite, others can be overcome through investment. By mandating one particular practice, you leave less room for other practices that might be more appropriate for the situation.<br /><br />Instead of throwing out predictions, one could: <br />1. ask Kent Beck about when TDD is not appropriate, and the trade-off between TDD and getting features out quickly, even if of less quality.<br />2. ask Peter Norvig about when a little "Think-First Design" (my words) trumps a Test-Driven Design in his sudoku shoot-out against Uncle Bob<br />3. Look at the trade-off between a little upfront design vs. a lot of heavy refactoring due to bad design decisions evolved through TDD. In a complex system, it frequently happens that tests are designed wrong when they are first written (implemented in the wrong module, ends up with an inappropriate api, works in isolation, but can't be hooked up with the rest of the system, etc.). The tests are then the largest hurdle to refactoring.<br />4. You could update relevant research, especially meta-studies. Most TDD fashionistas will quote you anecdotal evidence, or reference one or two small-group studies which proves their point. But I hope by 2022 there will be a lot more in-depth research available to provide the necessary nuances.<br /><br />Just for the record, I'm several years into a large project doing TDD. For the first 2 we mandated TDD. Now we just encourage it as a good habit, but are fine if people break the rules as long as they're justified. Of course - if their code breaks or anything else, we expect them to produce the justification.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-58208693927356164152014-01-16T15:12:55.657+00:002014-01-16T15:12:55.657+00:00In ten years, no one will remember what TDD was in...In ten years, no one will remember what TDD was in the ancient times.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-88955659100413500582014-01-16T10:47:26.756+00:002014-01-16T10:47:26.756+00:00Are people familiar with Steve Freeman's prese...Are people familiar with Steve Freeman's presentation "Test-driven development (that's not what we meant)"? https://vimeo.com/83960706 <br />Before TDD has any chance of becoming ubiquitous it'll first have to overcome that hurdle. Given that 10 years of agile has generated more far far more simulacra than true adoptions, our predominanting organisational cultures show a disposition towards local optimisation rather than transformational changes.Anonymoushttps://www.blogger.com/profile/16672617468996672921noreply@blogger.comtag:blogger.com,1999:blog-12948038.post-35381915456516143072014-01-13T12:58:05.096+00:002014-01-13T12:58:05.096+00:00People are not going back to stone age programming...People are not going back to stone age programming. IDE are tools to help you, not some evil. In future Developers will be more focused on developing less bugged code than documenting unit test cases in excel sheets. There will be tools to run tests which auto-create unit test cases based on tagging in code. Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-81208257428046042532014-01-10T04:00:35.395+00:002014-01-10T04:00:35.395+00:00I was the same as you several years ago, until I j...I was the same as you several years ago, until I joined a Java project that already had full regression testing that ran every night. If you wrote code, you had to write a test to prove that the code worked. No regression test meant that the feature or bug fix was not complete. If a bug was found in the field, that meant that we didn't have a test for that scenario - so we created a test to shine a light on the bug; fix the bug and the test passes... no more bug.<br /><br />I was initially pretty down on the whole thing because it added time to developing new features, until one night the regression test broke when I added a new feature and made an inadvertent change to some existing code to support the new feature. It turned out that what I changed broke a different part of the system that depended on it. It was a seemingly simple change, but had unforeseen consequences.<br /><br />That incident is what opened my eyes to how fearless I could be in refactoring code to be better. If I truly didn't change anything in the API that would affect the client programmer, then the test wouldn't break. When it did, that meant that I needed to rethink what I changed.<br /><br />It really is a good feeling. I highly recommend it!Stevenhttps://www.blogger.com/profile/01576193449065287575noreply@blogger.comtag:blogger.com,1999:blog-12948038.post-21344633476111490832014-01-09T12:43:09.851+00:002014-01-09T12:43:09.851+00:00I am not a TDD developer, and with risk of soundin...I am not a TDD developer, and with risk of sounding uncool and heretic, in my ~10 years career as a java programmer i havent seen TDD code which would really convince me that yes, the time wasted on writing them is won back later.Maybe i have seen only bad TDD but it looked as if the tests checked nearly only cases that really didnt matter, and , that was fact, the bugs appeared what really wasnt tested.While I agree that above can be discussed and i just maybe must learn much more about TDD, I concur with above posts saying to write IDE and debugging will be less important sounds abit silly.There will alwys be bugs, debuging to understand a a mechanism is gold, and plz try to write some code in notepad without all the IDE tools. <br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-53330091073820749812014-01-09T06:06:59.162+00:002014-01-09T06:06:59.162+00:00To say that debuggers are going to be less importa...To say that debuggers are going to be less important is quite a naive view. Debuggers are a crucial tool for those of us who prefer to understand what is inside the black box; a learning tool for understanding code. I routinely use a debugger to step through code and understand the flow of a program; without a debugger good luck with that. Tests will certainly tell you the expected outcome, but certainly not _how_ it arrived there.<br /><br />Secondly, even when utilizing TDD, a debugger provides insight when tests fail and one can step through the offending code to determine the reason for the failure.<br /><br />I've been writing code since I was 8 on my grandfather's Tandy TRS-80. When I was first exposed to a monitor (debugger) it was like coming out of the stone ages – even though it was stepping through 6502 assembly on a C64 :)Stuarthttps://www.blogger.com/profile/05427960730328380463noreply@blogger.comtag:blogger.com,1999:blog-12948038.post-20073281461076250042014-01-08T11:50:50.571+00:002014-01-08T11:50:50.571+00:00Allan - only a Sith deals in absolutes. When you s...Allan - only a Sith deals in absolutes. When you say "will be unemployable" I hear an absolute. Just because something is a good idea does not mean it always happens! Look how many obese people there are. Or divorced marriage-guidance counsellors. <br />And debuggers becoming less important. It depends on your point of view. No matter how good your development is, some faults will remain. Development is not manufacturing. The easiest faults to find are the ones that are found the easiest! As time goes buy, the average time to find and fix a fault increases. So I think with a better development process you might get fewer faults but their importance and "nastiness" will go up. So you could argue the importance of debuggers will go up.Jon Jaggerhttps://www.blogger.com/profile/11560463167349216675noreply@blogger.comtag:blogger.com,1999:blog-12948038.post-39383553108547096942014-01-08T10:43:23.725+00:002014-01-08T10:43:23.725+00:00Fabien, yes IDEs are more than debuggers but I thi...Fabien, yes IDEs are more than debuggers but I think debuggers are the main feature that many developers use them for. Also, the debugger is one of the most complex parts of the IDE. My hope is that with less need for an all-singing-all-dancing debugger in an IDE we would see more innovation. Which would mean the IDE - as you describe - would become even more useful!allan kellyhttps://www.blogger.com/profile/06262139490250478379noreply@blogger.comtag:blogger.com,1999:blog-12948038.post-58082462584858523152014-01-07T16:36:10.078+00:002014-01-07T16:36:10.078+00:00I hope your prediction is right.
However, I don&#...I hope your prediction is right. <br />However, I don't agree with your conclusion : "IDEs will be less important". IDEs should't be reduced to debuggers. IDEs are great tools to navigate in your project, launch your tests and, of course, perform powerful refactorings. TDD enables to do continuous refactorings and this activity is the main one of all TDD programmers. A great IDE is for me a must have.Fabiennoreply@blogger.comtag:blogger.com,1999:blog-12948038.post-84808493585860341262014-01-07T16:08:48.999+00:002014-01-07T16:08:48.999+00:00My guess is that you've been wrong for the cou...My guess is that you've been wrong for the couple of years. <br />Why? I think TDD is a reasonably sound idea, most people realise they need to test stuff, most write the tests and some even write the tests first, I have no argument with the concept. However, one thing I've noticed, things in this industry change faster than that, this years silver bullet is next years old hat. <br />I suspect that we will end up with more automated code writing systems, where the job is to accurately specify what you want probably in some graphical model, press the button and hey presto an automatically generated application doing just what you asked. <br /><br /><br />BTW 'captcha' or whatever it is called is NOT a good thing, the stuff you have to type is not even human guessableDavenoreply@blogger.com