tag:blogger.com,1999:blog-2660291115609609354.comments2023-10-16T17:53:59.857+03:00Software and IAssaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.comBlogger161125tag:blogger.com,1999:blog-2660291115609609354.post-62550955995298014552017-01-20T03:25:33.313+02:002017-01-20T03:25:33.313+02:00Just out of curiosity, did you read to the end? Di...Just out of curiosity, did you read to the end? Did you get that I'm actually in favor of TDD? <br /><br />Or do your think that TDD is in fact undesirable, and that the reasons I mentioned are actually valid?Assaf Stonehttps://www.blogger.com/profile/14023994489658711542noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-81296188128738203272017-01-18T16:59:15.593+02:002017-01-18T16:59:15.593+02:00You dont know what you are talking about man.You dont know what you are talking about man.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-90923737473742378562016-09-18T14:11:42.651+03:002016-09-18T14:11:42.651+03:00Did you even read the post, or just the (admittedl...Did you even read the post, or just the (admittedly click-baitish) title? Please read the whole thing, before you conclude that the article is wrong. You might be (pleasantly) surprised at how wrong you are...Assaf Stonehttps://www.blogger.com/profile/14023994489658711542noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-9589725560514416102016-09-17T09:27:55.835+03:002016-09-17T09:27:55.835+03:00I'm glad time and adoption has proven this art...I'm glad time and adoption has proven this article wrong. WeDoTDD.comAnonymoushttps://www.blogger.com/profile/15042375014937468047noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-48321704395578346052016-03-27T09:50:33.345+03:002016-03-27T09:50:33.345+03:00agile methods don't scale to enterprise level ...agile methods don't scale to enterprise level without some changes! He is so right. <a href="https://www.avaza.com/online-timesheets/" rel="nofollow">time tracker software</a>Richard C. Lamberthttps://www.blogger.com/profile/14766504022599651016noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-34170740265000834862016-03-14T21:42:14.762+02:002016-03-14T21:42:14.762+02:00Hy ... Very awesome posts here. I like this post v...Hy ... Very awesome posts here. I like this post very much. I really appreciate your hard working. Thanks for the sharing with us. Servers Valleyhttp://serversvalley.com/noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-53806581642385658092016-02-15T16:26:54.113+02:002016-02-15T16:26:54.113+02:00Great Post. Great Post. farnandashttps://www.blogger.com/profile/02349201946670312332noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-37495924972710175272015-12-28T21:57:59.704+02:002015-12-28T21:57:59.704+02:00Hi John,
I do believe that the need for estimates...Hi John,<br /><br />I do believe that the need for estimates comes from a valid concern. My problem with estimates is that they are the wrong answer for the question. Estimates, like any other attempt at divining the future, is based on a deep-rooted fear of the unknown, and numbers - any numbers, give a sense of security. However, it is a FALSE sense of security, because we simply don't know.<br /><br />The better approach, is rather than lie to ourselves (and our managers, and clients, and stock holders) about how volatile our guesses are, and hope for a positive outcome of an all-or-nothing bet, we should shift our efforts to making the best with what we have: deliver the most important functionality, as early as possible, and have the best possible product when the deadline comes. More often than not, it will be good enough.<br /><br />In any case, this post was more of a rant-turned-come-back for smug know-it-all middle (pointy-haired) management, using ridicule to shoot win an argument.<br /><br />Cheers!Assaf Stonehttps://www.blogger.com/profile/14023994489658711542noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-80092597273871454182015-12-28T21:22:41.858+02:002015-12-28T21:22:41.858+02:00I think it is a question of addressing the purpose...I think it is a question of addressing the purpose those see for estimates. If they just quote lots of people do it, so we should then your answer is fine in my opinion.<br /><br />If they say they need some way of deciding if doing that work is wise or something that is going to be so difficult that it isn't worth it then a different answer is needed. If they talk about scheduling then other explanations make sense to me - talking about the issues with fixed estimates etc. but giving them alternatives of fixed schedule with variable features (if there is a business need to deliver on some date)., etc.Curious Cathttps://www.blogger.com/profile/05269438998983808916noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-83290571447636848972015-12-18T21:12:26.250+02:002015-12-18T21:12:26.250+02:00This comment has been removed by a blog administrator.Anonymoushttps://www.blogger.com/profile/13449436643127931850noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-92223690159485270502015-12-15T14:52:26.972+02:002015-12-15T14:52:26.972+02:00Really nice post.Really nice post.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-36401373466009532842015-12-08T05:35:27.746+02:002015-12-08T05:35:27.746+02:00you must invest in some manual work in making conf...you must invest in some manual work in making configuration standards and then regular and automated comparisonAnonymoushttps://www.blogger.com/profile/13449436643127931850noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-38010066532958353992015-12-07T01:47:46.459+02:002015-12-07T01:47:46.459+02:00Dell Support would be a great startDell Support would be a great startAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-53371974800117919312015-11-27T22:29:43.684+02:002015-11-27T22:29:43.684+02:00Very gòod story, reminds me of my first jump into ...Very gòod story, reminds me of my first jump into kanban world. Everything was new, strange. After all i had 10 years of Watefall (ouch). But then it clicke - it worked. Job was small , really manageable tasks. And the morning standups were good faadback sessions for both sides. Ah the memories :) Unknownhttps://www.blogger.com/profile/09063110065536195339noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-34559014017295703082015-11-08T18:49:57.526+02:002015-11-08T18:49:57.526+02:00In my experience? It isn't that easy to do so....In my experience? It isn't that easy to do so. They might not want to hear criticism. <br /><br />What you may want to do, is to suggest things that may improve your agility, or even better, do them. Assaf Stonehttps://www.blogger.com/profile/14023994489658711542noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-11672535467706561142015-11-04T02:41:09.848+02:002015-11-04T02:41:09.848+02:00does not work with windows 8 with all steps follow...does not work with windows 8 with all steps followed.<br />Hope it is okay for windows 7.Anonymoushttps://www.blogger.com/profile/03528774073408828793noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-22968655907808371792015-11-02T18:49:49.936+02:002015-11-02T18:49:49.936+02:00Great article, but how does one break it to Manage...Great article, but how does one break it to Management that the department is not really Agile, LOL!?Anonymoushttps://www.blogger.com/profile/08638905365186970552noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-53461932937471012682015-08-17T10:00:39.544+03:002015-08-17T10:00:39.544+03:00NiceNiceAnonymoushttps://www.blogger.com/profile/06345066637323499316noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-66931410528304882492015-06-27T17:38:16.674+03:002015-06-27T17:38:16.674+03:00This is good. For me, installing DELL_CONTROLVAULT...This is good. For me, installing DELL_CONTROLVAULT-WINDOWS-BI_A00_R308326 and it works. Thanks!DLhttps://www.blogger.com/profile/08742931844991738372noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-82854388359633702752015-05-14T15:24:46.584+03:002015-05-14T15:24:46.584+03:00I think the high level estimates must be made befo...I think the high level estimates must be made before the sprint planning meeting itself. This gives product owner the ability prioritize and take decisions better and at the same time reduce time taken during sprint planning meetings on what needs to go into the sprint backlog from the product backlog ....Nice blog on <a href="http://www.scrumaxis.com/agile-estimating-and-planning.html" rel="nofollow">Agile estimation & planning</a> ..keep writing.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-79932260684932444532015-04-23T16:19:18.140+03:002015-04-23T16:19:18.140+03:00Hi Dmitry,
Thank you for your comment.I do, of co...Hi Dmitry,<br /><br />Thank you for your comment.I do, of course, completely disagree with you on almost every point you made.<br /><br />First, while there *MAY* be more test code than production code, this is, in and of itself, not a bad thing! One of the benefits of TDD is that it can help shape your code into a simpler design - which may mean less code. If TDD helped you reduce the amount of production code you wrote and have to maintain, then its own size is not a problem.<br /><br />Second, you state that nobody is testing the test code. While that may be correct in essence, in fact, it is (or rather, should be) of little consequence. BECAUSE there is no coverage for the test code, the test code must be written in a way that is so simple and intuitively understandable that automated testing is not needed here. Reread the third point I made (point #8), which is in my opinion the only valid reason not to test, which is that if the project (the test code) is so simple and straightforward, then it is a waste of time to test.<br /><br />Your third point is that trying to follow the principles of TDD you break them. That is simply not true. The principles are that you (1) write test code that proves that you need to change your production code base, then (2) write production code until the test passes, and then (3) refactor the code to improve design and remove redundancies. Rinse and repeat. Nowhere does it say that you need to write test code for every line of code you write, test code included.<br /><br />Your next point, that if you have 100% test coverage, then you have written your program twice is wrong on multiple levels: First, you've made a Straw-Man argument - 100% test coverage is neither a viable goal, nor a desirable one. Second, your test code is not a repetition of your production code. Your tests should NEVER repeat production code, but rather VERIFY the results. The simplest example would be that to test a complex algorithm, you need only run it with a known set of arguments and compare the result to a known correct answer. You EXERCISE the production code, you don't repeat it.<br /><br />Next, you state that the process of writing code that ONLY SATISFIES (emphasis mine) the tests can and should be automated. Whether or not this is true, I cannot say for sure, but I can say that this is another Straw-Man argument. You shouldn't write code that ONLY SATISFIES the tests. Or if you insist, you should write tests that make it so that ONLY SATISFYING them is the right production code (see this article on property based testing http://fsharpforfunandprofit.com/posts/property-based-testing/). Of course your statement on not needing the production code derives from the previous straw-man, and is therefore false.<br /><br />Your last point, that the test code is declarative, is actually the only point I agree with. I completely disagree with your sentiment, because this is a good thing. If it were an implementation spec, then the test would repeat your production code, and/or break every time you change your production code, and THAT would be a bad thing.<br /><br />So, yes, do not give in to provocations. Try TDD because it is worth the effort.<br /><br />Unless this whole comment was tongue in cheek, and you were simply giving me a treat in my own medicine...<br /><br />In that case, well played, sir. Well played.<br /><br />Best regards, and happy coding,<br />AssafAssaf Stonehttps://www.blogger.com/profile/14023994489658711542noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-84707189439383044692015-04-23T12:57:54.656+03:002015-04-23T12:57:54.656+03:00Test Driven Development - is a fraud! The program ...Test Driven Development - is a fraud! The program is written using TDD contains more test code than production code. But unless someone is testing the test code? Of course not! Thus, under the guise of testing a project goes further untested code! Trying to follow the principles of TDD, you automatically break them! Moreover, if you have 100% test coverage, you have written your program twice! The process of writing code that only satisfies the tests can and should be automated. And then you do not need a production code, you only need a test code. But what is this test code? This is a declarative description of what should or should not do the program in every possible situation, without describing how it should do it!<br /><br />Do not give in to provocations, TDD - is simply too complicated and perverse declarative programming!Anonymoushttps://www.blogger.com/profile/10864728738200857200noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-42226082734883219652015-04-23T12:57:30.008+03:002015-04-23T12:57:30.008+03:00Test Driven Development - is a fraud! The program ...Test Driven Development - is a fraud! The program is written using TDD contains more test code than production code. But unless someone is testing the test code? Of course not! Thus, under the guise of testing a project goes further untested code! Trying to follow the principles of TDD, you automatically break them! Moreover, if you have 100% test coverage, you have written your program twice! The process of writing code that only satisfies the tests can and should be automated. And then you do not need a production code, you only need a test code. But what is this test code? This is a declarative description of what should or should not do the program in every possible situation, without describing how it should do it!<br /><br />Do not give in to provocations, TDD - is simply too complicated and perverse declarative programming!Anonymoushttps://www.blogger.com/profile/10864728738200857200noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-54976571809307992992015-04-16T18:56:41.971+03:002015-04-16T18:56:41.971+03:00The post is written in very a good manner and it c...The post is written in very a good manner and it contains many useful information for me.<br />Business Messengerhttps://www.vipole.com/en/noreply@blogger.comtag:blogger.com,1999:blog-2660291115609609354.post-87479909950525321472015-03-30T09:30:38.920+03:002015-03-30T09:30:38.920+03:00Hello Mr Stone,
Nice blog! I am editor at .NET Co...Hello Mr Stone,<br /><br />Nice blog! I am editor at .NET Code Geeks (www.dotnetcodegeeks.com). We have the NCG program (see http://www.dotnetcodegeeks.com/join-us/ncg/), that I think you’d be perfect for.<br /><br />If you’re interested, send me an email to eleftheria[dot]kiourtzoglou[at]dotnetcodegeeks[dot]com and we can discuss further.<br /><br />Best regards,<br />Eleftheria Kiourtzoglou<br />Eleftheria Kiourtzoglouhttp://www.dotnetcodegeeks.comnoreply@blogger.com