tag:blogger.com,1999:blog-26602911156096093542024-02-21T08:13:22.469+02:00Software and IMusings about software, methodology, and meAssaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.comBlogger31125tag:blogger.com,1999:blog-2660291115609609354.post-60756904929843772542015-12-28T17:01:00.001+02:002015-12-28T17:01:10.458+02:00Do We Really Need Estimates?<p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEipOb3IDVmO982r0664aCWmyZz2M9Rd7DNrwHYgGqvMAe4UMT6Dln6urkrIteiuxdtB2hAj0-4TbKLIYSxDPhZEYIY2Gki0-g5hajceZiKquj6xkU7VDQV77iRt0sTcQtN6r22ERBZQXsSw/s1600-h/agile-icon7.png"><img title="agile-icon" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: right; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" alt="agile-icon" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifVezZGiPsl4JHZf4rvtqlcbGX5EvWvZGQ_ovgD14NZlhzWJ0oHGhopNxm1JOW-imOi0oGeVjdkDndf3wjZqr2mrm7zYQEqjEA71uyGuUAuZXC2IRpjvD_5YBz_ircDVkE2LL3fFGKwLpb/?imgmax=800" width="114" align="right" height="119"></a>Okay, so you’ve read anything I wrote before, you probably know by now, that I am a strong proponent of Agile methodologies. I’ve said it before, and I’ll say it again:</p> <h3>Estimates Are Wasteful</h3> <p align="justify"><a href="https://lh3.googleusercontent.com/-whcqwmCNz50/VoFOrcxVI9I/AAAAAAAB9Js/vFkhANPLy3U/s1600-h/waste-clipart-trashcanc5.png"><img title="waste-clipart-trashcanc" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: left; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" alt="waste-clipart-trashcanc" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhOfsGVtfQdQE-eiX0OI_4AuGSXXbhH4gh29l3HhU4sWTr1PxWgFabEvwgxZtDw2HA21ZwYzj2LDvOoQ4s1-emTWoFDdFzeYKBkmbH216kjLHvc2cF7kEfo6-OE1tW1TLw0Nx1JwJgHOpmQ/?imgmax=800" width="133" align="left" height="161"></a>It doesn’t matter if it was a friendly debate with a manager, discussion with a client, heckling from someone in the audience of a presentation, but pretty much every time that I bring up this point, I get asked some variation of the following question:</p> <p align="justify"><em><strong>Thousands of companies and organizations have been managing by estimates for decades. Do you think that you are smarter than the owners and managers of everyone of them?!?</strong></em></p> <p align="justify">I must admit, that question ruffles my feathers every time I hear it. Mostly because, that’s a direct attack on me, not my ideas, and a part of me wants to lash out back at them, or just glibly reply in the affirmative. I don’t. Discretion is the better part of valor, after all…</p> <p align="justify">Today I just thought of a real good answer. Perhaps still a bit on the glib side, but at least not disrespectful or boastful.</p> <h3>Am I Smarter Than Pro-Estimate Managers?</h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhTlPDqKCmDia83fhqbvFa_7a2iyf7rtvYp6qnl4cSmzC2VhU2uoU1CmSUkEKCgnjDiKWir17kQqZPASCl89UeP3qRGlI3OTCDhPF85_vSGya4JZk1AdKmkER071YCQHHYar8FTtBvQqhXW/s1600-h/brainy4.png"><img title="brainy" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: right; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" alt="brainy" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrwPwQIFdllUrtJF1cmonZOgjOYGVoLhCKPmo3bjuMXl-U65X5iR0gRfMzr2KmZT2cAdMPOEGIjSfv79X0wglNBwd3h2G9VXH0WD_cOVsEVgW_QZaF76_NhRz0FHgrFlfT5DNcqhhya1BN/?imgmax=800" width="78" align="right" height="110"></a>This is going to be my new go-to answer. Feel free to use it. Feel free to quote me:</p> <blockquote> <p align="justify"><strong><em>I think that I have more knowledge, better tooling, and have learned from more failures, than whoever originally came up with the idea to estimate. And I have no basis to compare myself with those who simply estimate because that is what everybody else is/was doing.</em></strong></p></blockquote> <h3>What Do You Think?</h3> <p><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCeeB_ezWHMD-WRt0AzrUrwgnouh7UDVg2g-lSoicc_SO4ech8xdwcXj4JT9aCqcHiR7rGlVLJho0t24oqjT0uK455nXx-uGGZFvdwoRK8Uk5mM1LR-Ph30Z-KZ7Ub6TdTtRSoJwPb24a7/s1600-h/Trollface4.png"><img title="Trollface" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: left; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" alt="Trollface" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQDX9Eg8LqqjNJvBSGXyN-_C-mCvFlerK-gytahAyovZrVhVogHwKHs3EC-9UEClTPxO55iWyg7hPYvJ-why1pAd4c1rgMBnL3UhEkVjtonmGthZIvs448eFBvGOAacjxXw5Qy-Pf5ggXr/?imgmax=800" width="66" align="left" height="62"></a>Still too glib? Too arrogant? Just right?</p> <p>Let me know in the comments.</p>Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com2tag:blogger.com,1999:blog-2660291115609609354.post-67876406688111864932015-04-15T18:43:00.001+03:002015-04-15T18:43:37.350+03:00How to REPL in C# with CShell<h3></h3> <h3><a href="http://lh4.ggpht.com/-twfC5c0h9xY/VS6HGp3HnlI/AAAAAAAB8gU/OXtsGA6-nII/s1600-h/Sea-shell%25255B8%25255D.png"><img title="Sea-shell" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; float: right; padding-top: 0px; padding-left: 0px; margin: 0px 0px 10px 10px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="Sea-shell" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9tVE-l_sciiyZvZho-f2PykS7M5_FDJSJe2anL1mZyeRr3TEA2A3G-zxszkjQbZizyOZDsJIfxRLpkuIz6_WfaF14ReT3IxVnrm2SEftxzawtc_WLmfKaza7WMRY4buBnAwa7AXtYpb0a/?imgmax=800" width="218" align="right" height="170"></a></h3> <p align="justify">Perhaps the first question should really be ‘<em>what is REPL’?</em> In truth, much like software testing, many developers use it, without knowing that there’s a name for it – or a better way to do it. In this post I will explain what REPL is, how to use it in your development process, and finally, how CShell makes REPLing so much easier.</p> <h3>What is REPL?</h3> <p align="justify"><img style="float: left; margin: 0px 10px 0px 0px; display: inline" alt="http://ubik.cc/MAOW-Firenze-09/images/repl-loop.png" src="http://ubik.cc/MAOW-Firenze-09/images/repl-loop.png" width="212" align="left" height="134"><a href="http://en.wikipedia.org/wiki/Read%E2%80%93eval%E2%80%93print_loop">REPL</a> is an acronym, which stands for <strong>Read – Evaluate – Print – Loop</strong> (see? not so complicated). Essentially, this is a cyclic process, where the computer <strong>reads</strong> and parses input from the user and feeds it into some algorithm or function, <strong>evaluates</strong> the algorithm, <strong>prints</strong> out the function’s output, and then returns (<strong>loops</strong>) back to the <em>read</em> state for more input. This cycle repeats until terminated.</p> <p align="justify">In some ways, you may consider this to be the interactive version of <a href="http://en.wikipedia.org/wiki/Test-driven_development">TDD</a>, where you make up the test as you go, running a function either in order to test that it works as expected, or in order to learn how it works, using different inputs to increase your confidence in the code.</p> <p align="justify">In fact, anytime you write a short block of code, often a console application or a unit test, in order to design or test a function – you are – to some extent – REPLing.</p> <p align="justify">To some extent, because just like with test automation, you really want proper tooling, if you want to do this properly, and do this with ease. </p> <p align="justify">You need a REPL environment.</p> <h3>What is a REPL Environment?</h3> <p align="justify"><img style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; float: right; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="https://www.smc.edu/ACG/Marketing/Events/Documents/policy%20of%20environment.jpg" src="https://www.smc.edu/ACG/Marketing/Events/Documents/policy%20of%20environment.jpg" width="164" align="right" height="149">A proper REPL environment is first and foremost, an <strong>interactive </strong>environment. This means that you should be able to simply drop into the environment, type in some code, and have an immediate indication as to whether the code does what you want it to do.</p> <p align="justify">A naïve and cumbersome way to do it, is of course, open Visual Studio, start a new console application, type some code into the Main() function, and run the application. The problem with this approach, is that (a) it takes a lot of time to reach the part where you can type in some code – too much ceremony, and (b) you have to compile the whole application, and start running from scratch every time you want to run. A true REPL environment should let you evaluate each line separately.</p> <p align="justify">Note that Visual Studio has an Interactive Window. Unfortunately, it is for debugging, and can be used only while running code in debug mode, not while designing it.</p> <p align="justify">Until recently, I’ve been using <a href="https://www.linqpad.net/">LinqPad</a>. LinqPad is a really great tool, that allows you to run short scripts in C# (and VB.NET and F#). The commercial version (just under $50) adds intellisense, and supports using NuGet packages for references that your .NET script may need. You can also use it to write short programs as well, and create extensions that you can use with all of your scripts. You can fire up the environment very quickly, and just start coding an expression to REPL, or write a script.</p> <p align="justify">I have, however, a few weeks ago, discovered CShell, and have started using it immediately, and have not looked back since.</p> <h3 align="justify">Enter CShell</h3> <p align="justify"><a href="http://cshell.net/"><img title="CShell Icon" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; float: left; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="CShell Icon" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhPRzH9WJiDmqVaWmRBIQ7GOdIcCz6TbS1sVLVafevWUMP5v8Kb0nQNrPTJUYvmJtno32wyqG5ZrF3lkO4rxb7mcEnIoNUBC_wuTYD6f7bHG3orIMrglnU6Hp9ncAY9atSqtudjswfrVEno/?imgmax=800" width="128" align="left" height="128">CShell</a> – no relation to the similarly named shell that is (not so) commonly used in UNIX and Linux environment, is a free (as in beer), true REPL environment. It is based on the new <a href="http://en.wikipedia.org/wiki/.NET_Compiler_Platform">Roslyn</a> compiler, and has all of the key components that you need:</p> <ul> <li> <div align="justify">True REPL interactive window – in the IW, you can simply type C# code, hit enter and it evaluates, line-by-line. In the IW, each evaluation is remembered, so you can enter multiple lines, each one based on the results of the previous evaluation.</div></li> <li> <div align="justify">A scratchpad window for entering C# and script-CS (.csx) scripts. You can run an entire script, or just selected lines. In this mode, of course, each evaluation runs separately.</div></li> <li> <div align="justify">CShell can print to a “sink”, in various formats – text, HTML, XML, graphs, etc.</div></li> <li> <div align="justify">Intellisense. It simply just works.</div></li> <li> <div align="justify">string based evaluation. You can type in something like <font face="Consolas"><strong>Shell.Evaluate("1+1");</strong></font><font face="Arial"> and it prints the evaluated result.</font></div></li> <li> <div align="justify">Add references from the file system or the GAC.</div></li></ul> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj9oiw36ejbcUcl1a6XiAnJS5QaszY2odZPU-gJ7azkGI8kYsCXlqhmA39h0nhzJG_ceANoqpZVv9I-fBbcKiBLQp7kePw-MlOLfXeu2Kxop3EfHIBz0g2JDNyHOD80mwC1gIGxPLXLcHVx/s1600-h/image%25255B21%25255D.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; float: none; padding-top: 0px; padding-left: 0px; margin: 20px auto; border-left: 0px; display: block; padding-right: 0px" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZRNVR8vAjwL8H7CEXq2HbkqhVxSCiOXVz3ybnUISuuH-e9W-r8TYwcTpipYu_t0ygsiPQlGfV0X6_y946ULQhvg3k3M4A9N75NwskW7EUt_sEI7xT_-DiBRSeiLjd_xvrKPw9vwbfVUOI/?imgmax=800" width="536" height="471"></a>One nice thing that <strong><em>really</em></strong> helps you get started with CShell is the tutorial. When you open the IDE for the first time, the workspace opens up with the Tutorial.csx script file. It walks you through examples of what CShell can do, and how you can/should use it. One run through it, and I felt as comfortable with it as I do with LinqPad, which I’ve been using for years:</p> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2FBo9MxxJl2efehwaILYlVrGqw_ZZRCUpL_8NP6Nga-4yCIX_MO6CcGH4Yhn_wHotRKpwF7Lws07nNGnK1LN4CabBUdGorrvcc3e9tjLe8km-dXm0lcIDltVBvexmiKr_o16KhTU6vmGV/s1600-h/image%25255B16%25255D.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; float: none; padding-top: 0px; padding-left: 0px; margin: 20px auto; border-left: 0px; display: block; padding-right: 0px" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhg9U_lvmYkrYJX2dSk-kLA4uPtGrn4nBmdKG99OqGYNUnw9D6vWxaMROmtMgl1v0BF7nybZx8XfYePCYSWGkt5KC_Tm11TzIQdm-Qgd9YpDeLKqSCu8gFsRExR6PO7KKIO9pBxILhVFAFk/?imgmax=800" width="540" height="475"></a></p> <p align="justify">If you accidentally (or purposefully – I won’t judge you) closed the tutorial and want to reopen it, you can find it where you installed it (unzipped the binaries, really – it’s an XCopy deployment), under <strong>CShell\Templates\Tutorial.csx</strong>.</p> <p align="justify">And did I mention that it’s free?</p> <div id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:d8ba92c2-239d-440a-9cca-da04fb551521" class="wlWriterEditableSmartContent" style="float: none; padding-bottom: 0px; padding-top: 0px; padding-left: 0px; margin: 0px; display: inline; padding-right: 0px">Technorati Tags: <a href="http://technorati.com/tags/C%23" rel="tag">C#</a>,<a href="http://technorati.com/tags/ScriptCS" rel="tag">ScriptCS</a>,<a href="http://technorati.com/tags/CShell" rel="tag">CShell</a>,<a href="http://technorati.com/tags/REPL" rel="tag">REPL</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com0tag:blogger.com,1999:blog-2660291115609609354.post-36867296898833416072015-01-27T19:26:00.001+02:002015-01-29T20:54:32.198+02:005 Reasons to Manage Your Solo Project’s ALM Process<p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjrDUqO8huvV5s9A8usZU2OJZMd36zIE01LYkkmk9coa1tlI6GKlDZvNmFISxlpUA6pxpsflSGvX4UnFxEASey66lLJUGRcIPeSAE7DB8pFXl2iOr6tRUD3mbVuwiHJ5zZNY8mOD6lw3K8D/s1600-h/ALM%252520solo%25255B4%25255D.png"><img title="ALM solo" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: right; padding-top: 0px; padding-left: 0px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" alt="ALM solo" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEisszdJTJQcMqvWCb06sDdT88hoiOABOt5weWgAU7Tm5XAGDO-Y5hQV3f9Cn17NmQG1j8T3BOildNx7Ffk7oML-e-N7_sbPoftve8Cmyqvuvq-LlFlrROd6f0y7rWPSRDPylomJHtmbbNvI/?imgmax=800" width="190" align="right" height="191"></a>So I’ve been developing software on the Microsoft stack for just over 10 years, and training and consulting on managing software development with VS-ALM (a.k.a. TFS, a.k.a. Team System) for just over 4 of those years. But in all time training and consulting, I was working with teams – from small 5 person start ups, to enterprises with hundreds of users, all using Team Foundation Server (a.k.a. on-premises TFS) to develop their methodology and align their tooling with their products.</p> <p align="justify">Never individuals, though.</p> <p align="justify">Over the years, though, I’ve had the opportunity to fly solo on several software projects, some short lived, some longer, as have other ALM consultants that I know. One thing we all seem to have in common is that, while as ALM experts, we have all of the skills and knowhow to apply our own trade to the software we develop, we seldom – if ever – do so.</p> <h3>The Cobbler’s Children Go Barefoot…</h3> <p align="justify"><img style="float: left; margin: 0px 10px 0px 0px; display: inline" src="https://mysocialmediastrategy.files.wordpress.com/2012/08/cobbler-and-child.jpeg" width="115" align="left" height="123">… as the saying goes. It seems that this proverb applies to our profession as much as it does to others. You’ve seen the doctor who smokes, the out-of-shape coach, the technician or plumber whose own wiring or plumbing is faulty, respectively. Perhaps it’s the same. Perhaps its just that proper ALM is more visibly useful when multiple hands are involved and they must all communicate and interact properly with each other, than when one person holds all roles.</p> <p align="justify">Solo projects <strong>seem</strong> to need no management, I believe they only seem to. </p> <p align="justify">Here’s why:</p> <h3 align="justify">1. If You Don’t Use Source Code Version Control, You’re an Idiot!</h3> <p align="justify"><a href="http://lh3.ggpht.com/-nZfmQ9p7G-A/VMfrDgiJEKI/AAAAAAAB8Xg/hwVJyZYDvUQ/s1600-h/The_Stupid__It_Burns_by_Plognark%25255B8%25255D.png"><img title="The_Stupid__It_Burns_by_Plognark" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: right; padding-top: 0px; padding-left: 0px; margin: 0px 0px 0px 10px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" alt="The_Stupid__It_Burns_by_Plognark" src="http://lh5.ggpht.com/-UzwyV26oDZs/VMfrEIlBc5I/AAAAAAAB8Xk/zSKScWd_6Vw/The_Stupid__It_Burns_by_Plognark_thumb%25255B4%25255D.png?imgmax=800" width="186" align="right" height="190"></a>I apologize for the vehemence. Let me rephrase this. If you don’t use some kind of source code version control, you’re an <strong><em>inexcusably dense idiot who deserves what he or she gets when you lose your source code!!!</em></strong></p> <p align="justify">I guess I couldn’t rephrase it without the vehemence. Lesson learned.</p> <p align="justify">Beyond the fact that having some kind of <strong>backup</strong>, preferably <strong>online</strong>, means that even if you lose your laptop, or accidentally delete your source files, you still have a copy of your code, version control means that if you make a mistake, you can still rollback to that point in time and fix whatever you did wrong. Having a historical log of the changes you made to the software can also serve as release notes of sort, and a rudimentary list of the features and bug fixes you have, and even help establish some kind of time line.</p> <p align="justify">Really though, version control is about security for the code – protection against loss and against mistakes. you should use it as frequently as possible.</p> <p align="justify">Note that you do not need to shell out huge amounts of money to be able to use version control. In fact, as in <strong>life</strong>, so with <strong>version management</strong>, the best things are <strong>free</strong>! </p> <p align="justify">I prefer using <a href="http://git-scm.com/" target="_blank">Git</a>. You can use it locally with any operating system (Windows, Linux, Mac OS), and there are multiple online tools that work and synchronize with Git, all free: <a href="https://github.com/" target="_blank">GitHub</a>, <a href="https://www.codeplex.com/" target="_blank">CodePlex</a>, and (my personal favorite) <a href="http://www.visualstudio.com" target="_blank">Visual Studio Online</a>. There are, of course, other version control systems, both <a href="http://git-scm.com/book/en/v2/Getting-Started-About-Version-Control" target="_blank">distributed</a> and centralized (<a href="http://mercurial.selenic.com/" target="_blank">Mercurial</a> is another DVCS, <a href="https://subversion.apache.org/" target="_blank">Subversion</a> is a great free centralized one).</p> <p align="justify">Heck, even use <a href="http://dropbox.com" target="_blank">DropBox</a> or some other online-syncing file-storage, just beware that it won’t protect you from deleting your code, nor will it let you rollback – but at least you’</p> <h3>2. Defining (just enough) Work Upfront = Less Code Writing and Rewriting</h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJafVK9gu3P9T7LZTE7gPAWCNHdkBtFigoTqHcu0vCstFu2ahytCtcl2JnPRuOrBAbtIFmBzhfV02MIwlfFy46TZtQQ88MaJzwHA6ywTR3x2F3zZHVcoTMu47cCjqjJYoLHOeXbeKNue0Y/s1600-h/backlog%25255B4%25255D.png"><img title="backlog" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: left; padding-top: 0px; padding-left: 0px; margin: 0px 10px 0px 0px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" alt="backlog" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhXVl3yE5MZXFSz5kOkNeNkJabtoDYT-9DVhbIlYFKA-YbY8cSKxuMeWRTZ195KCAuJjJJb0aSrKUq3vJU2l0fcnB9JXY6bhSPDtpd2F3XnBddEqEOLI0ij2WFrWrRH3HihODMGsk3gCh8X/?imgmax=800" width="174" align="left" height="186"></a>Much like TDD tends to limit the amount of production-code you write, so does defining your work. In fact what is TDD, if not the definition of a small amount of work that needs to be done to the system, along with a definition of how to know when you’re done? The same holds true for defining a development task, a user story (a.k.a. a product backlog item, or PBI) or a feature; each is an elaboration of the higher level: Feature to user story, to task, to test. When you know what needs to be done, and you know when you’re done, you know exactly what the remaining work <strong>is</strong>. That saves time.</p> <p align="justify">And let’s be clear. <strong>Just enough</strong> is key here. Too little, and you’ll rewrite anything that you haven’t properly thought out and planned. Too much, of course, and changes to the reality surrounding the project and your perception of reality will bring rewrite to your plans.</p> <h3>3. Project Planning Makes it Possible to Plan Releases</h3> <p><img style="float: right; margin: 0px 0px 0px 10px; display: inline" src="http://www.primaryresources.co.uk/english/images/AreWe.GIF" width="181" align="right" height="179">Unless you are truly working on a hobby for yourself, you still need to be able to answer at least these two questions: </p> <ol> <li>When will it be done? <li>What will be done by a certain date?</li></ol> <p align="justify">Without estimating the work you have to do, more so if you don’t even know how much work you have, you simply will not be able to give more than a <a href="http://www.urbandictionary.com/define.php?term=POOMA" target="_blank">POOMA</a> estimate.</p> <p align="justify">Note that unless you live alone, you might still need to answer these questions, if only so your partner, roommate or parent will know when you will finally clear the garage (or dinner table) from your junk.</p> <h3 align="justify">4. Automation Reduces Human Error as well as Manual Labor</h3> <p align="justify"><a href="http://lh3.ggpht.com/-nbfaQiAvc_w/VMfrF9pcrbI/AAAAAAAB8YA/z4V9jOHZXqA/s1600-h/vitruvian-hi%25255B4%25255D.png"><img title="vitruvian-hi" style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: left; padding-top: 0px; padding-left: 0px; margin: 0px 10px 0px 0px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" alt="vitruvian-hi" src="http://lh6.ggpht.com/-k4CUIuBJA3c/VMfrGQqtFiI/AAAAAAAB8YE/mbXpPZQ8v_Y/vitruvian-hi_thumb%25255B2%25255D.png?imgmax=800" width="159" align="left" height="159"></a>Even if you are a solo programmer, two things remain invariably true for you:</p> <ol> <ol> <ol> <ol> <ol> <li> <div align="justify">You’re <strong>only</strong> human.</div> <li> <div align="justify">You’re only <strong>one </strong>human.</div></li></ol></ol></ol></ol></ol> <p align="justify">Being only human means that as talented as you may be, you are still prone to repetition based errors. You’ll forget to update the version number, or forget to set the build configuration to <em>Release</em>, or forget to run the tests, or any number of things. When I train new developers, especially in those early days when they feel that the fact that they’re constantly making errors, and more experienced developers must be demigods or some such, in an attempt to reassure them (and lighten the atmosphere), I tell them this:</p> <ul> <li> <div align="justify">There are only <strong>two</strong> kinds of developers: experienced, and <strong>inexperienced</strong> developers.</div> <li> <div align="justify"><strong>Inexperienced</strong> developers make only <strong>two</strong> kinds of mistakes: Mistakes born of inexperience, and mistakes born of stupidity.</div> <li> <div align="justify"><strong>Experienced</strong> developers make mistakes <strong>only</strong> born of <strong>stupidity</strong></div></li></ul> <p align="justify">Aside from the fact that this is inherently true (an experienced person, by definition, cannot make a mistake born of inexperience), it is important to note – experienced developers make mistakes!</p> <p align="justify">Computers do not. Ever. </p> <p align="justify"><img style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: right; padding-top: 0px; padding-left: 0px; margin: 0px 0px 0px 10px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" src="http://careertipster.com/wp-content/uploads/2011/07/Man-vs.-Computer-300x276.jpg" width="184" align="right" height="169">Another saying that I’m fond of repeating, the former statement being a key reason to do so, especially when consulting and or training clients on the use of ALM tools, is to <strong>never</strong> let a <strong>human </strong>do a machine’s <strong>work</strong> (and vice versa). Anything a machine can do, we shouldn’t.</p> <p align="justify">Finally, there’s the fact that any time spent on doing what someone, or more importantly, <strong>something</strong> (i.e. your computer) could do, is time not spent on things only you can do (i.e. developing the product – which you’d probably prefer to do anyway). Ask yourself this – while you’re manually doing repetitive work – who is coding? Nobody.</p> <p align="justify">This holds true for building, for testing, for releasing and deploying, and basically for anything that you can (and know how to) automate.</p> <p align="justify">In all but the simplest and most straightforward scenarios (usually short-term, one-shot projects), you should find ways to delegate work to a machine.</p> <h3 align="justify">5. Defining the Work Makes Change Management Easier</h3> <p align="justify"><img style="border-left-width: 0px; border-right-width: 0px; background-image: none; border-bottom-width: 0px; float: left; padding-top: 0px; padding-left: 0px; margin: 0px 10px 0px 0px; display: inline; padding-right: 0px; border-top-width: 0px" border="0" src="http://www.csweek.org/web/images/College/change-management.jpg" width="184" align="left" height="175">It’s all great when you’re hacking away at that pet-project of yours and you’re in the zone, but a week later, a month or even three later, once you start delivering a second or third release of your software, keeping track of what was done, when – not to mention writing release notes, becomes extremely difficult, if you don’t know what your changes are or were. In fact, if you use an ALM tool for tracking features, changes and defects, and associate them with automated builds, you can generate a release notes document automatically with every build, and not have to deal with it yourself.</p> <p align="justify">The other kind of change, is change <strong>of </strong>management. Today this may be your solo project. Tomorrow, who knows? You may take on a partner, give someone else the code to maintain, or decide to open the source. If the only definition of the work is whatever lies inside that wonderful brain of yours, hand-off will be a bear. Trust me. I’ve had to waste two weeks once receiving a project, and I <strong><em>still</em></strong> don’t know everything about it. Finding out stuff on my own is not the best use of my time. Having a nice set of features, tasks and bugs (past and open both) shortens the time, and makes discovery pains all but gone.</p> <h3 align="justify">Conclusion</h3> <p align="justify"><img style="float: right; display: inline" src="http://blog.lewispr.com/content/uploads/2011/07/milleniumfalcon2.jpg" width="172" align="right" height="172">In summary, I’d like to state my opinion that in most (again, all but the simplest and most straightforward one-shot) software projects, proper ALM is as useful and important when flying solo as when developing with a team. Lack of communication issues (though see point #5) are balanced by the increase of work of having to do it all by yourself.</p> <p align="justify">Just do it right the first time. You’ll thank me for it.</p> <p align="justify">Best Regards,<br>Assaf Stone<br>Occasional Solo Developer</p> <div id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:1686bbd5-b3e7-423a-946d-1734c800bdc1" class="wlWriterEditableSmartContent" style="float: none; padding-bottom: 0px; padding-top: 0px; padding-left: 0px; margin: 0px; display: inline; padding-right: 0px">Technorati Tags: <a href="http://technorati.com/tags/ALM" rel="tag">ALM</a>,<a href="http://technorati.com/tags/Software" rel="tag">Software</a>,<a href="http://technorati.com/tags/Development" rel="tag">Development</a>,<a href="http://technorati.com/tags/Testing" rel="tag">Testing</a>,<a href="http://technorati.com/tags/Building" rel="tag">Building</a>,<a href="http://technorati.com/tags/Code" rel="tag">Code</a>,<a href="http://technorati.com/tags/VCS" rel="tag">VCS</a>,<a href="http://technorati.com/tags/Git" rel="tag">Git</a>,<a href="http://technorati.com/tags/Solo" rel="tag">Solo</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com4tag:blogger.com,1999:blog-2660291115609609354.post-36901059383459931862015-01-23T19:21:00.001+02:002015-12-28T17:15:43.649+02:005 Ways Project HoloLens May Change the World<div align="justify">
<img align="right" src="http://cnet3.cbsistatic.com/hub/i/r/2015/01/22/b296b5a6-dc10-4be4-9627-05178e574c7e/resize/770x578/259277ce975f321a3aea6d7f4c411ac4/microsoft-hololens-rgb.png" height="139" style="display: inline; float: right; margin: 0px 0px 0px 10px;" width="247" />Ok. So I have just right-clicked the word “HoloLens” and selected <strong>Add to Dictionary</strong> from the context menu. I believe that this word will be there for a while, and sooner or later, on everybody’s lips. </div>
<div align="justify">
In case you have been out of touch with technology news in the past several days, <a href="http://www.microsoft.com/microsoft-hololens/en-us">HoloLens</a> is Microsoft’s newest device, still in its earliest development phase, which has been unveiled for the first time (after many super-quiet years of secret development) at Microsoft’s Windows 10 Event in Redmond, VA.</div>
<h3>
Meet HoloLens</h3>
<div align="justify">
HoloLens is Microsoft’s leap in to the virtual reality – or rather <a href="http://en.wikipedia.org/wiki/Augmented_reality">Augmented Reality</a> – arena. Wearing HoloLens will allow you to view the reality around you, with holographic images, videos and even sound overlaid on your surroundings, allowing you to interact with it with natural gestures and voice commands. Imagine being able to see a video on a virtual screen where your wall should be, or a floating instructor – either virtual or a real person on a Skype call – along with arrows and guidelines for, say, fixing a sink. Imagine your game world overlaid on your real world!</div>
<div align="justify">
There are a lot of different ways to <strong>use </strong>HoloLens, or a similar device, and most people whose comments I’ve had the misfortune of reading, seem to see a cross between an even weirder-looking Google Glass, and Yet-Another-Gaming-Console-That-Will-Never-Replace-The-Controller-We-Already-Have.</div>
<div align="justify">
I disagree. I think that the sheer number of possibilities such technology can offer is mind-staggering and goes far beyond gaming and taking pictures and videos of others on the street without the subjects knowing it.</div>
<div align="justify">
The following list comprises what I believe may be the five most pronounced ways that HoloLens can <strong>change</strong> how we interact with the world around us.</div>
<h3>
1. Virtual Privacy</h3>
<div align="justify">
<img align="left" alt="Not my office. Just a picture off the net" height="164" src="https://boagworld.com/wp-content/uploads/2013/09/cubicles-515x308.jpg" style="display: inline; float: left; margin: 0px 10px 0px 0px;" title="Cubicles are hell" width="275" />Many people in various industries are victims of what seemed to bean-counters like a great idea. Cubicles, bullpens, hotel-desks. No matter how you call them, Work environments where people who are not collaborating on the <strong>exact same task</strong> are forced to endure noise and distractions from others are detrimental to productivity. At my current job I sit at my (small) desk, and am surrounded by people who are almost constantly on support calls that 90% of the time have nothing to do with me. There are also at least one man and one woman who seem to be chattering about non-work related issues, at least half of the day, everyday. The noise is annoying. Add to that the fact that there’s no privacy – my calls, my screen, etc. Personally, I hate having to think that someone may be looking over my shoulder while I’m browsing, reading, coding or answering emails (unless I asked them to). Finally, I miss the gigantic whiteboard that I had in my office, the last time I actually had an office. Just something that I could always look up to from my screen, so that I can verify or validate some design decision. So I work from home as often as I can (though I still miss my whiteboard. My wife just won’t let me put up one in the living room where I work…).</div>
<div align="justify">
Only at home, while I do have my privacy, I only have my (two) laptops – no 24” screen (its on my shopping list), much less two of them. And my really good keyboard and trackball mouse are at the office.</div>
<div align="justify">
<img align="right" src="http://staticai.worldviz.com/wp-content/uploads/2013/04/Cave-user-touch.jpg" height="165" style="display: inline; float: right; margin: 0px 0px 0px 10px;" width="220" />Enter <strong>HoloLens</strong>! Imagine coming in to work and putting on your HoloLens and sitting down at your… <strong>virtual</strong> office. That giant whiteboard? Hang it wherever you want. Might as well share a virtual strip of wall with anyone else in your office. It doesn’t matter. You see your whiteboard, I see mine. Or just hang it in the air. Look up to it any time you want from your 24” screen. No! Make it 48” or have several of them. It’s virtual anyway. Ever wanted your emails to be announced just not on your screen because you’re coding now? No problem – they can float off to the left, if you want. Your office can look however you want it. </div>
<div align="justify">
Just add some pluggable <strong>noise-cancelling earphones</strong> to the rig (hear that Microsoft? I want to be able to plug noise cancelling earphones into my HoloLens!) and that annoying chatterbox may as well be on the other side of the world, for all of me.</div>
<div align="justify">
And did I mention the privacy? Nobody looking over your shoulder. They can’t see your (virtual) screen unless you share it.</div>
<div align="justify">
Oh, and for the bean-counters out there – as soon as this device hits the $2,000 mark, it will probably be cheaper to buy than the desktop, desk and cubicle that your office currently has.</div>
<h3>
</h3>
<h3>
2. One office to rule them all!</h3>
<div align="justify">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgqRSnZJdY5E7m6k4_nhqsVVidvY9HLOUyk5xOIymBvRM_3X-PEnb_N4oXPr84jQ-7cIsN4prXn2TkICRTXOYAFKQaMBNT__UOvIlwwsB_bt3MkrHn3Mc01oB0KFOpMLNOXGWdm-e1pG9C/s1600/virtual+office.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" height="133" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhgqRSnZJdY5E7m6k4_nhqsVVidvY9HLOUyk5xOIymBvRM_3X-PEnb_N4oXPr84jQ-7cIsN4prXn2TkICRTXOYAFKQaMBNT__UOvIlwwsB_bt3MkrHn3Mc01oB0KFOpMLNOXGWdm-e1pG9C/s200/virtual+office.jpg" width="200" /></a>Moving on to #2, and moving home from the office. If you, like me, work a few days at the office, a few days at home, and a few days at the local Starbucks (or wherever you choose to water your horses), you know that having a decent laptop and VPN is crucial to get any work done, but you may have to decide between shelling out extra cash for having the same office set up at home as you do at work, or do without the comforts that you have at one location or another. You may decide to buy a decent monitor for home, and the same keyboard, but you are definitely going to have to live without your 2 x 24” setup whenever you go to work at the coffee shop.</div>
<div align="justify">
Enter the – you guessed – HoloLens! Just lug that HoloLens from your office to home (and even to the coffee shop if you aren’t concerned about looking like a dork), and you can have the exact <strong>same office setup</strong> anywhere you are.</div>
<h3>
3. Training and teaching</h3>
<div align="justify">
<img align="right" src="http://rack.3.mshcdn.com/media/ZgkyMDE1LzAxLzIyLzNhL01pY3Jvc29mdEhvLmVkMGU5LmpwZwpwCXRodW1iCTEyMDB4OTYwMD4/ebef2efe/38f/Microsoft-HoloLens-Skype-RGB1.jpg" height="185" style="display: inline; float: right; margin: 0px 0px 0px 10px;" width="290" />Ever had to explain to someone else how to do something? Ever had to do that when you were out of reach? 10 miles or half a world away, as is often my case, something always seems to go wrong just as soon as I’m away. The farther I am, the greater the problem. I go to work – any my smart TV cannot connect to the internet, leaving my baby daughter unable to watch her favorite YouTube nursery videos (mainly “Twinkle, twinkle little star”, and “<a href="https://www.youtube.com/watch?v=eRBOgtp0Hac">Peanut Butter Jelly Time</a>!”) on the big screen (<strong>#FirstWorldProblems</strong>). I’m out of state? The thermostat doesn’t turn on the furnace (and it’s below freezing outside). Did I leave the country? The garbage disposal unit won’t work.</div>
<div align="justify">
My wife is very capable, but I have a bit more of a knack for figuring out what went wrong and how to fix it. I could guide her, if only I could see what she sees, and show her what to do…</div>
<div align="justify">
Enter – yet again – HoloLens! Skype + some virtual whiteboard tool, and I can see the sink as she does, point out where to stick that screw driver, see what’s happening and adjust my guidance without her having to describe what’s happening. Think Remote Assistance, only outside the computer!</div>
<div align="justify">
Imagine <strong>a</strong> <strong>doctor training for a complex operation</strong>. Just put on the HoloLens and bring up a virtual body. Do the operation 100 times until you get it right, then swap for a real body. Keep the HoloLens on, for real-time guidelines on the procedure…</div>
<h3>
4. Design!</h3>
<div align="justify">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgVQVEu2AJ3a-R1G_6baXSlFWeC3-p-1nqloSaXv8PaN-nxoiS_0diHKb8S2Y5tvKdn2xpsqqSbGxaVie2Pf-WFMaDk4qa0mzcN4LFKM1nG7fp2s8zwf50yBIvF-bmzXGw7YIK2ckyi4TOl/s1600-h/image%25255B3%25255D.png"><img align="left" alt="image" border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjgZoEEX0iaQjD9K-0LD2dzAp_Ed_QLXpDIh3W_F0PWB812CA2bYNY4fkksPzsYD8ktu7xDZPW0cFQ45Mi_jdVF_2i5kga6U691hLF7CWAkgOwYPKRT713yQebpib5gzhfOUgVnxV67dmNf/?imgmax=800" height="208" style="background-image: none; border-bottom: 0px; border-left: 0px; border-right: 0px; border-top: 0px; display: inline; float: left; margin: 0px 10px 0px 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;" title="image" width="195" /></a>When Tony Stark designed his Mark-II suit (yes – that scene in his basement lab), a new era of imagining how we design products – forget flat rendering of 3D objects with blueprints on paper. Let’s have the objects floating in the air right in front of us! Zoom in, zoom out, step inside, turn it around – we can <strong><em>really </em></strong>understand what the design looks.</div>
<div align="justify">
3D Modelling will be come a much more natural process, and design verification will be much better. We’ll be able to see what something actually looks like before we make it.</div>
<div align="justify">
And speaking of seeing what something looks like, and speaking of Iron Man, imagine trying on a suit or a dress before you buy it. In the comfort of your own home. </div>
<h3>
</h3>
<h3>
5. P0rn</h3>
<div align="justify">
Let’s not pretend that it won’t change this world.</div>
<h3>
Closing thoughts</h3>
<div align="justify">
I am mostly psyched up about the first two options! <strong>Productivity</strong> in the work environment is a key concern for me. I believe that improvements there will ripple out to everything else we do.</div>
<div align="justify">
I’m sure that there are other amazing ways people can improve whatever is near and dear to their hearts with the aid of augmented reality. What would you do if you had a working and stable version of the HoloLens?</div>
<div class="wlWriterEditableSmartContent" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:1e35ec9f-dfa0-416b-bc4b-d36655bbaf8a" style="display: inline; float: none; margin: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
Technorati Tags: <a href="http://technorati.com/tags/Microsoft" rel="tag">Microsoft</a>,<a href="http://technorati.com/tags/HoloLens" rel="tag">HoloLens</a>,<a href="http://technorati.com/tags/Productivity" rel="tag">Productivity</a>,<a href="http://technorati.com/tags/Augmented+Reality" rel="tag">Augmented Reality</a>,<a href="http://technorati.com/tags/Virtual+Reality" rel="tag">Virtual Reality</a>,<a href="http://technorati.com/tags/AR" rel="tag">AR</a>,<a href="http://technorati.com/tags/VR" rel="tag">VR</a></div>
Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com0tag:blogger.com,1999:blog-2660291115609609354.post-17372817666762877182014-12-03T00:13:00.001+02:002015-12-28T17:09:47.677+02:00Winter is Coming… And I’m fine with it<div align="justify">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkm1aaGxpbZC6IhEzn1lqM4iXQqbAigvlpdxOmNiOOXnlsuHvTQ_eYnKDWBtouxeS2S_KVtN0NFs9HhTFAeuRjFuORffQBID5YagEPzNQqplhesmVApLdBZMrpaACQb88zy9ZWOUPhoyrm/s1600/Wall-e.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" height="186" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhkm1aaGxpbZC6IhEzn1lqM4iXQqbAigvlpdxOmNiOOXnlsuHvTQ_eYnKDWBtouxeS2S_KVtN0NFs9HhTFAeuRjFuORffQBID5YagEPzNQqplhesmVApLdBZMrpaACQb88zy9ZWOUPhoyrm/s200/Wall-e.jpg" width="200" /></a></div>
Today I read an <a href="http://www.techrepublic.com/article/robots-about-to-make-your-job-much-more-boring" target="_blank">article on TechRepublic</a> about how robots and computers automate more and more roles previously carried out by humans, and how we won’t like what’s left.<br />
<div align="justify">
We all know what’s coming, manual labor will be replaced by machines, leaving only the jobs that (still) require a human mind. I’m sure you cannot throw a stone without hitting a politician or spokesperson who will tell you that this is bad, but at the risk of coming off as a detached and condescending elitist, I will have to respectfully disagree.</div>
<h3>
Change Happens</h3>
<img align="left" src="http://www.trainingzone.co.uk/sites/default/files/styles/540x350/public/images/change_sign" height="144" style="display: inline; float: left; margin: 0px 10px 0px 0px;" width="222" /><br />
<div align="justify">
Change happens. Always. This isn’t a new thing. Change has been happening since the beginning of time. Literally. Without change we’d still be a potentially explosive situation in the middle of nothing, because the Big Bang wouldn’t have happened.</div>
<div align="justify">
Okay. I’ll agree that that was just some demagoguery. Forget everything that happened in the last couple of billions of years. Let’s limit the discussion to technological advances. Disruptive ones. Like agriculture. Advances were being made that changed the world, and the roles humans played in it. It started some 10,000 years ago, and is still going on today. Still not convinced? Still think this is demagoguery? Okay, I’ll put that aside too. Let’s talk <em>“real”</em> technological changes.</div>
<div align="justify">
How about the Industrial Revolution? Those factories? Them machines sure replaced a lot of people didn’t they? Please note that that was going on some 250 years ago.</div>
<h3>
Change is a Good Thing</h3>
<img align="right" src="http://petapixel.com/assets/uploads/2013/04/kaizen1.png" height="141" style="display: inline; float: right;" width="219" /><br />
<div align="justify">
The Japanese word “Kaizen” literally translates to “Good Change”. Now, I’ll say straight up that not all change is good, hence the differentiation, but I believe that it is more often better than it is worse. I don’t have any scientific proof of it, but I seriously doubt that anyone could argue that their lot in life is actually worse than it would be if they were in their comparable station in life in or around 18th century Earth. I think that even people living in 3rd world countries all over the globe are as well of as they’d be, or better. I believe that just being able to discuss their issue, having first world people become aware of 3rd world people is an improvement. We, as a rule are becoming better people.</div>
<div align="justify">
Please note, that the comparison I am making is between one person, and his or her own lot in a world “stuck” in the past. I believe that inequality, while it is a touchy subject, is irrelevant here. I know that there are people who hunger for bread living a few miles from people who have more money than they could ever spend. But was that not always the case? I believe that I myself, my friends, and probably anyone who has a computer, tablet or smartphone with which to read this post lives better than most nobles did a few centuries ago, and better than any king just a few centuries before <em>that</em>. And I’m just making a (fairly) decent living.</div>
<h3 align="justify">
So What is the Problem?</h3>
<div align="justify">
<img align="left" height="157" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjUqBFiqzjO9LvJN0_m2PiWDIGDuEzncePx8fnMjfdmXh9htsvxm7tbNB1p4DCSMNTPrLAb1RAAGXzisJ7SxGYpyitFNvs3aggCARQ6vigplFqYel6w2XvLbvmVY6fVhLMWZaSmDXdHnD5v/s1600/information_overload-1.jpg" style="display: inline; float: left;" width="210" />Adapting to change is difficult. Disruptive change, more so. When something that you know, and believe in may become invalidated and obsolete, it may feel overwhelming and scary. Other times it just makes you feel irrelevant – just like your (now useless) knowledge.</div>
<div align="justify">
People have been losing their jobs to machines since forever, possibly since ten thousand years ago, definitely in the past 250 years. But this isn’t a bad thing!</div>
<div align="justify">
For every manual laborer whose skills were no longer necessary, two jobs showed up for factory line workers. Old jobs transformed to adapt to the new world. New jobs were created. Some people adapted, others did not. Those of us who adapted were better off for it. Those who didn’t, weren’t. And we can and should feel sorry for them, and that is okay, and it is okay to rejoice in our own improved lot, because the change made our lives better, as a rule, or it wouldn’t have happened.</div>
<div align="justify">
The issue at hand, I believe is that <strong>change itself has changed</strong>!</div>
<h3>
Change is Changing!</h3>
<div align="justify">
<img align="right" src="http://www.theemailadmin.com/wp-content/uploads/2013/03/evolution1.png" height="84" style="display: inline; float: right;" width="279" />Change was always happening, and the rate of change was always increasing. But where in the past change happened over billions of years, until it could be measured in millions of years, and human advancement was then measured in millennia, at some point changes became so great and so quick that we started to notice. The industrial revolution was, I believe, the first such point in time, with change so great and so fast that it one could perceive life before and after it, within one’s own lifetime. Since then the changes began to happen every several decades – factories, the telegraph, automobiles, airplanes, radio, television, computers…</div>
<div align="justify">
Computers.</div>
<div align="justify">
From the 1943 legendary statement, (allegedly) made by <a href="http://en.wikipedia.org/wiki/Thomas_J._Watson" target="_blank">Thomas J Watson</a> that “there is a world market for maybe five computers”, to a national average (US) of <strong>more than five (5.7) internet connected devices per household(!)</strong>. In 70 years, computers have transformed (almost) everything that we do, allowing us to do more, much more, in less – much less – time. Everything. Including research work. This means that the <strong>rate of change</strong> itself has changed, dramatically and visibly increasing.</div>
<div align="justify">
Why, up until roughly 20 years ago, hardly anybody outside colleges had any personal or commercial access to this overgrown, BBS-on-steroids thing called the internet. Ten years ago, I had a palm pilot, had a slow GPRS modem to connect to it, and was the only one I knew that had one such. Seven years ago, the first iPhone came out, and while there were “smart” phones before, it was the first device that was actually accessible for the general population.</div>
<div align="justify">
Now? <a href="http://www.emarketer.com/Article/Smartphone-Users-Worldwide-Will-Total-175-Billion-2014/1010536" target="_blank">More than half</a> of the entire world population have mobile phones. 31.1% of the population have internet access, meaning that <strong>just under a third of the people in the world have access to the sum total knowledge of human knowledge(!)</strong>. Let’s ignore the fact that most people’s usage has nothing to do with knowledge (except in the biblical sense).</div>
<h4 align="justify">
The Pros</h4>
<div align="justify">
Is this a good thing? I think it is. For me personally, at least. I cannot imagine being able to do my work, without access to millions of code samples, documentation, tools, guides, online books, etc. Twenty years ago I had to remember most of the software languages that I use, or else take a (heavy) book off the shelf and flip through what I couldn’t remember. Ten years ago I had intellisense and computers had enough memory and disk space for references to be stored on disk for quick access. Today I don’t ever bother to install the help, documentation and SDKs that come with the tools and languages that I use. It is quicker to Google it. Googling even became a word. Almost everybody knows it and does it (except for those who must <a href="https://www.blogger.com/www.baidu.com" target="_blank">Baidu</a> it, and those who choose to Bing it, and those elitists who prefer to duck-duck-go it).</div>
<h4>
The Cons</h4>
<div align="justify">
Some people take exception at this change. From developers who claim that Microsoft-stack coders who rely on <a href="http://en.wikipedia.org/wiki/Intelligent_code_completion#IntelliSense" target="_blank">intellisense</a> have become crippled by their inability to code without it, to my wife who gets upset because I do not (cannot?) remember anything that isn’t on my calendar, people believe that we who rely on the internet to remember for us have lost something by giving up the skill of memorization. </div>
<div align="justify">
Personally, I think that a skill that is no longer needed is not worth having except for recreational purposes. I don’t remember how to sheer sheep, gut a fish or skin a rabbit, because I never knew how to do these things. I never needed to learn (though if I did, I’m sure I could <a href="http://www.google.com/#q=how+to+skin+a+rabbit" target="_blank">Google</a> it).</div>
<div align="justify">
My main argument is that it is foolish to waste brain power in learning things that will soon become obsolete.</div>
<div align="justify">
<strong>And that is our problem</strong></div>
<h3>
Changing is Difficult. Not Changing is Fatal</h3>
<div align="justify">
<img align="left" src="http://images.fineartamerica.com/images-medium-large/extinction-jack-norton.jpg" height="116" style="display: inline; float: left;" width="155" />Saw this quote somewhere. It is largely true, I believe. For myself, I love change. I can’t wait to see what the next big thing is, what’s over the horizon? What new technology will come out tomorrow…While I appreciate my own generation’s unique stand point, being born on the cutting edge, riding the wave of technological change, We are immigrants to this brave new world. I would love to have been born today, to be a true child of the millennium, to be born a native child of the world of technology. What does my eldest daughter at 13 feel, never knowing a world without the internet? How will my baby experience the world, growing up in a world where scientific and technological advances I can barely imaging will be common place?</div>
<div align="justify">
But it is a constant struggle, riding the wave. One must adapt to change quickly, one must learn to devalue what one knows, in favor of what can understand and extrapolate. Hanging on to yesterday will cause you to fall into the chasm with it.</div>
<div align="justify">
I figured that out on my own. My children will have that engrained in them. But many of my generation don’t understand that. Most of my father’s generation do not. How surprised are we to see our parents have a truly thriving online presence? Our grandparents? I learned to work with computers at an extremely young age, because I saw my father, one of very few at the time, using one, programming. My kids still perceive me as an expert on technology, though I already defer to my daughter in some areas (social networks, mostly).</div>
<div align="justify">
My mom can operate a computer if told exactly what to do, step by step. I have friends whose mothers can read their email, because they have to, as part of their work, but go to pieces if things don’t work just right, because they fear the computer. Computers are alien to them, and the change they bring is beyond them.</div>
<div align="justify">
My grandmother, and some uncles will still want to explain to me how to get somewhere, all while I politely explain that I just need the name of a place or an address and Google Maps will do for the rest. </div>
<div align="justify">
That’s all okay, they have their ways of doing things, and I have my <a href="http://www.waze.com/" target="_blank">waze</a>.</div>
<div align="justify">
But not at the workplace. </div>
<div align="justify">
</div>
<div align="justify">
</div>
<div align="justify">
At the office, at the factory, time is money, and anything that a computer can do, it can do faster and with greater precision than any human can cope to do. </div>
<div align="justify">
And once a computer can do something, it is only a short matter of time before it will replace a human doing it.</div>
<div align="justify">
What will such human do?</div>
<div align="justify">
Learn to do something new, or become extinct, obsolete, unemployed.</div>
<h3>
The Way of <strike>Tomorrow</strike> Today</h3>
<div align="justify">
<img align="right" src="http://pixabay.com/static/uploads/photo/2014/11/01/15/22/technology-512210__180.jpg" style="display: inline; float: right;" />At any job interview, I will tell my would be employer that the biggest asset that I bring is adaptability, my ability to learn, knowing how to know. More than one customer asked me a question, and when he saw me searching the internet for the answer, he or she asked me something to the equivalent of “If you don’t know the answer why am I paying you”? My answer is always a simple statement that I’m paid because I know enough about my domain to Google faster than anyone he or she employs, I know where to search, I can understand what I read faster, and extrapolate a better solution to the problem than anyone else (perhaps a bit arrogant, but selling yourself short is never a good idea, and stammering any other answer would be worse).</div>
<div align="justify">
What is my point? My point is this, in order to thrive in the world today, one must cultivate the skill of learning in one’s domain of expertise. One must learn to adapt to disruptive change, to seek out these changes and prepare, to look for opportunities to adapt first and come out on top.</div>
<div align="justify">
That, or fade away. Or hope you can retire before becoming completely obsolete.</div>
<div align="justify">
I consider myself lucky (though I believe in making my own luck), I could never as a kid sit down in one place at school and learn to retain knowledge I considered useless. I instead learned quickly on my feet, figuring things out in the middle of a test, extrapolating from whatever I learned before. Today this a prized skill.</div>
<div align="justify">
Others who are less lucky have to learn now. Change will never stop. Not everybody will hold back, and not everybody will stop inventing new ways to replace human labor with computers. Perhaps one day it will all be computers and machines doing the work, and perhaps we can become a utopian society where machines can sustain comfortable human life for all, and people will simply do what ever they can to make themselves and the world better, not for monetary reward, but because they want to fulfill themselves (see – this isn’t communism).</div>
<div align="justify">
One can hope.</div>
<div align="justify">
And adapt.</div>
Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com0tag:blogger.com,1999:blog-2660291115609609354.post-78126752052775606842014-10-03T16:19:00.001+03:002014-12-12T16:37:42.887+02:0010 Things You Should Know When Submitting a Bug<div align="justify"><img style="float: right; display: inline" src="https://skaheru.files.wordpress.com/2014/07/bart-phone.jpg" width="174" align="right" height="169">An on-call technical support engineer wakes up groggily at 2am, when his phone rings. It’s a department manager. <em>“Huhhhh? Huhhlllo?”</em> he mumbles into the phone.</div> <blockquote> <div align="justify"><em>“Your software doesn’t work!”</em> states the angry voice on the other end.<br><em>“Uhhh… Could you be more explicit, sir?”</em> asks the still bewildered techy, trying to figure out what’s going on.<br><em>“Your software doesn’t #&@<ing work!”</em> </div></blockquote> <div align="justify">So, that might sound like a joke, but for many people in the software development business, this is just another workday. It seems that whenever somebody has a technical issue, they become even more technically illiterate than they might normally be. Personally, I believe that fear and frustration with their unknown situation, coupled with annoyance at having to deal with a less-than-perfect product reduces the end-user’s ability – perhaps at a subconscious level, perhaps not – to be a part of solving the issue. They want it solved, and they don’t care how.</div> <h3>We want information. INFORMATION!</h3> <div align="justify"><img style="float: left; margin: 0px 10px 0px 0px; display: inline" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEifjkAyRn_5xxHfNBOs90L13114huCNpWsniozWW4CKJ21Z2zDp9gB0FkqR_akY_yQ4b0lUvVJFfRCdQ6H-93lsHTRwJibUwi-iP7Q-Z5A4dRcjPwhrJWZEuza-BpWGObUDocY_2Al8sw/s1600/the_new_number_2.jpg" width="225" align="left" height="165">No, I’m not the new number two. I’m just another developer, who has to solve problems with software, and consequentially, solve problems <em>in the software</em> that solves the problems. I get bug reports coming from end users, testers, middle managers – sometimes even fellow developers – that leave me without anything more than a general sense that there was a disturbance in the force, and the software is not performing within acceptable parameters. </div> <h3></h3> <h3></h3> <div align="justify">Please understand! Most of us are actually eager to solve problems! A lot of us actually got into this business because we have a hacker mentality, we’re tinkers at heart, and we view every problem as a challenge to meet! Don’t hear us clicking away furiously at our keyboards, guzzling coffee, muttering curse words (often in foreign languages such as Russian or Klingon), and then stop with a resounding “WHOOP!” of joy? That’s a feature we developed or a bug we fixed.</div> <div align="justify">Help us help you.</div> <div align="justify">The items below are the top ten things every developer wants you to provide – as best you can – to help him or her understand what the problem is and how to reproduce the issue:</div> <h3 align="justify">1 – What do you mean to say?</h3> <div align="justify"><img style="float: right; margin: 0px 0px 0px 10px; display: inline" src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAOEAAADhCAMAAAAJbSJIAAAAkFBMVEX///8AAAD7+/vt7e319fX4+Pivr6/q6urU1NTw8PCdnZ329vZ3d3egoKDf39+oqKjMzMx9fX3CwsKTk5Ourq61tbViYmLc3Nxzc3Pl5eW8vLxERERqamre3t7IyMiDg4NRUVFsbGxLS0uLi4tZWVmCgoIoKCg5OTkdHR08PDwYGBgyMjJGRkYnJycTExMLCwvOIhi4AAAgAElEQVR4nNVdiXaqyhKVSZCATDJqEIQ4RE3+/+8eoIm7ekAz3XtfrXXOiojQ1TVXV3dNJn8NxswKvSjIkmqz/IBNlWRBtAitmfrn7/9LMNJpUx02ydorrFzTERlV13K/8NbJ5lA1cfr/iGe6yI7Ll4Wl898wn3XfCw5HZ8Fe/y9Dalc7ZzoXf7lOhJefF9mudf8fsHyKk61TzKTfZ00t/U4rsvOqMP5iWL8Fmrc5uPmde8Q0/IC5fag87RfH9ItgLJbVQk68D8jHMZwM83SK/3u6x0+OHq9VBHAfww5m7rG2fjiiXwXdPgbPD96bt4/dlwZH9+nbI/pdmGe76eN3q49OxURdHJ07Qv2PgFW1f8dP/l8+/MEhHLJHpjm3Ci9qnFVbbU6bql05TeSF1iO/nK+W/yaO1iG7ozzN0M6W76+nrLGnoWWl8zzP56llhVO7yZav76fMLs3xR2j1v4ZjWtVjhsssmuXrpnPcTLnmV01/EZxeT004+qRV+2/I46weee0szl5360JAHefQ8k5LXrwc904htzbzjfOQKfpNsI++7CsrOh4bX+x8udGkCITf6OV6u4ukjml5dL86xB+Bf/Yk31iB0i7kLNfhXayl35qL6n0tQ9Ld/nPi+LRaiSmUR+9tccffSt9GbzDi6jUS6x49yf4hr7zYihm0OBwXd6Wl3N51VGbe8RSKf3wWX/9dMFqhHM0ixZFEhAjWVlUfcKqfMyUSTla2+nOXvBRKw7x+9R56td1Wp+aRGw33TehL+BIG+jUIVoKLz+3xL7in2CYCHNVWrql+DuYx5i/O2939aVVnphXGC8+Oosj2FnFomQ+k2cqjCMfF4X4U+k0Ij/z7Ziu5YbzcYHnrpA7W9rTwrblpaqY5t8piaq+DetV41vhoy3PGy+P8rzi14TlUbd4L+Q8M386SJrbkOv7JmjaJY0vcgwFiJeIvtoJrP4fK5t/+zl/7AL+pg5ijuVG1DnfrPA7qSG7Oo3deyqMH4+gvgHbmOMNcriTmz4hrJxY6Nm48yYS4mNMsiyWknLUV97Dy+MvCaJ05ctiv4mk34iwYkRNrI/UKyiCTeETlO+eVzvcPJwsegfDITm++FSttaxS9DuzlmGNQBo7YLw2OrCun/6a+8Sr2ivsqmkHVSxbjT9LUbg5G7+ifISJk+s45+yeB7foe2KwSfTqJPLfZ2rnr/TfRZC0LSz7BchoRJ2cVi3l791GPQcNqP18p+btMZ/1Iqrpp5eoXHhYEgoeFCjuD9a9YjfULcyHa8TNsBsJp/z7M1gIctSM7PdkvoPjCapSK51AjWD+iu7W5Zfm+b1nzR6itBWteHjPWDjo/RrFhKGi+8+LtrkbTZfpz4XXuaOROww67Dvxw2vunkVfMRwmfJ7ycLfbM7PyUihEjg77CKXO/HdHaaYebF5riqFfPw/7rkUXDkk8IW6wwrn6UwPGYZZR4z3KjkUk1Rz6NopInEivWehlFsZQJIodlVY114tofGI2wYl53YO8oEsnYLDcSr5MGiuCiFkey9d+8Zb1SlU27Lb9t+q0j/bxmxVytxQbJtCNfEv2F9lH8hVpGrlgBuZyLsGFk7/xNB87cU1ctY9/kt0IChpF8fVNvJ2fpC9VpJMwV5BUrjQnV57PX77nhe+ps16zhb0QJF8O1x/zOtlkIYqEbPEfCfM8LK+zMYJ63I8+UwoZy94rREEYrcGw02x1Pafph+D7u2j3ZtoAgYcIgnlEUw2/Ei2s6bcwTJ3M+ZJvMxARgQCKHNzA8W+A0VUz4tqKM2nzZLBbUTrwwMhgKcm6u+1u5TMMWaLCE4ZmECkklYKkxMKk+YJMGNj9jRfSAtKuGPtONByZCa3hpZYOSDTUanKkehy3hiZixgwG3bp8Ho+VMpr+wXdd2F9O4iKcLt/+w8Ee9UyvgFLXHqDaapU13Y49jwSEo+G/02xXHEK48UNPCDptwztNNfS5s1xtZGuUfWlBZMagD530hVRwSIcwVSv+EVYbzF4ljo5auyyyTThceYY+8cN1SwrZ5wCaHfCr+pkLmp3rYt3nak1cyznbLOhCemIBqaHtc+mq2K/gU49yzQzGSLisOFlWAlLuYcY8ADRY21LFtGYNuvAhdJkuAXj+kJhUazNyzhWbSYmNEBkWPqMDwkXqrDmJi+pgcRsLgk7KhwuURsgSvvXTfJE6kH4liBJXlVIsy6oqY7dVDK0T6Hj+V1ECvmJEXguDsybPHtKQvzbWZ0UJAYJsZNfP7PY5IfYhPE+RRnWqZgNGiEW9mVdcbWeWN5pNQSPXr60RKOWRmsSBGw1RwVsLxVOUAPuHlA5lAmxH8F17UYnvUMbW2zXE0c6FH/FJPythBqtriCj89UCVGQiabCGHIeDIB50X40b3SHuPuUnjOy7DJkH1NVOEKEZ7djTIivD1/x6/mVMZVh6WWEf1Onr2MWGnSGb+fLJyqCppckUuLMCOK5YyW0KjInQa3ShaO5Xq1NCzixdVrW8RFmI64kSo3VSqTriHpb5qL2I7Hbyt8dESYoyUKUuUQlK4Aqv50Gpc5WdVWZ3kZT6dSofFZ1555H600zlAXheKaqyukFT6F8GhD1SaL4LwR6+k8nhK/TY9REM1iUYgl12iY6wyKBWEY4r0tx3TBBr88ID19qs8ChhUK4ZqTGbNU0s/FgeFAayrOJXqMHdSpuiHBDEkKpiPxvoV7IWJkBJX+6oURIqHLVXq84ukMqM5PsejOblIZO2gyIS/5gNORyCO5AxBbVdBu1WSaWZvQ8D6MWixElKmzSrCu0/ulgooHkxHGlKCcI9tqKFH5RvCGAYg/1CCjF0QFF1QkDYEIxlOxXU9iWW2ivuBxNBi/u6D+Bw6DDJeL7z4AK3E0TE0bRHPRqZzM+KRi6ck0dqevLL4Y4wK6y/NqQx9kE+ZpEX9kOVNCRLL8vMIZzZDhDCrxMy5lk49sDDK38U4uJXOX42xmWZJYghw/TXHiJJKI+bo5GlGfaGaKoM4hOB2NYPTRiu5JwUVQlIoGYfEGEcEE9rMwUCSbWUgQTPSoR8I7g2VR0/3ZWvCMi7zoGywyBTgykuAUZHM7Gw7i+Yx5KyIec+r2sQiGI0VgeurHnmu7XuynI9MQsxEZfYeNjByiGT7DN6UgRNMRKSShQRxu+kvWRfYkkYNZrCuFQrUuJPyaMr6zQQWBiCJyIyHikdfvLpA/RykkeUuqCpjlMFUcG1rroyKGYyNU6zrjwuee9NMcCbyHwXm8k4VI1aAsTJRt+q6Cjk8TLTfnDcHJTq3UJleEZevM4oxPGJdIqgN3xkBelVvM9QGRGWZqSJhLlTXVe7nANfVbnnBzlqKisJzZRkr9I5QUQoA34CGuemwFEoRRMHEGC/IrKh45v0PPPwg40434ayceR8bnI++y0B4hBWxgb9axMJCoCkgp2Y1DtBoVFh7BOatbLmAKr/I7jOi2FIO8DcehARGfMEHMrOLFQDbctjNDJnCRYUsy7zOORRshJoozFV/nK4HpplsfX2eiOnAgtVeDwNrUcJ3gcRhBYq3aDDWJStSKyiqZ9E2CSJhIvlDOrKWhzyRERKWdw9xgaKgRRwU/mcCwJLAmxo/yKIugLUNDcWWWo/9uDEUyiU/4enSnt8BmpFTXA7UYAcN5wBsasoZFeJRNVUvpdAeYwwh0Itslqjn0DX0YvAvzgEhNKkB9D3yNLoMtJWFJ1cRMSqbzJulhs5fdcKDeXErCKXznE1IUfBnMFZoweuMETwWGtYCcBj6TJJdMGkyIleWbEzgvq83ysDssN6sXJ8jeRbe9UjtIyqpytPuomFyQYMw0gbhhCL+G8SKHkzIS4tpQN3IuGPdRgNBbFjgiYlN+IM/GOZ7BN0+g/GNAHeqPVvBYMCkGujDII0TuCrIQI6Bgu17d0Gv84Ibkai3weYjDNkP+0FGwkIhACQNKLNLb+IF5kUljEIMQOMFA42cSn3HG8V7bLOFTXSoW6qFNw+G4JzMWIsJYrpPCe0OYB2TTzzUMwHWCy5TIpDhlhITU1LN8d2g25HMWsxaxatjfLMkT8fkzCRHRqHnAy/UHtrgGCdkoZFITn43y4BP/kTUTQc1SKLee2UuZw17AR+Zol4ioAHUBQ8xCxR/T097u1YFhkUnRVMTIOMRkMYZ+32xZbIqV4sTsxWPzSi8Q/UJEAmhhwF3IpufbUD/tBbAFrq/KmJQkUpFhGeqc1iwqilK2SlLwl4msKlSh6qhs8N0SNsV16itmKXztAN3gsgWXiTtDQkRqyNuax0TZzotUZO8dGoiQuADf4UMeDJUfeEMhBAtXI7EAToMVYOIMAZOSlSwkIQ38EonrJnHJV1SnIq1mqK2BNZFNoRwe3Zqr45bd5gK9blyMQIZAuUApzCkFxQi+7fd7oTOjrCgVNclbUERhVDlMyfbm+l1rYQDnEMQQCJ9DqBWCjJDaO0KEU83jUGV1NvilzioTRMcZyQhg3gzV6TPIC25xhNGCpBnL2/8XaG6ooK2YYqYAXo3ktHB8+0Bh4OTUO/i4q50le8sLYeBU8h54P5owWAWP4ZaBeljVtLxZNxRDCZOa6PqTAbNa9BR8EC0qsg+SBiyO5FcVPLuEGZawKcR5c/jpcArCFMYMSTZc5oEnYaRElByOLjuTkb994tch2BuMTxwphseVjIggJSmwLEb3gDli0f8SsrLoD4A1RBcQNSliiFK4o1pmAz6LvyX2kCHjCj0ElESJroEaABWECvyysp+E6qZ6sCALwkfMCQGGqACIIqWkSRB511OKUPYl80vQI+gbwgg0mGMYb3aTnsGrAQNh3xgW1z2BGTTgF+IGw8haQpjVieCwKF+IT7Mh9N6gnw4Kw8DXwnzDyKB2AovjOuwM5MwbVSyxoglhMpF1pIRIKILORvEoiTeEivgdZt7hXXPQb6hqbnKLFTWdoZgBeUGVgm7SYUqARVSYVzQVLdq1ExP+7eZ+SK8oCd5PiAi6BvkFXRmhC4Yroa0+scCNe78ZlfXtt8/g+gKGKBuY/kUyvGfKfSD34K+BQnPAFrgXVI12uxsrZDtzEcKUvN7+BMpi2gmejkwKQewRBesRBOldqE4xFIa3wRjmMPng1UDpiV1OoJAlPwnvh4pYjM/gnZicwZTTkgph5+oEL8E6cJhwsAJv57WGL3DlDP68jQcXE8C6HG9qeBpjwR0UY6B5AWbxIWCBd6J2RDajJDw2zgX794AJjfE+/L14PjF8A3pCsAelGKE9gUpxCH9xRQYwhCnTwA0Ad+sNRktJWGOyIiDuSwVcjnehEr/ZiBmoODQXtztebuo2XU+yG0W924yYMDnwFLiagvsGkYIDTFojFgFNSVUkOQPTcgbcE/HrxGODaC+6Udx0Joku+sICroCngCrFNB8iAn8jnVYUwQ5F1Eg4F4A6aAzNF44CDeJNgmD1Qqux2hb2i2HVCEwZPBvOWdHF40MFcvzAYXv88MrRPT8A/jhHt9ehVyPGEBJnkPjW2wnoT6iogds1saIGRZPCmF5ufwr0R5IlbeK0PCo1d+sAoNgkU36bZyBKeVMoaoWJNtgusoBwS2zwQelA5IRSBKN+vWDrXNyX5fUTiCz8DC+D1pTMszCg9UGvbq4YDiWwba9k121vMwamDk59rHHNs/X54yH8DXen5RXDp+TU49wnQAvLSuur1+VY1vJKw8ryV590aT/Ydjmopn1/Q2b5vcbtmfvVt/qEa8/cL5Zl9cvh/eSmm2G/ff8+67jp65ouPopeTS75NrUedq8PC2VF2yNx3Tk0/H+6YPgyzFY1H47fnDaX2qrOeDTxh/mJe44x+ol8sT7ntCN60ikcrxvL29u+j6CSHjVTOXSM+9arEu2sPL9+YHgjavbBj3utY8X+d92/RaCku4sr+/56Wd7oybK9lAP343cvjHjBcNX7Zn466JU+Xupj4NnbZHa+bv+atYMYLwcMtXIo/+8XNXR1MIuX6jGtN51DjYBZ98dZD4s/m3Xd03p4ubXu73OH8Zb9kAY32m+bjgD7AcOODu1VOrc37ZkMWqYzo6eOw/OOLZO3DuH40C//L4fbssGL6NB6dqbR54wGQynCsG7ihv26y6WAIa/MS8WdOpuo++vykmXubhh2avQDw+7O1+4Bl0ql6PCBYTXpD54ebO16nitPg+Sripu+6ddk/m7IeCc9I8aFv75iaEX1U3ul4fEWZ6wGE9/jbTprdd/9riN0YsW9RB8GDPMhb+z1Qu4XyyuGkaX1NZbTboB5PSQrLhgGfVA0vyiJZfi5gLYVY2jtewPZ01C9VEz3D/F2za42LjQ0LkF0/6dysTADDb2BTj0Nq7LzKK8YKlEQV9cc0xlouL/SsIv6kz706mn4/K409pWGp0s8trhwXL9JZHp5dZ946c+ROmTNgL81jLP3N4eqSXXYGyzFsJdDa/9kGBcM7fVkGlzkcJbmbXGVQ0V76g9Z7f+srMnBvMihMh/c6V4Oj7ny3nHnez/SDtlcGZFDxVd26VUOO8mLu0unXg3Zl6RB3G+4m+jnqxwqz5P+yK8elTzN+zRHL4drdyiGGnJR23Kif27DPCOG3ocubdq23wU+6NJ1FaifujT60KVpMji2/Z/6ajg5ZVhMKochDbo0sPzqqh9byx+062ABqo/0xmkw8OceY8cqz9d7z6XVc8OgcaOLI9hLndUO21b79+WrYevgNd5bXXXpJBiOw+x1qXVqq+pzVwXq0utPfm4P92DY4M+rP55dXPHNhZh/aA8hMtpMIE0D6XAo1P2aTwMeSc1fbp1klXysM8Gt7yvu1gHA3f6+T/PLfimMD/3S84cLdz5+LK45sMq2/Eu/9A9jCyRiwq7FtK3kTvDdoS5EElvA7Etji1+ODzNYXiEhPrMGStdP4c6tOD60vhQf3kSoiw8hxg/vx/g31pyJY3zMrh1ITLhC8q5JIrj95RgfDqdMmwls13wgTwOLzF/O02yb4CJ652BNV7pleRqYxC/laVqSp4ENVTlYDsy13SYHk/rwTg1HC8p+xwT2b1nQrNdBzawCY5pmX8MX4lzb9JbKncEgMNd2++E0luVL4f5CLAK/ly9FpGqI/L+dLwUdbJeynHdzS0pKTL71QM6bR/G45pbxSU5KkvN+Fue8weCb4px3NifrFqe76xa4AitZt6hw6enArFu0pjNnyogSXP2uMAEpTs7iKrT7yLqFimtPoHXEBhHrFB5ae2qpKPpLJVuQKxWxIvhbPMgJ3vX81bWn768fYi08rh8SOjCmvqiViCw+EcNP6Q8SYYCgyNYPbxLmApV77GANuATkv7YGTMpK6QIhqazZz8sp2hamiob8EjQplrXACEzxGnB9o/Kwb7+BNWF0w29/ytbxkU0RDVpxoCzRV31TAqjve9mRO1GRkgrF++v4WBwDe6nLXi3FkioG3CZ0+7MUiz8tp6mZktHgkxXrNMg/lWnClF3uZLUYZDH2a7UYQ8gP2J/u19PAk9AbnhCNwtbTHD5x3HyGf22wY+4ivyLbQ0FMZPU0twl5hp8OPTLU+zVRWF71UE3U64vCwM6pYTX7fZnxZezUUs4l74H3YzEa1ERN2ZqoCWwexcpF8BFQorFkCI0+rQ8+CLyZTb1yrnVt3DpNBxRllMI5MCZuwcBiNEld22XNAvrDaIAtbn2UsCnRALRKv6La5hPeXiXllzVFWlaH/EBt4vnG09alQAjLvs43Zw1tvrS+FPe40BroVoLiq/hyTc0GOTZIUl/6JK4v1bC+9MLHz8ARWCMsqfvCwjJaI0zdsYotUO/h/Tm0BJfZ9VNyBCK+A2UEIwIIFFDSPk45xt0zX6zzDnFzBK2hVQ6CLYiNzVYMXS4zahXlm5BQUueNatHh67yltfpo6IFNyS5zst3Co+N8YwfeOQNWYJ3Zi4eGiTcIZ+AbcvDeMCAoJLX6H6R1QevCAS44MVgjRySRtmmsmbFnrEpN/MBic1IO+yuynxrjJkJC9CWB3fLq9venhnkGDw2PZCPbK+FvcjIL3TPD7m0+Mrt+/KNyKsmVltuUQQ8mIXtmiLN/+xNzLli2d9vPBayJDgGeQxNChoYYDI3szXviVGXVIM3shRKTOsaGs4xbchoCaYpI9niCTsSBnkT7nm77gzp4vb1AlRIR9QttzKixA+5wfKlviafIv+mfff3CW/5X+jicP9m2J2RSHU6kA38Uz3dsxK7QhDTnJTt06f7DnBtzR5YscFj9snWCjNM53BZL8myyCQO4F8/ImuL+wxtp0TVFNkWHXSVGAvULkY5u2sU2feUEgVOdloflqer/FDsEZ0JBEu2SwlJqvmA0UECK7ijaC3R66D5gcqAijsOnJ5I+iY5SGOB913ZuabUT7ynpYENPJKH7qfGdaCrQ3GuSfcBkYxAePAiLbGRfKrMHecqc51nLMLgDzEEPRO7INicy3SXchoNHIziZVbe/TZgGomsIEeneeXYnvSfDIbL8UnLagqKwB0+QpxrEVcWvcI/7GZjxRPbQ4+78DUxWA2xNtvnfQTEXKJEetoe95LwMhWvMZ8s/4eEHeKaChScn0LOiMJWB57jq6F+QI1V8wqc6VagTdifbDRoJfbnDbeiJaOQYDnJQDLZfxfNzmU4SKuodSH3T42no2SZEK2jc0R+mePeaeLv+ijtRySN7unUyATgOPF5Gh2UJrkNBDe5fhJs28HCTkOg2ehqJyR/AYwki+ZVgB6lS8cerMUfwkLklRw7h8TJ4sI7FHvKJF8hUkMZS5Bws5lAhjWPUvsCMRSauOfxqwfFx5KAYFl9yrhPijq2G+acim2agZzWcC5MwCz2ihjvA6vJzmzoAMRNQ7YXNZZgjtUp6PgZij008p4A6OVLoAh7o6hyPG16jjqMHrXvMKVaCzhsdpBG31fAKy0h4evmMPeuLMMszGpUURQW7zXDn1XdIIxGxW4ZKtC7l7og5tmUhORNxFkYJdWTekqiciW+2mMExvEFGgFnVAg0jjVCuvwRWIAe2eSjYOdXq7Jl7fjyRw3xomLuIS4s1fQjc4cL0HRFyNTlmEfuVhezAeiDnJpKWJ+Q4IjoAlX3STNQH5wugcZxO3+ATN19KwpPwPD/sepDj4p1F7AI9NZU7GnISjxyd2Hsgo2d+8z+mx7/q5HVrFOM3UAqpqPU0c4pwhvR3yAHhVBR1DkXNlbfQMrfPrXwGUpdjAOaIVvLuFM2Gh1+xLSo+YIkHe+EZtPSc5JxKPk/FicWP9AqNNTNk32kufzAdc4AvPYIQR6ViAwHMRtGBIREjZE3aniCkHt9kzTdDKBZiPFZt8GYKv9HY060n/AG+9OBPwu9rHGErUek0QJ6QpQPayZ3tcyfqFxAKe5QkIdkq8AlzAX6TOXNKnUW8JlwVnOTohuF2dQZI/4+CsCb9UcPQQXDGcT8gvntMVPAO40QNPZ4/+/OW6eecIkxGdCK6f6SVXoUSusFfWfRo1hdGp4cCp7QP0hdMU3H9aDOtiw1/EQtdIXbWZvSU7AyHSqhhjXWbmWM21iS9GJlmKGxryZxRep8PKRbkJP1Jij98jqehWCx1tveuQUmPAW2nZlCiDqNdUTOyDEIkhulWyXXPFHRkuUI67RBJNZwCQ7PC7qpUI3CdJJhmE3NyPN8KHddipMvLhCZUuyCSdKmpyJ1sx4m+Y8NIZwk994tiulhMp/1/ReHnI4clP3GdJBgE6Vh8EkecBR4pgouTR/k0Z/jb4cYobkH5ZSi4MGzGaCfSa8MgPBrxkTgDJCfrEmYomRPx+WZkVnSvjYyZ5+M9RLqAiFOFOfNi2v+7xVhEY5MXPFjESGyIi8X2H2t4ObrTJFBVMumx/gNoAj6wGMNPWxYt6IBHe/hdAA+C7jiA0KlhfEpX4GMuxqILdrAMaGy/pR5iZl5jYhdzPBOYHActBYP07PJpq8eMMVKi7jnqVN4TydsnB2nDq1zYl4zV0UwfmTfS7Wc/eQRCInwRPTaVbUuWs/1YBihkpiOfTWKJNi+FekpnGz0yTclaQuBkNDSD+8jw6DP47hhroVylrjCGCnXaZAJuF+oon0si0MjPJh8LSg05qLTV8RudGA7FWJRj6wdj803FF6114JuJu7Zk7rkWZQyCJZGh2WM8OjyHHqNMtQ3tCdWDyfWa/ADLdanP1qFN7lWfY1fodvfwHLC5CKZxXE564UwEB59L4YVwpqVQNyHjNKgnIWMHuu/Zdmzx+nVmTW174ctdG16vMppSV4ggCBrcjsCR/LZg2rU1XCShvYzO35NV9O1jbc9bTBdeh3L3obBGTb/PdlziUdgTfWHRc0/vgUZZ2mVa0wjatoZszCgG9ZFuwH2owitjh6HpgfhnxuuIoyuCkrawahif1BfEYKJm0wIY6f/4ATOBc6myLRQqKhlfEcILRJQlAkYR52yf7El/vL97f/iWcu8O3Ra0v+b6gLfUjnDd1x+Algl5GTOmJgKPTXfv9q6u7rRgnEWiZlExa+kSKifxWFwvhS012Q77ElvoA3rRqO+7ykcxtMTBT8aqtpYiaN2PKEQwY2Q3YOcpFXDqpHe/FlJmLbzJWfbdRPfECfG0Yv2dirKo9vqAcIvgmRlMxDX7csTcP/OiUGwKNoedIm73+lREnlhTRRyvLOlr1dd73U+lUDImxuN6DJV8c5ELzL1I3NYQD33/hHwaCdOrk75Gi6WrfmbMxvHLavQGU6ZZYqiwo1YDacSnxVEk6OnECppZdLdJ9dOas7y5wqC8GV0Kugcus4iTKtx8pe1IdibvsPSKuRiB2Tx2o4jvRH6Dgk/ulgojlK0gaP4KRIzUzPZ87neRjGZnjDxc2FHUuWpx6PcQdoj1F6ahOeq4pS0fEdtbRlhXoi5TX4KIXWZIBEFY4zzisqnmPLUsK52bj3hueSbwpLmXr75h6VlgqThxt7xwzdZcpPMzMJ2G16w5x0C/gWCHIrugaikC2Z6tnUd0tpdJU+MAeSbAbxK/s85E8mMWvZPZRIIAAAOBSURBVIDHtp9VW1G64Cli81SCRwXGaLveAcpalD1XE84zq36oZG4Qn9grC16nDjeu3PF8r66O9bId7rBXwnoOX2Evq7sfmQnm8awGm2g7ccPUeZDxq4YIx93Il2qRCTrS91/US9biaPsfGHoe5nvOIHiKxA6GjjOGZCxzEYwiCyRCWnDVtZP0/G1XTQz6kcNn1rYy/Rk6tdgLW/uSfsBzrw5knoO5STi9U+zuLH98AxLePIVv8uRPateOl7K0NHerDRsHGKnn1LZcOps9r8DW4oKZH0Ik6Oht8+xzA9XygiTwSAeFCZl60x/u4CYCwOOrhyfq5pesBAs+196u415nP75oaKRxVK+coPE6n63zZ+adX1OGsdcETlJH8RhyHRRvglWD9PyrOgZhdhAUJJir8wMLo7o294t44Xmu5007XOfaA2mrYl8LJN09fTGr9iVoWoGAm6v9WEnid2H6JsJPr76U+P06WFuRQjeD98dSid0UZQ8lTGfR+4tIU4fbB5ZAfwgr4QKPYb+zC28i8Jrh8NB7YCVvQudITcQpkF+GUiJ3ZXUWFm0jzAzSYkIIpr1vxZa/OD+4PvhTUJ1WzJKafV5O73CrqYzeMFsctpLKRq26Nze/COlRFpfNm9elO+JPWa8jKePcPeylK+TR8V6dx++Cx3txHzC3l/sgFCMy38qcLa1wXk/yuSm2d+tkfhuM4CTXakb4sj07U37Sm8Nyx/ulz4tsf1yXciVrHdYPaeBfhrxNxtz7WRlV+0PmhiP1XXoeuvVu39ojC6Ud4dvkoZW7P4B0c+/Vs87xbPfvx+QlcuPSt6w0TS3LL2M3Ctqjsm+DsVXgAfK2GqkX/XOwNndC9gtoqd/h1DirJGmTpA6aDl8/fWTfQtoKtn39s5Amm0dyS9+D8LT6ZxWoGMyXrWjJTwYPJ1ee3HPzuynK74PhHbMHAxq1fXAt06p3039Df0rByrb2IwovWDwSnefR2fm3xU8ARbV07yNp3qVhbh9G9tX8u6DH7XF8kZuvNGbAio6tuHb/PwOhc15NR0g5gmG+SM7O7xRS/zHMvWSXeJKSp1yQz+p0leV2v1n8cgr0TyGPg+Uxs0uemizieWlnx9NL8W85Zj+CeRElh2Xr2NMwNbUnOPlG18w0nNpZuzwkdvhfsOo/AX1exvbaqdtqs+zhtNxUbe2sO0d1/g/olP8BXzM3bHPPpwAAAAAASUVORK5CYII=" width="151" align="right" height="151">I know that for many of you, the official language might not be your native one. Where I live, roughly half of the people are foreign-born (which is great, by the way – I like diversity). It’s fine. But please, please, do your best to write your bug report in a precise, understandable manner:</div> <ul> <li> <div align="justify">Be <strong>specific</strong> – did you load a file? Fine. Did you click on a button, select from a menu, or did you use a keyboard shortcut? It might be important. For bonus points, try all different ways to do whatever you did. If it works one way and not the other, let the developer know.</div> <li> <div align="justify">Be <strong>explicit</strong>… as in <strong>precise</strong>. Instead of the ‘it’ pronoun, describe it (‘the window’, the ‘message box’ the ‘radio button’, the ‘phone’, etc. Just not ‘it’). Use the <strong>Find</strong> command in your email client, browser, MS Word, or whatever you’re using to report the bug, search for the word ‘it’ and replace it. <br>Also, avoid ‘they’, ‘he’, or ‘she’ unless there can be absolutely no doubt about the person’s identity.</div> <li> <div align="justify"><strong>Reread what you wrote</strong> – unless you’re completely incompetent as a writer in the language in which you’re writing (and I guess it’s okay, if they hired you despite your language deficiency), you should be able to see if <em>you</em> think that you were clear. If you weren’t, please correct your grammar. And for the love of your chosen deity, please use a spellchecker. Correct those squiggly red lines!</div></li></ul> <h3 align="justify">2 – Can I please have a bug report, hold the attitude?</h3> <div align="justify"><img style="float: left; margin: 0px 10px 0px 0px; display: inline" src="http://www.troll.me/images2/grammar-correction-guy/woah-lose-the-tude.jpg" width="194" align="left" height="130">Jokes aside, we usually do not insert bugs into the system intentionally. At best it was the one defect that slipped the developers’ scrutiny. Often it is the product of being rushed to meet a tight deadline. At worst it is the result of negligent work born of the despair of either not knowing how to work properly and worse – knowing how things should be done, but not being able to do them the right way (see aforementioned deadline).</div> <div align="justify">Either the poor developer is mortified by the bug (extreme unhealthy reaction – but it happens), or the developer has become apathetic to the bug through continual disillusionment (extreme unhealthy reaction – especially for the organization that employs him or her), or anything in the middle.</div> <div align="justify">There is no point on the reaction scale at which berating or verbally abusing the developer is productive. Or even acceptable.</div> <div align="justify">So take a deep breath and stick to the facts, Mack!</div> <h3 align="justify">3 – What <em>exactly</em> seems to be the problem?</h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh08rBnazhqCiKLlhtzztk4T392t22LKWhWGEtNHvmgZmkiwMPDi3biYatcShirfNtDYdKLwHtFCfihF9nv3eMTpoFX19kZc4i5oFWOcjmakHVZ5NYHFASMX4H81JyJ_l1YSZeMEY9WnyYj/s1600-h/image%25255B3%25255D.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; float: right; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgio6OZa-Puil-W-WEHG5FcVd8FmXc8LqTZnlGw22okq9_alEyE_PXOFxrcXjt2LslSd3T5IyoKY_xyvZ1RsjLmUPkWlmSTied86cJRUb3tZlwOB1wY7_UNIP5AGblmtvwVmT6Vds84aLFu/?imgmax=800" width="240" align="right" height="153"></a>No, we don’t think that you’re making it up, that you’re dense, or that you’re bothering us with trivialities. We just want to know what kind of a bug you might be dealing with now: <br></p> <ul> <li> <div align="justify">Did you get a weird error message? </div> <li> <div align="justify">Did the application crash (i.e. suddenly shut down)? </div> <li> <div align="justify">Did the application freeze? </div> <li> <div align="justify">Does something look wrong? </div> <li> <div align="justify">Is something missing?</div></li></ul> <h3></h3> <h3>4 – Do you have any evidence?</h3> <div align="justify"><img style="float: left; margin: 0px 10px 0px 0px; display: inline" src="http://evidence.uslegal.com/files/2009/10/Evidence.jpg" width="119" align="left" height="178">Yes, for god’s sake, we believe you. We don’t think that you’re off your rocker, if you have one. We need whatever evidence you have to help us identify the problem, find its source, and resolve it. So if you have it, give it up:</div> <ul> <li> <div align="justify">Screenshot of the problem</div> <li> <div align="justify">Exact wording of the error message</div> <li> <div align="justify">Log file (if you don’t know what that is, don’t worry)</div> <li> <div align="justify">Any other kind of output?</div></li></ul> <div align="justify">Also, if you’re a <strong>tester</strong>, please come prepared – you’re working with software, our software, and you <em>know</em> it might malfunction.In fact, if it didn’t, you wouldn’t have a job, now, would you? Since that is the case, please have some kind of diagnostic tools installed to help you gather the evidence: loggers, video captures of your testing session, etc.</div> <h3>5 – Do you have any special set up or configuration?</h3> <p align="justify"><img style="float: right; margin: 0px 0px 0px 10px; display: inline" src="http://www.cce.usp.br/atendimento/faq/images/configuration.jpg" width="92" align="right" height="90">Especially if you are a developer or tester, you might have a special configuration file with specific setting that you are using. Please provide any <strong>non-sensitive</strong> configuration, or at least describe it. Anything you know about how you use the software can shorten the time it takes to fix the problem.<br></p> <h3>6 – What did you expect to happen?</h3> <div align="justify"><img style="float: left; display: inline" src="http://www.ma.hu/images/2014/08/nyil_freedigitalcooldesign.jpg" width="161" align="left" height="101">No, it’s not a cynical way of stating that that’s the way the cookie crumbles. We don’t always know what you believe the normal behavior should be. You may be right, you may be wrong. If you’re right, we need to fix it. If you’re wrong (i.e. the infamous “not a bug”, a.k.a. “by design” / “as designed”), we need to fix our documentation. So please let us know what you expect.</div> <h3>7 – What did you do before the problems started?</h3> <div align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgR7qw7jK3Uvckn_tvKfBBEA5mjwKbWLqP8GPujNb1UUInnqk3Is1jFhKET52KSntrHkIOzPot_uTEM8JMRkq0n-Q4iOEdX_WIIJYOSTLHpoJiIA2_SPA6YoGwwqawlLhgrgfc0LcoCQPkf/s1600-h/horrified%252520pup%25255B4%25255D.png"><img title="horrified pup" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; float: right; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="horrified pup" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTNoCkx7XYf4jhBYNQJJnxckxxt-JHut9uK0MLmY7rBkHw6Bx42ts51CVKv4D7gy8URN5WVxRSSSWIC112tkOy4NfI3a8wBL5fyEITu28-U8E39Nz7QpjR55wUu8Bs_hyphenhyphen-CB44kvJ-9wtg/?imgmax=800" width="151" align="right" height="148"></a>Lemme guess: You think that it is your fault. Well, it isn’t. Period. It never is. Get over yourself. Stop wallowing in self pity and shame. <strong><em>This</em></strong> is me being cynical and stating that that’s the way the cookie crumbles. Nothing but the simplest programs can ever be completely defect-free. </div> <div align="justify">What we mean to ask is “Can you please tell what steps I need to take in order to reproduce this myself”?</div> <div align="justify">So please, list the steps you took, as best you can, so that we can repeat those, as many times as necessary, until we find the problematic part of the code that needs to be fixed. It is usually something in the code that is responsible for handling the steps you took, so <strong>this information is vital!</strong></div> <div align="justify">This is where a video recording, coupled with a log file and input recording would be nice. <strong>Testers – please use those.</strong></div> <h3>8 – It works fine on my machine.</h3> <div align="justify"><img style="float: left; display: inline" src="http://cdn.meme.am/instances/53157068.jpg" width="155" align="left" height="155">Okay, this one goes out to all you developers out there. There is nothing our coworkers hate hearing from us more than this line. <strong>It is not okay</strong>. It is still your responsibility to resolve the problem. I once worked with a manager that suggested that any developer that shrugs a defect off with “it works fine on my machine”, will be shipped off to the customer with his machine, in order to solve the problem. Said customer was in another country, where summer temperatures reached over 50 degrees Celsius (122°F!). To my knowledge the threat was never actually carried out, but the developers there used the phrase less than any other team I’ve worked with.</div> <div align="justify">What we mean (at least what <em>I</em> mean), and what we <em>should</em> say is “It works fine on my machine. <strong>This means that the problem is probably related to your environment. Can you please describe the conditions in which you are running this software?</strong>”.</div> <div align="justify">So please describe your execution environment (re: what your machine is like), to the best of your knowledge. If you don’t know it, don’t sweat it – but if you are a non-technical user, and can find out this information (Wikipedia is a good enough explanation. You don’t need a PhD to understand most of it), you’ll really make your developer’s day:</div> <ul> <li> <div align="justify">What version of <strong>our software</strong> do you have? Testers – you must know this. <strong>Devs – you must make this knowledge available</strong>!</div> <li> <div align="justify">What are you running this on (smartphone, tablet, laptop, PC, server, virtual machine)?</div> <li> <div align="justify">What operating system are you on – we might not know (Windows, Linux, Mac OSX, iOS, Android, Samsung? etc.)</div> <li> <div align="justify">What <em>version</em> of the operating system do you have (Windows XP, 7, 8, 8.1, Mac OS 10.6, 10.7, 10.8, 10.9, iOS 6/7/8, Android 2.2/2.3/4.0/4.1/4.2)? </div> <li> <div align="justify">What version of Office do you have (if any)? It may be relevant.</div> <li> <div align="justify">If you know the software to be a sub-module or extension of some other software, please let us know what version of the <em>host </em>software do you have (e.g. you’re running an extension on Visual Studio – is it 2010/2012/2013? Which update?)</div> <li> <div align="justify">If this is a web application, what browser are you using? What version?</div> <li> <div align="justify">How much memory does your device have?</div> <li> <div align="justify">How much free disk space does it have? All disks / volumes, please.</div> <li> <div align="justify">Screen size?</div></li></ul> <h3>9 – Are there any specific conditions / times that this happens?</h3> <p align="justify"><img style="float: right; margin: 0px 0px 50px 10px; display: inline" src="http://metro-portal.hr/img/repository/2010/10/thumb/planeti_suncev_sustav_shutter.jpg" align="right">Sometimes a bug will consistently appear whenever the application is executed. In other cases it might be limited to happening only sporadically:<br></p> <ul> <li> <div align="justify">Does it happen every time you run it? </div> <li> <div align="justify">Only every other time? Third time? </div> <li> <div align="justify">Only mornings? </div> <li> <div align="justify">Every Sunday at 2am? This is not a joke. If I know that the nightly backup happens at that exact time, I can deduce that the two events are interacting and this causes the problem. </div> <li> <div align="justify">Does it happen only when some file is open in notepad? </div> <li> <div align="justify">Does it appear to be completely random?</div></li></ul> <h3>10 – Is this happening to anyone else, as far as you know?</h3> <div align="justify"><img style="float: left; margin: 0px 10px 0px 0px; display: inline" src="http://orandze.com/wp-content/uploads/2013/10/social-stand-out-2-300x212.jpg" width="187" align="left" height="132">This one goes especially for corporate and enterprise users, as well as testers in teams. Nobody expects Joe Six-Pack to go knocking on doors in order to figure out if he’s special or part of something bigger.</div> <div align="justify">By now, you probably know that I’m not singling you out as an idiot, or something, but rather want to understand what is happening. If this is happening to everyone on your floor (but nowhere else), it might be some network issue. If it is only you, it might be a configuration issue, but if everyone on your team who’s using Internet Explorer 10, as opposed to 8, we know that there’s a compatibility issue in the code. The developers need to be able to identifying what is common to those who have the problem, that sets them apart from those who do not have it. It’s called <strong>differential diagnosis</strong>.</div> <div align="justify">See, every bit helps. If you’re on a team, you really could go that extra mile to see if your teammates have similar issues. Especially if the software is built by the same company that you’re working for. You’re all in this together.</div> <h3>In Conclusion</h3> <p align="justify">We’re all in this together – developers, testers, operations – we usually (should) have the same interest – to make sure that we create a better product. So please – pretty please – with relish(!): be <strong>professional</strong>. </p> <blockquote> <p align="justify">Thanks in advance,<br>Assaf – a developer.</p></blockquote> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com0tag:blogger.com,1999:blog-2660291115609609354.post-67027356072814373352014-01-06T10:09:00.001+02:002014-01-06T12:43:52.940+02:0012 Revs of Software<h3><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTT25KtCJ7WtD4Uta8KPHLiPodwgmXsRY7Ylu1s7CZa2cFxXSzW_ArDdZkYadiwzqPtuklj66mSWnMnsP8j5RK816BY6h7isj8jIs8anf4oXnXMR5VDGOyflwEZLJmQvTArEk-Aiuyzqj0/s1600-h/crappy-christmas-tree%25255B12%25255D.png"><img title="Crappy Christmas Tree" style="float: right; display: inline" alt="Would you put your gifts under this?" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhyZtD4JSHvLCToYOGEgju9QidL5qyYR_WYdWnZ1rToyOy0fLQsZrR4TJDBq6z1EtUgBWL1aoe85jlRTmdWr3bCInmM3xQgQW8JoUs61UH2cgx7H4-yXgKvwwLgPMZkO3qi3m3M3hKvLrpS/?imgmax=800" width="240" height="238"></a>A Version from St. Service Bus</h3> <blockquote> <p><em><em><font face="Georgia">’Twas the week O’releasing, and all through the teams,<br></font></em></em><em><em><font face="Georgia">Not a programmer testing, at least so it seems.<br></font></em></em><font face="Georgia"><em>The builds barely holding, the crashes abound,<br></em><em><em>In hopes that some luck, or a safe place be found...</em></em></font></p></blockquote> <p>[Enter the choir. You can sing along. You know you want to…]</p> <h3>The Twelve Revs of Software</h3> <p><font face="Georgia"><strong><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh_sUD7bz45XHYxV8MVVsC76r2CF-HvIuPGuEQHh-oc1xvpFG1HMjT9tVPhs8NHWz5INCqRVfeXhAgnpiqdidhlaWILfsyn2kRbaG0YOV0FBdi_kkr_Wcb-6oG7wgENSpm658b0uVz87Tn7/s1600-h/BadSoftwareSnakeDM%25255B2%25255D.png"><img title="BadSoftwareSnakeDM" style="float: left; display: inline" alt="BadSoftwareSnakeDM" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiwtEtGLnvdGOECdwaY71j5JHfAqbAPrUyjvqdQmq3FgqIW4Xj8bOei_mUJCAAkdYKoPGEYUHkSHI06Rq3q0t2AYYQvbXZ22fTXosjpAiVVpWpMTqm9mHcfWo5xZ161hYYekXdGAYkF8xe3/?imgmax=800" width="223" height="240"></a>On the first rev of software</strong>, my dev team dropped on me<br>A piece of software that I can't release.</font> <p><font face="Georgia"><strong>On the second rev of software</strong>, my dev team dropped on me<br>Two breaking smoke tests,<br>And a piece of software that I can't release.</font> <p><font face="Georgia"><strong>On the third rev of software</strong>, my dev team dropped on me<br>Three days till deadline,<br>Two breaking smoke tests,<br>And a piece of software that I can't release. </font> <p><font face="Georgia"><strong>On the fourth rev of software</strong>, my dev team dropped on me<br>Four tests a-failing,<br>Three days till deadline,<br>Two breaking smoke tests,<br>And a piece of software that I can't release.</font> <p><font face="Georgia"><strong><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgI1srTwimNbzaKCO_CozdkSmFWJu2KdlcmDzjsqyT80te-IOnsZ1YStXkJcrNX6ktmidt9r2p7tEmudlirw46Ihp9VTq1eTqE7NaiEwtN__vuwbxQkBevRWnqES78SWRCaOl971UQ6LGw3/s1600-h/bug_report-250x250%25255B2%25255D.png"><img title="bug_report-250x250" style="float: right; display: inline" alt="bug_report-250x250" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEht5ETplo71QPK7RlA_B5efHnqkyRJESByHMuyMkIMIzkHOiTuyPzMObDwiyal9P8HTcRoUFCw5fscNq3j2_XqqNl5DTrwXxoFpSA9oCHPteIR_Fj_YDWkuBkL22q_8-Mfzi5SBkEZZC_Os/?imgmax=800" width="240" height="240"></a>On the fifth rev of software</strong>, my dev team dropped on me<br>Five bugs regressing,<br>Four tests a-failing,<br>Three days till deadline,<br>Two breaking smoke tests,<br>And a piece of software that I can't release.</font> <p><font face="Georgia"><strong>On the sixth rev of software</strong>, my dev team dropped on me<br>Six missing specs,<br>Five bugs regressing,<br>Four tests a-failing,<br>Three days till deadline,<br>Two breaking smoke tests,<br>And a piece of software that I can't release.</font> <p><font face="Georgia"><strong><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhuCDz3pBmHvIwDvwSRd2blQqEleAEJrK2L_h_moboza4P_lNg01R9zN-qI29OLv2O3z5PBJ3L_i4O_7B3jWROVDMmAIus0C58G8y-OSX5eXdD1ckLZ9dMWGQomefaYLDZ-cMomHo4XHxa5/s1600-h/angry-boss%25255B5%25255D.png"><img title="angry-boss" style="float: left; margin: 0px 0px 120px; display: inline" alt="angry-boss" align="left" src="http://lh5.ggpht.com/-HHjxjOFBtUc/Uspx82ETBuI/AAAAAAAB2L0/Mj5dLAIizv4/angry-boss_thumb%25255B1%25255D.png?imgmax=800" width="179" height="240"></a>On the seventh rev of software</strong>, my dev team dropped on me<br>Seven bosses angry,<br>Six missing specs,<br>Five bugs regressing,<br>Four tests a-failing,<br>Three days till deadline,<br>Two breaking smoke tests,<br>And a piece of software that I can't release. </font> <p><font face="Georgia"><strong>On the eighth rev of software</strong>, my dev team dropped on me<br>Eight devs on sick leave,<br>Seven bosses angry,<br>Six specs a-missing,<br>Five bugs regressing,<br>Four tests a-failing,<br>Three days till deadline,<br>Two breaking smoke tests,<br>And a piece of software that I can't release.</font> <p><font face="Georgia"><strong>On the ninth rev of software</strong>, my dev team dropped on me<br>Nine queries locking,<br>Eight devs on sick leave,<br>Seven bosses angry,<br>Six specs a-missing,<br>Five bugs regressing,<br>Four tests a-failing,<br>Three days till deadline,<br>Two breaking smoke tests,<br>And a piece of software that I can't release.</font> <p><font face="Georgia"><strong><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKhaGCFR2URVjAEKrzcxWq0TRWGIGq_a-zWEPxia1VixqMfU5LkRyxd8HV6hNkbx7eBlos2lAhwuhzVtjlJhImrScvHp0ar96_bgFnYPt4_pRZ_WVjtlPh0tHjkuwAmYLhwDDWRng3T7_7/s1600-h/clip-art-waiting%25255B2%25255D.png"><img title="clip-art-waiting" style="float: right; display: inline" alt="clip-art-waiting" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgk_-Iq_RGbS5_s3-XjmS04IXgxxUoi9h4jepSU2nh33GwqVIWoyCHsVdqIaRFY1uNmLzkeYiwLR1FkO0xj2AjYxVveUOoGSuzA4q4v98JYqXE05uZl0m4zvx-AFcUnl0Gmv96hZYoZATb5/?imgmax=800" width="240" height="216"></a>On the tenth rev of software</strong>, my dev team dropped on me<br>Ten seconds lagging,<br>Nine queries locking,<br>Eight devs on sick leave,<br>Seven bosses angry,<br>Six specs a-missing,<br>Five bugs regressing,<br>Four tests a-failing,<br>Three days till deadline,<br>Two breaking smoke tests,<br>And a piece of software that I can't release.</font> <p><font face="Georgia"><strong>On the eleventh rev of software</strong>, my dev team dropped on me<br>Eleven builds a-crashing,<br>Ten seconds lagging,<br>Nine queries locking,<br>Eight devs on sick leave,<br>Seven bosses angry,<br>Six specs a-missing,<br>Five bugs regressing,<br>Four tests a-failing,<br>Three days till deadline,<br>Two breaking smoke tests,<br>And a piece of software that I can't release.</font> <p><font face="Georgia"><strong>On the twelfth rev of software</strong>, my dev team dropped on me<br>Twelve months were wasted,<br>Eleven builds a-crashing,<br>Ten seconds lagging,<br>Nine queries locking,<br>Eight devs on sick leave,<br>Seven bosses angry,<br>Six specs a-missing,<br>Five bugs regressing,<br>Four tests a-failing,<br>Three days till deadline,<br>Two breaking smoke tests,<br><strong><em>And a piece of software that I can't release...</em></strong></font></p> <h3><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhA1-VkeKSWVTRubyAb5GYU0p2CDVfG_LWwPau41Io6y5gN0gGL1PLWdtfs_98aaNTSZCn9D2cphvEHMV3K4IwNWFfwBeNeO2DwaDBP-4UKl2Eoz3bXVIQPktoZS9jQ55WDsdwhywrUuOTy/s1600-h/Youre-Fired1%25255B2%25255D.png"><img title="Youre-Fired1" style="float: left; display: inline" alt="Youre-Fired1" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh6EUPWGpykX2HdgVvtJNml93Blx2MF_pWwmKUb10KsC_JZafzM-d4t5HRaZAmivCiy4HrXNGC31QnSVKIhw9jpputTakOo1JkMwCx1rd1E5ArzBT6UoCAc8A7vV1I7Mdvy6IrZ-i4CtE4w/?imgmax=800" width="240" height="240"></a>Final Round...</h3> <blockquote> <p><em><font face="Georgia">He sent résumés, to his team gave a whistle,<br></font></em><em><font face="Georgia">“This product is dead”, he said this Fo’shizzle.<br></font></em><font face="Georgia"><em>If you do it at all, then perhaps do it right.<br></em><em>Happy coding to all, and to all a good night!</em></font></p></blockquote> <h3> </h3> <h3> </h3> <h3> </h3> <h3> </h3> <h3> </h3> <p>A very special thank you to my good friend Maor, who reviewed, QAed and wrote the first verse of the Version of St. Service Bus. </p> <h3>P.S.</h3> <p><em>This post was supposed to go up on Monday, before Christmas Eve. Unfortunately, I, too, missed my deadline.</em></p> <p>Happy New Year.</p> <h3>P.S. 2</h3> <p><em>My New Year’s Resolution is <strong>Retina</strong>.</em></p> <div id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:91788387-b619-48e1-af09-5e847d05692a" class="wlWriterEditableSmartContent" style="float: none; padding-bottom: 0px; padding-top: 0px; padding-left: 0px; margin: 0px; display: inline; padding-right: 0px">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Build" rel="tag">Build</a>,<a href="http://technorati.com/tags/Test" rel="tag">Test</a>,<a href="http://technorati.com/tags/TDD" rel="tag">TDD</a>,<a href="http://technorati.com/tags/Release" rel="tag">Release</a>,<a href="http://technorati.com/tags/Version" rel="tag">Version</a>,<a href="http://technorati.com/tags/Software" rel="tag">Software</a>,<a href="http://technorati.com/tags/Delivery" rel="tag">Delivery</a>,<a href="http://technorati.com/tags/Revision" rel="tag">Revision</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com2tag:blogger.com,1999:blog-2660291115609609354.post-26518662087447382082013-01-06T10:34:00.001+02:002013-01-06T10:34:38.353+02:00Patterns of Testable Software<p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiqs02smDoga8P-9Zd9wBdU-h-rucS9brmqt5M1kbY8Bd-kHuQ_pqT8ObAPOkkl68YP846qkFQIDUNMMsSpMj3A4rRovH1SeWOKoNLysi-WeCj6zriop6Nok-FL4cSMYGJVx8jqI_IbQMW-/s1600-h/Patterns%252520of%252520Testable%252520Software%25255B7%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="Patterns of Testable Software" border="0" alt="Patterns of Testable Software" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhR51OvZqw1DItdQsRBe3YwHiWz5ti2kDBs0cxrmi_3TbdrJ1E344KILqyABOjFiEIVNboAkbM5PhYaeot64nP9VXrs8cZpHuZxMoNmxGV-mQkU3r-GpIFqRBWKZUQNt8I6wYDzRe17qHtX/?imgmax=800" width="240" height="201"></a>My love for test driven development started a few years ago, when I first had a taste of it while working on a product in a startup company. I started out using <a href="http://www.typemock.com/">TypeMock</a>, a really wonderful framework that allows you to isolate the code you want to test from its external dependencies, <strong><em>without</em></strong> having to change the way your code is designed. Within a few months, my team and I completed our work, met our deadline, and we were confident in the product, because we had tests to prove that it works.</p> <h3></h3> <h3 align="justify">Writing Unit Tests is Easy! Good Tests… Less so</h3> <p align="justify">Writing unit tests is easy. All you have to do is choose a single use-case of a method that you’re going to test, set up its inputs, and measure the output against some expected result. If it matches, then the test passed. If not, it fails. Rinse and repeat.</p> <h3></h3> <p align="justify">Our problems started after that. With the next version, we had to modify our code. No problem, we thought. Our code has unit tests. We can refactor without fear, because our tests will tell us if we’re breaking anything. Except it didn’t. Because of the way our software was written, and because of the way we mocked our dependencies, our tests were tied in to the <strong><em>implementation</em></strong> of the code, rather than the <em><strong>end results</strong>.</em> This meant that our tests were <strong><em>brittle</em></strong>, and <strong><em>fragile</em></strong>, because the tests broke whenever we changed our internal implementation. Our tests were starting to “<a href="http://en.wikipedia.org/wiki/The_Boy_Who_Cried_Wolf">cry wolf</a>”. We abandoned them quickly.</p> <p align="justify">As it turns out, it is not enough “just” to write tests. You actually have to write the <strong><em>production</em></strong> code in a way that is easily testable. Your code has to be written in such a way that you can verify the outcome of a method <strong><em>without depending on internal implementation details</em></strong>. As time passed, I became more and more proficient at doing this, while becoming increasingly frustrated at the difficulties that beginners have. I see many good programmers giving up early, because the tests fail them, because it is difficult to get existing (legacy) code under a good test harness, and because they keep hitting a wall with the question of <strong>“how do I test <em>this</em>?”</strong>.</p> <h3 align="justify">Patterns of Testable Software</h3> <p align="justify">I have recently begun trying to codify recurring patterns of software that is easily testable: Patterns that developers should strive to conform to, or refactor their code to. Patterns that help developers test the <strong>state</strong> of a module after running it, as well as to test the <strong>behavior</strong> of the module when running. Patterns that test the <strong>outcome</strong> without depending on <strong>implementation details</strong>.</p> <p align="justify">On Thursday, January 24th, 2013, I am going to present some of these patterns for the first time, at the <strong>Toronto ALM User Group</strong>. At the time of this writing, <strong>there are still some open spots</strong>. If you’re in the neighborhood, and are interested in <strong>Test Driven Development</strong> or writing <strong>unit tests</strong> in general, I think that you’ll find the material quite rewarding. You may register <strong>for free</strong> at <a title="http://www.meetup.com/Toronto-ALM-User-Group/events/97454932/" href="http://www.meetup.com/Toronto-ALM-User-Group/events/97454932/">http://www.meetup.com/Toronto-ALM-User-Group/events/97454932/</a></p> <p align="justify">I hope to see you there and if I do, I hope you’ll enjoy the session.</p> <p align="justify">Assaf</p> <p align="justify">P.S. Oh, and happy new year!</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:143ba305-4273-4dfd-bc36-2d659432ff9b" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/ALM" rel="tag">ALM</a>,<a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/TDD" rel="tag">TDD</a>,<a href="http://technorati.com/tags/Unit+Tests" rel="tag">Unit Tests</a>,<a href="http://technorati.com/tags/Design+Patterns" rel="tag">Design Patterns</a>,<a href="http://technorati.com/tags/Refactoring" rel="tag">Refactoring</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com0tag:blogger.com,1999:blog-2660291115609609354.post-7365352718538480992012-08-21T10:02:00.001+03:002012-08-21T10:02:57.131+03:00Windows 8 RTM is Available for Evaluation<p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhP3F3tkaksbL_eH0rXb_S332HLMAUTU-BKEFp-3GckIZ6IjIqNGBzhd_JI9DCP5iManwYtfqysYbgatsYFJORzInubcF2U7NL6iNybMVc__WC7xtyMhGc4e_MEMXZOUTAT7bLVf3K-3T2i/s1600-h/image%25255B3%25255D.png"><img title="image" style="border-top: 0px; border-right: 0px; background-image: none; border-bottom: 0px; float: right; padding-top: 0px; padding-left: 0px; border-left: 0px; display: inline; padding-right: 0px" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8k5GdXHRNyvRWp2ox5Qj7OqTy9XX9NsldvVG-Vf8cVRnvqX0_fKGmMUK6CW7_06r8ZVESngUfCrhsxFeic63LUFjPqMxfogpyRsYtUkT2fgxXMXJ6WtkWa2utsrJ2b0GB0fjt2LFXZspf/?imgmax=800" width="240" height="135"></a>If you haven’t been living under a rock, then you probably heard of Windows 8. It’s new, it’s different, it moved your cheese to a different time zone.</p> <p align="justify">And it’s freely available for a <strong>90 day evaluation</strong>!</p> <p align="justify">You can download the <strong>Enterprise </strong>edition <a href="http://msdn.microsoft.com/en-us/evalcenter/jj554510.aspx">here</a>.</p> <p align="justify">A few things to note before you try it:</p> <ul> <li> <div align="justify">This evaluation <strong>cannot be upgraded!</strong> </div></li> <li> <div align="justify">You will have to <strong>install a retail version of Windows </strong>when the <strong>trial period is over!</strong> <em>Don’t say I didn’t warn you…</em></div></li> <li> <div align="justify">To revert to a previous version of Windows (say, Win-7), you’ll have to do a <strong>clean install</strong>.</div></li></ul> <p align="justify">You may wish to try installing it on a <strong>virtual machine</strong> for evaluation. Personally, I’m partial to <a href="https://www.virtualbox.org/">Virtual Box</a>, though you can of course create one with any platform.</p> <p align="justify">I’ve already installed it. So far, so good. Everything but my Dell’s <a href="http://www.softwareandi.com/2012/04/how-to-reinstall-fingerprint-reader-on.html">fingerprint reader</a> works. <em>Grrrr….</em></p> <div align="justify"> <div id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:670eba7d-90d8-41b9-b327-aa927c891d3e" class="wlWriterEditableSmartContent" style="float: none; padding-bottom: 0px; padding-top: 0px; padding-left: 0px; margin: 0px; display: inline; padding-right: 0px">Technorati Tags: <a href="http://technorati.com/tags/Windows+8" rel="tag">Windows 8</a>,<a href="http://technorati.com/tags/fingerprint+reader" rel="tag">fingerprint reader</a>,<a href="http://technorati.com/tags/dell" rel="tag">dell</a></div></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com4tag:blogger.com,1999:blog-2660291115609609354.post-33483531198030209462012-06-09T11:33:00.001+03:002012-06-10T10:26:37.541+03:00How Does the LinkedIn Hack Affect Me?<h4 align="justify"><strong><em>June 10th Update: I added a new GUI tool, to make it easier to check your password’s hash</em></strong></h4> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhjcyGrFZkzUy34VlDZOlenFbqhQJ_FjRkFtyt1MJhw0Z_DiuR9quI0F85cHMCTrVoiACeQAA8WCwC66hXO7P6x7-Gb8nOIGyYZ-NCdNIBg8MscemFMAQdvoHerPOfHCgrS4T0SOeKq-dce/s1600-h/salted-hash-linkedin%25255B4%25255D.jpg"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="salted-hash-linkedin" border="0" alt="salted-hash-linkedin" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWXJSowtATF6DxIawvowmcX4dWFEtEhwADA4d8ufb92EZpq0uytWfAAdJ6EJmz0IjFmANiA2pc5ICjKvVAhtbBjLU6GPBUBgVALpayCyULfUh-AxXjBQvIKh2fZAflIRsQlAtAShTGkKLk/?imgmax=800" width="225" height="212"></a>If you have a LinkedIn account, you may be the owner of one of the 6.4 million accounts that have been recently <a href="http://www.guardian.co.uk/technology/2012/jun/06/linkedin-hacking">hacked</a>. You should check to be sure. If you have been hacked, your password <strong>has been forever compromised in all of your current and future accounts!</strong> In this post I will try to help you check whether or not you’re safe, explain what LinkedIn did wrong, and how and why all developers should be more careful.</p> <h3 align="justify">First Things First: Was I Hacked?</h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_eenQXTTBZOxuhMBHIWBX5U5oHzwJviUMQwRh1oujv2DGyGg4ROgB7vF010cFNzEE4RII9_nWpt7uCkipcwiJIhB1eYqs0dp6hWQahBwb79D4W8witpBQJiGJLsSqF6-RjFqYF0JmW9v0/s1600-h/hash-checker-icon%25255B4%25255D.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px 4px 0px 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top: 0px; border-right: 0px; padding-top: 0px" title="hash-checker-icon" border="0" alt="hash-checker-icon" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh9xc1LMgPz2iBxkmkZCSTshRXz1gH2TkOFj0scEIrk4tn-5dgboeX5lsIgussKyiBl7Ndxr9rX14eqlqqVQRd8M6lMlnV5O-S6o4-MEfy4Cpc7Lc-F-q1doFn3h0wlL7hkGXSf5Ln9xBep/?imgmax=800" width="83" height="83"></a>I wrote a simple command-line tool that will help you check whether you were hacked or not. What you do is enter your password, and it will check the SHA-1 hash of your password against the published list of hacked hashes, and tell you whether you’re safe or not. Don’t understand what I’m talking about? Never mind. You soon will. </p> <ul> <li> <div align="justify"><strong>Is it safe?</strong> Yes. It is an <strong>offline</strong> tool, and doesn’t connect to the internet in any way – especially not to publish your password, nor is it saved on the disk or added to the list. <strong></strong></div> <li> <div align="justify"><strong>Don’t believe me?</strong> No problem – disconnect your internet connection while using it, then delete the application from your machine, before reconnecting to the internet. </div> <li> <div align="justify"><strong>Still worried? </strong>Still no problem. I’ve published the sources. You can check what I do, and compile the checker yourself.</div></li></ul> <p align="justify">The hash-checker project is stored at <a href="http://hashchecker.codeplex.com">http://hashchecker.codeplex.com</a>. You can get both the binary and the source code there. </p> <p align="justify">The list of compromised hashes can be found <a href="https://www.dropbox.com/s/mfd4h4oylp3691a/linkedin.com.zip">here</a>. </p> <h4 align="justify">Usage:</h4> <p align="justify">To check whether you were affected by the aforementioned LinkedIn attack, download the <a href="http://hashchecker.codeplex.com/#">tool</a> and the <a href="https://www.dropbox.com/s/mfd4h4oylp3691a/linkedin.com.zip">published list of stolen hashes</a>. Make sure the text file and executable are in the same location. </p> <ol> <li> <div align="justify">Run the tool (Icon added to your desktop – you can’t miss it).</div> <li> <div align="justify">To check against the <strong>LinkedIn</strong> hacked hash list, just type your password and select the hash list file. </div> <li> <div align="justify">Optionally, you may unhide the characters, decide not to pad, or change the number of characters padded.</div> <li> <div align="justify">Press “Search”, and wait a bit. Hopefully, the result will be in green, like mine…</div></li></ol> <p align="justify">In case you’re wondering about the padding, the list has the first 5 characters zeroed so as not to expose the hashes completely. Pretty much like with credit-card hacks, they leave out the last 4-6 digits.</p> <p align="justify">Here’s a screen shot of my self-testing:</p> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg5ljgiCIUhTnIQwHUMHdZyhwwwpiNBNj3LDZfJWCAm8S58xc1FWSfxAykUMXH5k_xpKOkkiDZQF3kNKF3RSx1K-fUwUN8iQcvQZu_MHcsrMglA9phTFBm1SLoY4kAGoq_EJxddmpZPGGuz/s1600-h/image%25255B4%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiE_5rpDnkBfE_R4JUfTfQPAvNjrQRPYOJ-9CigDw96Bq5IqgTA7wwL7nIwQnHS1RD7OgJ-DclCPULjXSoMi1XgPvKjw37BUAHXHScUjNUCIrlO-wt8AuPsgJngKhbUir3buzFz2PJenn6w/?imgmax=800" width="611" height="560"></a></p> <p align="justify">I sincerely hope you’re in the clear. <strong>And that this is the entire list of compromised hashes…</strong></p> <p align="justify">Either way, take a deep breath, and move on. Time to discuss what happened.</p> <h3 align="justify">What is a Hash, and What Happened to LinkedIn?</h3> <p align="justify">Okay, here’s a crash course of password management. First, in order to authenticate users, most sites store the unique user identifier (username, email address, etc.) in a database, with <strong>some form</strong> of password. </p> <h4 align="justify">Plain Text Passwords</h4> <p align="justify"><img style="margin: 0px 7px 0px 0px; display: inline; float: left" align="left" src="http://www.ed.ac.uk/polopoly_fs/1.12812!/fileManager/password-word-clipart.jpg" width="123" height="86">The most naïve (and dangerous – <strong>never do it like that</strong>) solution is to store the password in <strong>plain-text</strong>, i.e. unencrypted. What these sites do, when you log in, is send the user-name and password (often unencrypted) over the internet, to the site, and then compare the <strong>given</strong> password with the <strong>stored</strong> one. If they’re the same, the user authenticated.</p> <p align="justify">The problem is, that if someone manages to hack into the site’s database, that person now has your credentials, and can impersonate you on the site. </p> <p align="justify">That might not seem very harmful, especially if it is not an important site, and you didn’t give it any sensitive information like your Social Security Number, or banking credentials. <strong>Unfortunately, that is not true!</strong> Statistically speaking, <strong>most users reuse their usernames and passwords</strong> in multiple sites, including ones where <strong>sensitive information is stored</strong>!</p> <p align="justify">This means that if you register with<strong> </strong><a href="http://www.someunimportantsite.com">www.someunimportantsite.com</a>, with your email address, and password 12345678<strong>, it is extremely likely</strong> that you used <strong>the same password</strong> when you registered with the email service, and with <a href="http://www.paypal.com">www.paypal.com</a>, and many other sites as well.</p> <p align="justify">Knowing this, a malicious hacker may crack <u><font color="#0000ff">someunimportantsite.com</font></u>, and with the credentials he got there, try to log in and impersonate you on <font color="#0000ff"><u>paypal.com</u></font>! Congratulations – you have now <strong>lost money</strong>!</p> <h4 align="justify">Hashes and Hashed Passwords</h4> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoD-eHHLe4mTYCorCiPLeTCwvRyQ32vYJaEHHzeQCMUa8w3EkvTm5mwNvZom4Si9S44igewkDy9bZx57Z30I15xWbmRANKeOFoDmPdD-AzMsGANtejjc8B-JOklvY855w8PPQc7RQ2CA2c/s1600-h/hero_hash-browns%25255B4%25255D.png"><img style="background-image: none; border-right-width: 0px; margin: 0px 0px 27px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="hero_hash-browns" border="0" alt="hero_hash-browns" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgz8OeRWYY5OKEEikMTleL2TCN074eNfBQ9GebjUMXMfLiNVQzekrpB0YQmkEnpMW7_u3p2H7jdHEI5lbPLiGrE0TiHgY_uy8LyRNGk1GxrYinV97kq3EcCuLdCVK84mWeSKcVDaXKgA5v0/?imgmax=800" width="115" height="106"></a>In order to protect the passwords, most sites that care about their users (and about malpractice lawsuits), will encrypt their users’ passwords in such a way that it is impossible to derive the password from them. These sites use a form of encryption that is based on a <strong>one-way encryption algorithm</strong>. Simply put, it is an algorithm that easily and deterministically transforms some plain-text input into an encrypted output, but <strong>no algorithm exists </strong>that can reverse the operation and derive the input, based on the encrypted output. This encrypted output is called a <strong>hash</strong>. Two commonly used algorithms are <strong>SHA-1 </strong>and <strong>MD-5</strong>. LinkedIn, by the way, use <strong>SHA-1</strong>.</p> <p align="justify">What these sites do, when you log in, is to encrypt your input, and compare it to the <strong>stored encrypted password</strong>. If the encrypted input matches the encrypted password, you’ve authenticated.</p> <p align="justify"><strong>Problem is, this isn’t good enough.</strong></p> <h4 align="justify">Rainbow Tables and Rainbow Attacks</h4> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhWIrZLwpDA76755hZxRtTC-isjS087aARkmMCHp2XLe2WHqIM4_vS9Yzal877FFjYDXedFyWzjkOO7i_SJNjcBUhZZAWexfIxlMfi0I8Fm0l6COyQnPkZXquvTo4fi_5lbXUgJKCAp91oz/s1600-h/image%25255B5%25255D.png"><img style="background-image: none; border-right-width: 0px; margin: 0px 7px 0px 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi-ccouckCoqcQmI77A4SsoeUvNOR_AKdhcedC-MYZxgAAKsO4pjMPf9AUcE49Gan8fW8tbRPk60myl9JGur6bZFvyxG4b7if7AuEd0Fhyaq_i9w40R_AVXnujvhsUtEdsgr7_rIDZfKbyW/?imgmax=800" width="169" height="184"></a>As previously mentioned, while it is impossible to reverse a hash, and derive a password, it is easy to generate a hash based on some input. And the same input will always generate the same hash. A hacker will use a <a href="http://en.wikipedia.org/wiki/Rainbow_table">rainbow-table</a>, a table that has known passwords and their hashes, to hack a site that stores hashed-passwords.</p> <p align="justify">What the hacker does, is take a hash, look it up in the rainbow table, and if he finds it, he looks up the password that creates it. <strong>Congratulations</strong>, you’ve now been compromised.</p> <p align="justify"><strong>This is what happened with LinkedIn. This is the danger you face.</strong></p> <h3 align="justify">What Should LinkedIn’s Developers <em>Have</em> Done?</h3> <p align="justify">I’ve got <strong>no problem</strong> with how LinkedIn dealt with the attack, <strong>after it </strong>happened<strong>. </strong>My grief is that this fiasco <strong>could have been prevented!</strong></p> <h4 align="justify">What Is a Salted Hash, and How Does it Protect Users?</h4> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEguWBCndZpdzOqmxc68MxOeaTdMHPtMIo5G18-_unLiAedAJfj5lMFSkckJGxZeOqoPmpA4V4pzFuOMjgChyGsxPiszjiCZDIgAzW-swrORE4gEvSVUb4JTE9AkIWpwVaaVVt0sHzo7Iz65/s1600-h/image%25255B12%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjDGPujy8F2Vc9pogj5GqXSayPHR1MlVfOgn9vJetiiGQALgaRfZE9iICw-aInA4IMw4SlDg9txVfnqVTiprT58tFx5t1r6RobRuPfjqaUq1SI2PE1hy7IrxtAWDsCefyFEKj3O1sNMlxHY/?imgmax=800" width="128" height="155"></a>The problem is that many people reuse passwords, and that many passwords are commonly used by different people: 12345, 1qaz!QAZ, <strong>any word in the dictionary</strong>, “p@ssw0rd”<strong>,</strong> and <a href="http://http://en.wikipedia.org/wiki/Leet">1337</a>-speak (you pseudo-hacker-cool-boys know who you are). They all appear in every respectable rainbow table.</p> <p align="justify">If a site’s developer would add some random and unique characters to the password, the resulting hash would be <strong>vastly different</strong> from the hash of the same unsalted password. It would be <strong>vastly different</strong> from the same password <strong>hashed with a different salt</strong>.</p> <p align="justify">In short, a salted hash defeats rainbow attacks, because the uniquely salted hash would <strong>never</strong> appear in it, and <strong>no two users</strong> would have the <strong>same hash</strong>, and <strong>no</strong> <strong>user</strong> would have the same hash in<strong> two different sites</strong>.</p> <p align="justify">The great thing is that since the <strong>salt cannot be separated from the salted password</strong>, the salt doesn’t need to be secret! The site can <strong>safely store the salt alongside the salted hash</strong>, without fearing for the security.</p> <p align="justify">I repeat – all the site’s developers need to do is create a salt (256 bits of random bytes will suffice) and then hash the password concatenated with the salt:</p> <blockquote> <p align="justify"><strong><font face="Courier New">saltedHash = Algorithm.ComputeHash(password+randomBytes);</font></strong> </p></blockquote> <p align="justify">Finally, save the salted hash and the salt in the same record in the database.</p> <p align="justify"><strong>That is what LinkedIn should have done!</strong></p> <h3>What Can <em>You </em>Do?</h3> <p align="justify">Unfortunately, beyond writing your congressman, brow-beating your site’s developers, and boycotting unsafe sites, you can’t do anything about how the passwords are saved. You probably won’t even know how they manage your password until something bad happens and it gets published.</p> <p align="justify">You can, however make sure not to use commonly used passwords, and not make sure that your accounts in sensitive sites have <strong>unique, strong passwords, that you don’t reuse</strong>.</p> <p align="justify">A<strong> password manager</strong> tool (I paid for, and love <a href="http://www.roboform.com">AI RoboForm</a>) can help you keep passwords without having to remember them, and can generate strong random passwords for you.</p> <p align="justify">If this seems like too much work, use<strong> levels of security</strong> – have one password for unimportant sites, and another safer one for important sites, and a <strong>unique one for each extremely sensitive or money-related site</strong> (email service, bank, PayPal, etc.).</p> <p align="justify">I hope this helped clear out the air around LinkedIn, hashes, salts, and your own safety.</p> <p align="justify">Assaf.</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:7f61e532-d8ba-4a87-bf48-5b50af8ccc6b" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/How+To" rel="tag">How To</a>,<a href="http://technorati.com/tags/Security" rel="tag">Security</a>,<a href="http://technorati.com/tags/Password" rel="tag">Password</a>,<a href="http://technorati.com/tags/Hash" rel="tag">Hash</a>,<a href="http://technorati.com/tags/Salt" rel="tag">Salt</a>,<a href="http://technorati.com/tags/LinkedIn" rel="tag">LinkedIn</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com3tag:blogger.com,1999:blog-2660291115609609354.post-8929533392611683172012-05-08T20:39:00.001+03:002012-05-08T20:39:36.726+03:00One Team’s First Sprint Planning Session<p align="justify"><img style="background-image: none; border-right-width: 0px; margin: 0px 0px 0px 7px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" border="0" align="right" src="http://i.pbase.com/u25/jetsynth/large/40697876.OnYourMark.jpg" width="231" height="228">This post is a bit different than my usual ones. Instead of orating off of my soapbox, I’d like to share a moment of <strong>agile bliss </strong>that I had today. One of the teams I work with at my customer’s company conducted their first “<strong>truly agile</strong>” sprint planning session. This post is a recount of the experience.</p> <h3>What Came Before</h3> <p align="justify">About a month ago, I began working on agile methodology training for a few teams at my client. The focus of the training was team work-process, mostly using Scrum as a template for how we will do things, with a few <a href="http://www.crisp.se/kanban">Kanban</a> inspired overrides. In my first few sessions, I focused on what a user story is, what a task is, and the concept of focusing the team’s energy on completing user stories as fast as possible.</p> <p align="justify">What I taught them boiled down to a few key take-away points:</p> <ul> <li> <div align="justify">A <strong>user story</strong> is an <strong>independent</strong> increment in functionality that is <strong>valuable to a stakeholder</strong>, that can be completed <strong>by the team</strong> in <strong>one sprint</strong></div> <li> <div align="justify">A <strong>task</strong> is <strong>one developer’s day</strong> of work, on <strong>one component</strong> of the system that is <strong>affected by its user story</strong>, or work that needs to be done to meet the team’s <strong>quality standards</strong>.</div> <li> <div align="justify">Each team member <strong>pulls an unassigned task</strong> from the <strong>most important</strong>, <strong>unfinished user story</strong></div></li></ul> <p align="justify">Initially there were arguments on all points: “<strong>Our stories are too big for one sprint</strong>”, “<strong>What if a task takes more or less than a day</strong>?”, “It’s <strong>easier to assign a story to a developer</strong>”. I had to convince them that these basic ideas are <strong>important and valuable</strong>, or at least to <strong>give them a try</strong>.</p> <h4></h4> <h4 align="justify">The Man’s Too Big…</h4> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjEnl9q5fESVIdmklrNPYXp8ro1HzvW5hEDVTNXXEnK6UnCPwJ1qpcRKX_wnbnbS37Yt_gXYftsgcLOY0vBgWDFjheNEySV1rirE8uguYOIR2NPIwCH5WzCWck0LmgOwyF6p0A4w7_uJhRp/s1600-h/image%25255B3%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjCR9MczwdGBoj6foTQmQOMq_4BfcsF_SsomiHw1VojyxsWeiNXzT7zL9mkIlfkfJ1UT40JRCkwf9-uMkaarSqPRZBvFsOUMsWLqfPlMzAFSFEO8L63-R6lInkWcKH8g-TWL057jcAztY-_/?imgmax=800" width="240" height="145"></a>What we did was take one “too big” user story, and look for some way to break them down in to thinner vertical slices. We ended up with stories that use <strong>naïve implementations</strong>, or serve a <strong>smaller set of clients</strong>, or handle a <strong>smaller set of scenarios</strong>, with further stories that <strong>cover the difference</strong> in robustness, clients and scenarios.</p> <p align="justify">With regard to the tasks, I suggested that we simply split tasks that feel too big, or join tasks that feel to small, and not to worry about their actual length. We’ll measure the <strong>averages </strong>and <strong>variance </strong>after the end of the sprint, and look for better ways to be more predictable as needed. It was more of a let’s simply try it solution.</p> <h4 align="justify">The Man’s Too Strong!</h4> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjxtcNTeWwu3TIAL3UXok_SBZxt_ewwc0Qp80lpXfApyl_-kHUVCWDSaoVu9_HsXZaGNoplsoNTCY14_G0iO5marIYoRNxozZmfeKl5pHD5oIQqVqlmo_XKLk0kRnwDffhP79XjFCouHhwy/s1600-h/image%25255B7%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgiJeGCb8l3_5q2TLmwjqVv8MlINanG7FFqRTSo8BQl_OSDm3nq34878OCanFttWRGQKXIQXPcLHAXVQEwdai74N9ge2mIfjNsurjzkToAYM1NWa0o3upIduqB1ytkTwtM_GuK5piIayp7L/?imgmax=800" width="225" height="202"></a>The longest argument was over whether the first story warranted having multiple developers swarm on the tasks until the story is complete. One developer felt most strongly that it’s a <strong>waste of time</strong> to have <strong>multiple people learn the story</strong>, since we’re certain to complete it in time either way. Another developer didn’t want to be pegged in just the server (or client) coding tasks of each story, and felt that owning a whole story gave her <strong>more satisfaction</strong>. She also expressed concern over the pain of <strong>complex merges</strong>. Incidentally, it was mostly the QA engineers that immediately accepted the value of working on one story’s tasks in parallel.</p> <p align="justify">Here are the points I made to alleviate their concerns:</p> <ul> <li> <div align="justify">Having multiple developers learn a story is a great benefit, as it will <strong>allow flexibility in task assignment</strong> now, and further down the line in future sprints that <strong>may have related stories</strong></div> <li> <div align="justify">Having more people understand the story will <strong>eliminate bottlenecks</strong> (and increases the team’s <a href="http://en.wikipedia.org/wiki/Bus_factor">bus factor</a> – a good thing) </div> <li> <div align="justify">Regarding the perceived focusing on one component, <strong>some other team member</strong> chimed in, suggesting that nothing would stop her from taking a client-side task in one story, and a server-related one in the next. I was really happy that other members joined the discussion; it was no longer a teacher-class relationship, but a <strong>team of peers</strong></div> <li> <div align="justify">I also reminded the team, that since we define a task as the work on <strong>one component</strong> for a day, and since we focus on completing <strong>one story</strong> before moving to the next, we are actually reducing the chance of two developers having to manipulate the same object at the same time – which of course <strong>reduces the merge conflicts</strong>! Further effort can be made to remove the rest of the edge cases almost entirely</div> <li> <div align="justify">I further mentioned that there will be at least two members working on each story in any case: one coder, one tester.</div></li></ul> <h3 align="justify">Planning the Sprint</h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjX3rcIZ2Jbg5VwTTRhScPqZr7CgGqD7psZrQSmpSZGMuojbiWXr1Dr7j2KQ224HdtU0xeGZubidUmoY1Lxz0J-tzZsONlGxV1fw0ytYPd_SAcw-CQa2EQILZYow7G_aTLB3LQ1ED1Agu8o/s1600-h/image%25255B11%25255D.png"><img style="background-image: none; border-right-width: 0px; margin: 0px 6px 0px 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPlXsM8cNV8wrfIJWDjP5qCTCePRMHj2wkmbjGKThS6Ih_Bnk_Dth99nMVgSFyrtLn87g5LW7Mr_qzS8pMMOA27wEjOOQsDyxZhyphenhyphen2Wz7PHUYTucrM46D92Jvxv0Mi5O2kvP1m_-SU5OR4q/?imgmax=800" width="182" height="196"></a>The rest went by rather smoothly. The team <strong>calculated how many expected work days</strong> they have in the sprint. I suggested that we simply add them up, rather than trying to split along the lines of coder / tester days & tasks.</p> <p align="justify">I noticed that the backlog had some <strong>free-floating tasks</strong>, i.e. not related to any user story. I asked the team about those, stating that unless there is some value to a stakeholder, the <strong>task may be a waste of time</strong>. The team told me that it was <a href="http://www.softwareandi.com/2011/12/how-to-measure-technical-debt.html">technical debt</a>. After some discussion, <strong>we agreed</strong> to <strong>deduct the tasks</strong> from the available work days, rather than creating <strong>fake user stories</strong> – we have to own up to the fact that we are <strong>paying back a debt to the system</strong>, not adding value to it.</p> <p align="justify">The team-leader-turned-part-time-<strong>product-owner</strong> gave a <strong>rough stack ranking</strong> (there were several items high on the list with the same rank). I suggested that if he doesn’t care which of the same-rank stories we complete first, I’ll set an internal rank by the order that they appeared in the spreadsheet. He accepted.</p> <p align="justify">Next we started explaining and breaking the stories. Traditionally, the PO explains the stories in the planning session’s first half, and the team breaks them down in the second. Since the <strong>PO in this case is a team member</strong>, and fully savvy of the product and solution, I suggested that we simply run down the list <strong>until we have as many tasks as we have work days</strong> (see how that works out?).</p> <p align="justify">The first story was easy. We created 4 coding tasks and 2 quality related tasks.</p> <h4 align="justify">Break it Down!</h4> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjXkIIQyPsb3CWfII4aJnp3hhom3R6lQ1lMcsgi1i1PgxSMglLpg_OH21ftL3fVn7g_-ASmQ9x6a0negSJLxmLnFdICfhbbPmgYETrPckESNbXo_hTZuWYm14-38yAf1wFFHOKHfDnWb2xo/s1600-h/image%25255B17%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgSXbkcHPLy8EikPn2cFRx8C8S_uHU2KxJZhUOM07hQ-0PYBwIsAPMiFET4j39WMEMZxefzPPY33qPI_8Xy1pp_VOC449i0zyugTxkBGz3kWI0gj0ouYn7WzcyS_tAA0uyhxgSdyYFTNRrS/?imgmax=800" width="143" height="146"></a>The second story was a whopper. We knew it would take most of the sprint. One developer suggested that we <strong>split the story by data source</strong> – one part retrieving one source’s data, the other part retrieving the second source. the team leader shook his head. “The <strong>customer needs both</strong>”, he said. There is <strong>no value in supplying just one</strong>. We’ll split it some other way, if we have to”.</p> <p align="justify">You couldn’t erase the smile from my face with truckload of erasers. I knew for sure that<strong> he got the idea of what a user story is</strong>!</p> <p align="justify">With the second, larger, story, the team leader frowned and looked at the task list. “This doesn’t feel right” he said. When asked what the problem was, he said <strong>that one task is too big</strong> – it will take longer than a day. The team then split it in two parts, and added a third task.</p> <p align="justify">And we were <strong>done estimating and committing</strong>. Just like that.</p> <p align="justify">All in all, we spent about an hour of planning, <strong>2-3 minutes</strong> of which were<strong> spent “estimating”</strong>, which is to say deciding how to split that “too big” task.</p> <h4 align="justify">An Agile Manager in a Brave New World</h4> <p align="justify"><img style="background-image: none; border-right-width: 0px; margin: 0px 5px 0px 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" border="0" align="left" src="http://img.ehowcdn.com/article-new/ehow/images/a07/76/nq/do-manager-scrum-800x800.jpg" width="135" height="102">At the end of the meeting, the team leader expressed his regrets that we don’t have a <strong>full-time</strong> technical-product-manager (TPM) which is the closest role they have to a Product Owner. The group manager, who was present for the Sprint Planning <strong>picked up the impediment</strong> and answered “Let’s take it offline; I’ll try to get one to join the team ASAP”. </p> <p align="justify">Yes sir! The manager became the <strong>Scrum Master’s Scrum Master</strong>, as per my suggestion in my <a href="http://www.softwareandi.com/2012/04/how-to-manage-self-managing-team.html">previous post</a>.</p> <h4 align="justify">Here’s What We <em>Didn’t </em>Do</h4> <p align="justify">There are several things the team didn’t do:</p> <ul> <li> <div align="justify">Defining <strong>proper user stories</strong> – I didn’t bother following the ceremony of form with the stories, declaring the reasoning and the interested party. I ignored this because I wanted to <strong>avoid too much change-shock</strong> at once. Next sprint we’ll focus on that. For now, I felt that understanding the <strong>concept of value was more</strong> – well – <strong>valuable</strong></div> <li> <div align="justify">Estimate the effort involved in the stories. Personally? I hate estimations. I think they’re <strong>useless</strong>, most of the time. I noticed that <strong>most of the time</strong> spent in a sprint planning session is wasted on planning poker, story points and ideal hours, and in the end – they <strong>don’t help the project’s predictability</strong> in any noticeable way. Instead, we’ll<strong> measure</strong>, and seek a <strong>low-variance way to split the tasks</strong>. That will be better. and <strong>cheaper</strong></div></li></ul> <h3 align="justify">In the End</h3> <p align="justify">All in all, it was a great first “agile day” for the team. It was <strong>fast</strong>, to the point, and <strong>everybody participated</strong> in every part of the session. Tomorrow I will work with them on building their Scrum-board, and walk them through their first “real” daily meeting. I can’t wait!</p> <p align="justify">So, what do you think? Want to hear more such experiences? Is there anything I did that you like? Something I could have done better? Please drop a comment. Don’t be a stranger!</p> <blockquote> <p align="justify"><em>P.S. A special thank you goes to <a href="http://www.markknopfler.com">Mark Knopfler</a>, lead vocals and guitar legend from the <a href="http://en.wikipedia.org/wiki/Dire_Straits">Dire Straits</a>, for inspiring the titles of two sections, in his wonderful <a href="http://www.youtube.com/watch?v=AVdB-UKfxD4">song</a>.</em></p></blockquote> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:f465008c-be84-4d30-8784-3604f8d88a6e" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/Sprint+Planning" rel="tag">Sprint Planning</a>,<a href="http://technorati.com/tags/Estimation" rel="tag">Estimation</a>,<a href="http://technorati.com/tags/User+Story" rel="tag">User Story</a>,<a href="http://technorati.com/tags/Task" rel="tag">Task</a>,<a href="http://technorati.com/tags/How+To" rel="tag">How To</a>,<a href="http://technorati.com/tags/Team" rel="tag">Team</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com1tag:blogger.com,1999:blog-2660291115609609354.post-67978253834160793332012-04-28T18:26:00.001+03:002012-05-06T08:09:30.857+03:00How to Manage a Self-Managing Team?<div align="justify">
<a href="http://lh5.ggpht.com/--HMYRUR46eQ/T6JaMRvN4uI/AAAAAAAAAnA/USVRLfe4CfE/s1600-h/image%25255B3%25255D.png"><img align="right" alt="image" border="0" height="178" src="http://lh4.ggpht.com/-XQstp_D70-o/T6JaNTLICcI/AAAAAAAAAnE/2MQw5TK4RP4/image_thumb%25255B1%25255D.png?imgmax=800" style="background-image: none; border-bottom: 0px; border-left: 0px; border-right: 0px; border-top: 0px; display: inline; float: right; padding-left: 0px; padding-right: 0px; padding-top: 0px;" title="image" width="240" /></a>As we all know, there’s no shortage in <strong>confusing </strong>and counter-intuitive ideas and practices in the Agile world, but the idea of a <strong>self-managing</strong> team has to be one of the best. Indeed, the idea that a manager can manage a self-managing team sounds <strong>oxymoronic</strong> at best, and at worst – plain moronic. In this post I will try to clear the air and explain what it means for a team to be <em>self-managing</em>, and what is the role of a manager of such a team.</div>
<div align="justify">
By the way, this post is the fourth in my series of <a href="http://www.softwareandi.com/2012/01/demystifying-agile.html"><em>Demystifying Agile</em></a>. If you like this one, you may want to read the others.</div>
<h3 align="justify">
What Does It Mean to Self-Manage?</h3>
<div align="justify">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiSWS-8hJcd9tLcjFa16RJJYenqEvdZRi7KbC3EQKZgx52APhtw9VI_eUGlpdxtVd8PsP0DCUjV-mneNjNAceERIvcr9vNaHz8s4ERlZ4AindXrroVccnW1TDB6kNS3Tr5v751t9oh2y9I7/s1600-h/image%25255B15%25255D.png"><img align="left" alt="image" border="0" height="204" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiaOlh70WSjp7dSKhZ2jI9NTUidD-9tO3aKc3rzSHTBXfHSXiFTagKSVtJWT1hsmTY1dbTwyUuNqAReN92yyMvF_DWUwUC-uf7On3uVttmMQLTRIPOEwNM_wsR_2ae0heYryaF2nXe-eA5m/?imgmax=800" style="background-image: none; border-bottom: 0px; border-left: 0px; border-right: 0px; border-top: 0px; display: inline; float: left; padding-left: 0px; padding-right: 0px; padding-top: 0px;" title="image" width="240" /></a>A self managing team, or as it is sometimes also called, a <strong>self-organizing</strong> team, is, above all, a <strong>mature</strong> team. It doesn’t even have follow the percepts of any agile methodology per se, but in fact most do. Probably something to do with maturity.</div>
<div align="justify">
The first thing such a team does is to take charge of <strong>how</strong> they do their work, which is to say, they define the tasks they will have to complete in order to deliver the solution (requirement / user story / feature).</div>
<div align="justify">
They will also be in charge of estimating the cost of their work, decide what work they can complete until the next milestone (or iteration, or sprint), and commit to it.</div>
<div align="justify">
They will take control over their <strong>development process</strong> and the responsibility of improving it in order to develop a better product, while reducing the cost, as much as they can.</div>
<div align="justify">
They will (to some extent) be in charge of identifying anything that may impede their progress, any issue that may stop them from completing a task or meeting a deadline, and either resolve what they can, or report to their superiors what is beyond them to solve.</div>
<div align="justify">
Depending on whether or not the <strong>Product Owner</strong> is considered <strong>part of the team</strong>, they will define <strong>what </strong>needs to be done: user stories and priorities.</div>
<div align="justify">
In short, one must merely <strong>point them at a goal</strong>, and they will do everything needed to <strong>achieve it</strong>!</div>
<h3 align="justify">
So What Do I need a Manager for?</h3>
<div align="justify">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg4al8eEpugQDsXomKVGffv2l8NVt6Kq36oL6ppVaH54vh8vMsIRyaejSthMUL54FZXAarGJFZWp_jb8F6-6R1-Xpn07r4sVNQPKNwcjicYL-fYxvp5Hz2ZZFTZXnEAh0ZCxgNr5Y9f2PAA/s1600-h/image%25255B19%25255D.png"><img align="right" alt="image" border="0" height="192" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjNHC4adIYEnGjMhEem7aIVJGQoSV2X3defPnqP04tI3cqA8s6PlK0d13vJKkwVWioXMePCBgy6fd8bQ5VYm5OXa9peBnkyUAExAntOJrqUgYuHMHeoj-bd5R2llqLAoEXYZERYzL5uw8FZ/?imgmax=800" style="background-image: none; border-bottom: 0px; border-left: 0px; border-right: 0px; border-top: 0px; display: inline; float: right; padding-left: 0px; padding-right: 0px; padding-top: 0px;" title="image" width="205" /></a>As a manager, you may worry that you have become obsolete. Indeed, all but <strong>one manager</strong> I’ve worked with, has expressed some form of anxiety over this change and subconsciously hindered my efforts to help the team become self-managing. Incidentally, that one manager simply asked me to <strong>tell him what his new role would be </strong>in this new agile world. All I had to do was convince him that it will work (if you’re reading this, and you know who you are – thanks for making my job enjoyable!)</div>
<div align="justify">
At any rate, you are <strong>not obsolete </strong>– in fact, you are needed more than ever; Your team(s) need you to do those things that nobody else can do:</div>
<div align="justify">
First off, there’s the whole matter of<strong> human resources </strong>and <strong>financing </strong>(some might say it is the same). No agile methodology that I know of, suggests that the team is responsible for the following:</div>
<ul>
<li> <div align="justify">
<strong>Hiring </strong>new employees</div>
</li>
<li> <div align="justify">
Negotiating <strong>compensation</strong> and benefits</div>
</li>
<li> <div align="justify">
<strong>Purchasing </strong>equipment, software and other tools</div>
</li>
<li> <div align="justify">
Authorizing <strong>personal absences </strong><em>(see below however)</em></div>
</li>
<li>Anything else that is not directly related to the <strong>team’s work</strong></li>
<li>Yes - <b>Firing</b> a team member that cannot or <i>will</i> not do his job properly</li>
</ul>
<br />
<ul>
</ul>
<div align="justify">
Regarding the matter of personal absences, a mature team <em>could</em> handle the matter of absences by themselves, accounting for planned absences when planning the iteration, and dealing with the consequences when they are unforeseen. The absences would still be accounted and authorized within what was agreed in the compensation package, but the manager might be relieved of having to deal with the day-to-day issues.</div>
<div align="justify">
What else? In a traditional hierarchy, a manager is in charge of team leaders, who in turn are in charge of the team. In an agile world, the team leader is often replaced by the <strong>Scrum Master</strong> (or Agile Coach), who <strong><em>serves</em></strong> the team by removing impediments from its path.</div>
<div align="justify">
An agile manager could serve as the <strong>Scrum Master of Scrum Masters</strong>. A scrum master who encounters an impediment that he cannot resolve, needs someone to turn to. Enter the <strong>Agile Manager</strong>, the <strong><em>servant leader</em></strong> for the teams. With the backing of his position the manager can do more to resolve the issues than the scrum masters might do on their own.</div>
<h3 align="justify">
All This Sounds Great, But How Do I Get There?</h3>
<div align="justify">
<img align="left" border="0" height="137" src="http://banmilleronbusiness.com/files/overworked.jpg" style="background-image: none; border-bottom: 0px; border-left: 0px; border-right: 0px; border-top: 0px; display: inline; float: left; padding-left: 0px; padding-right: 0px; padding-top: 0px;" width="209" />All of this may sound great in theory, but you know your team; they are simply <strong>not ready</strong> for <strong>all this responsibility</strong>. So you may wish to “thank” me for wasting your time, right?</div>
<div align="justify">
<strong>Wrong.</strong></div>
<div align="justify">
Look back at the list of things that the self managing team does. Now back at your tasks. Now back at the team’s. Looks familiar? They are – or <em>were</em> – your tasks. Now look at it again. It’s <em>their</em> tasks, only you were handling their work <em>for them</em>!</div>
<div align="justify">
Work with the team, relinquish these tasks, one by one, suggest that they take over them. This can (should) be part of their <em>Kaizen</em>, their <strong>continuous improvement</strong>.</div>
<div align="justify">
Sooner or later – sooner, actually – you will find yourself the proud agile manager of self managing teams! </div>
<div align="justify">
Now you will finally have the time to do all of those things that you never had the time to do.</div>
<h3 align="justify">
Summary</h3>
<div align="justify">
The Agile Manager is the <strong>financer </strong>and <strong>builder </strong>of the self-managing teams he is in charge of. The agile manager is also the <strong>scrum master of scrum masters</strong> and solves the issues that they cannot resolve on their own. </div>
<div align="justify">
The path to self management is not a short one, but not a very difficult one. You can get there, one step at a time.</div>
<div align="justify">
Try it, I believe that you will find it rewarding and liberating.</div>
<div align="justify">
If you have any experience managing self managing teams, why don’t you leave a comment with a pearl of wisdom of your own? Be a sport.</div>
<div class="wlWriterEditableSmartContent" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:f4a52e35-a10d-42f3-a964-688eb9af1663" style="display: inline; float: none; margin: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/Team" rel="tag">Team</a>,<a href="http://technorati.com/tags/Self+Management" rel="tag">Self Management</a>,<a href="http://technorati.com/tags/How+To" rel="tag">How To</a></div>Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com2tag:blogger.com,1999:blog-2660291115609609354.post-62356217120182821242012-04-19T20:22:00.001+03:002012-04-19T20:22:08.478+03:00How to Reinstall the Fingerprint Reader on a Dell Laptop<p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEii7nVTqKWCp-Yc9lqXe8p44q0llcDeF-JFy4qc6VptT7b8bmfaLJ1nLHKhw1l1KnbfXdXyeykiT1CGex82n4o7cq2jbYWC9MrEKNQLM-VLkGRLLagaM0jkIxqpd68F6SQDOau2DNlhTL1n/s1600-h/dell-fp%25255B3%25255D.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px 0px 0px 6px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="dell-fp" border="0" alt="dell-fp" align="right" src="http://lh4.ggpht.com/-vLQXX1aXhmY/T5BJvpkJVaI/AAAAAAAAAlw/byKUTvOD7iI/dell-fp_thumb%25255B1%25255D.jpg?imgmax=800" width="240" height="239"></a>I love my Dell Mobile Workstation. It’s a <a href="http://www.dell.com/us/enterprise/p/precision-m6600/pd">Precision M6600</a>. Yeah. The big one. With (almost all) the works (no touch screen or SSD drive). Recently I reformatted it. I don’t mind, really, I was thinking of doing so anyway. A digital spring cleaning if you will. Spring cleaning and Decrapification.</p> <h3 align="justify">The Story of My Woes</h3> <p align="justify">It took me about an hour or so to get Windows 7 up and running, and (most of) the drivers working. Just extracted the big giant drivers’ CAB for my machine, and pointed every unknown driver in the device manager at the root folder, and got it all up and running.</p> <p align="justify">All but the finger print reader.</p> <p align="justify">I couldn’t get it to work. There was no unidentified driver left, but there was no biometric device defined either.</p> <p align="justify">Dell’s support site was no help either; I went through the site, having entered my Service Code, and got a list of drivers and applications for my machine. Nothing there pointed me in the right direction.</p> <p align="justify">After a day or so, I found the finger print reader app from <a href="http://www.authentec.com">Authentec</a>, and tried to get it to work, but I couldn’t. While I got Windows to identify my finger print reader module, and it read my fingers, I couldn’t get it to “enroll” my finger prints.</p> <p align="justify">And for some reason the interface really didn’t look familiar.</p> <p align="justify">Took another day scouring the web, looking for a solution. I started worrying that I somehow damaged my device. And that really drove me nuts. I love using the FP reader to authenticate.</p> <p align="justify">And then I found -</p> <h3>The Solution</h3> <p align="justify"><em><strong>Important note:</strong> This download is for the Dell Precision M-series Mobile Workstations for <strong>64 bit Windows</strong>. Before installing any driver, firmware or application, verify that your machine make is supported!</em></p> <p align="justify">In the end, no single blog had the solution for me. I had to mix parts of this and that, but here is the result:</p> <ol> <li> <div align="justify">If you’ve already futzed with the FP reader, uninstall <a href="http://www.dell.com/support/drivers/us/en/04/DriverDetails/DriverFileFormats?c=us&l=en&s=bsd&cs=04&DriverId=R214858">ControlVault</a> and and Finger Print related software</div></li> <li> <div align="justify">Install the Dell Data Protection | Access -- <strong>Driver </strong>Package. You can get it <a href="http://www.dell.com/support/drivers/us/en/19/DriverDetails/DriverFileFormats?DriverId=R308498">here</a>.</div></li> <li> <div align="justify">Install the Dell Data Protection | Access -- <strong>Middleware</strong> Package. You can get it <a href="http://www.dell.com/support/drivers/us/en/04/DriverDetails/DriverFileFormats?c=us&l=en&s=bsd&cs=04&DriverId=R291064">here</a>.</div></li> <li> <div align="justify">Install the <strong>Dell ControlVault Windows Biometric Framework Integrated</strong>. You can get it <a href="http://www.dell.com/support/drivers/us/en/19/DriverDetails/DriverFileFormats?DriverId=R308326&FileId=2731119600&productCode=precision-m6600&urlProductCode=False">here</a>.</div></li> <li> <div align="justify">Install the Dell Data Protection | Access – <strong>Application </strong>Package. You can get it <a href="http://www.dell.com/support/drivers/us/en/04/DriverDetails?DriverId=74YRR&FileId=2938744107&DriverName=Dell%20Data%20Protection%20%7C%20Access%20--%20Application%20Package%2C%20v.2.1.00001.002%2C%20A02&urlProductCode=False">here</a>.</div></li></ol> <p align="justify">You will be told to restart once or twice. <strong>Make sure you do so! It’s important</strong>.</p> <p align="justify">That’s all there is to it. Unfortunately, these apps did <strong>not</strong> appear in my list of suggested apps. The installation instructions on Dell’s <a href="http://support.dell.com">support site</a> are misleading.</p> <p align="justify">I hope you have an easier time of it than I had.</p> <p align="justify">Assaf</p> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com17tag:blogger.com,1999:blog-2660291115609609354.post-57883324559352065152012-03-09T18:03:00.001+02:002012-03-18T14:32:12.374+02:00Why Should I INVEST in User Stories?<p align="justify"><img style="background-image: none; border-right-width: 0px; margin: 0px 0px 0px 4px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" border="0" align="right" src="http://www.ewopproductions.com/uploads/2/4/1/8/2418939/4299741.jpg?462" width="192" height="144"><strong>INVEST</strong> is a another great acronym from the Computer Sciences industry, Department of Agile (yes, <strong>DOA</strong>, and I’m well aware – thank you very much); It stands for <em>Independent, Negotiable, Valuable, Estimable, Sized</em> (or <em>Small</em>), and <em>Testable</em>. Those are indeed valuable attributes of User Stories, of <em>any</em> kind of requirements at all, and the acronym itself implies some effort on behalf of the creator of user stories (i.e. the Product Owner), with a potential return on investment.</p> <p align="justify">But that isn’t good enough. A catchy name may be enough for most developers to try something new (seriously, when does a developer <em>ever</em> need a reason to try something new?), but not so for management. To many managers, however, this can sound like <em><strong>Impossible</strong>, <strong>Not</strong>-gonna-deliver, <strong>Vague</strong>, <strong>Everything</strong>-is, <strong>So</strong>-what, </em>and <em><strong>Test</strong>-the-whole-goddamn-project</em>!</p> <p align="justify">In this post, inspired by a twitter-conversation I had a while ago, I hope to explain what this INVESTing in user stories <strong>really means</strong>, and why it is worth doing.</p> <h3></h3> <h3>I is for <em>INDEPENDENT</em></h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjKhTMNuKCZ6HkRQnEKDSazVJCE43mtrsj7_Cppah9RC41oa42kiLwziFq9dbH-S-p2FAbHngwmdgtv5ozh0StL9pB6NAOjVvxH2FD876ED3zOH5_ZPyvwXDWjq-uDgBjFYgHBHrX6AS-Vc/s1600-h/image%25255B3%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px 6px 0px 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimYliQroAbuISCTARvwW6cTdGJCE4nqXR1bZe-AHj5Z5VvjGXelnqaZLvlqD9HXAghEywOz33u8Zu_sbz1-nQ8src1KHrqjelzRSUak1fJ2hXjZo1IPFQR2dDkHbh_MVelUgiNv2FUG3OL/?imgmax=800" width="240" height="160"></a>In my opinion, writing independent user stories will be your single greatest return on investment (no pun intended – this time). In one of my recent <a href="http://www.softwareandi.com/2012/02/do-agile-estimation-techniques-really.html">posts</a>, I described how work items (stories, tasks, features, etc.) are far more likely to complete later rather than earlier if they more than one dependency, while having just a single dependency (i.e. starting the new item is simply dependent on completing the previous one) will <strong>increase</strong> the likelihood that it will complete on time.</p> <p align="justify">Of course, most of the work in writing good user stories is in this part as well. You are required to reimagine how you think of your work. You need to do away with layered one-shot thinking that is probably necessary in every industry except software. Since the actual <strong>construction </strong>of the software is for all intents and purposes <strong>near-instantaneous</strong>, you can (and should) think about vertical increments of value, when you come up with your requirements. Each such story should be <strong>worded</strong> so as to be independent of any previous (or forthcoming) stories.</p> <p align="justify">In some cases, you may find it impossible to break a story’s dependencies, no matter how you try. In those cases, try to look at the story <strong>with its dependencies</strong> as a <strong>single story</strong>. Find the commonality of them and reimagine it.</p> <p align="justify">To summarize – <strong>Independence in your stories will translate directly into increased probability of delivering on time</strong>!</p> <h3 align="justify">N is for <em>NEGOTIABLE</em></h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjipngFQzze5iTIX83HNy6JMzhX5kIt3qe-msyMngSrsX3iUFHQTn9dsCaOjqu1ONAyowpFrsCAB-lxMe7hf1xzlrtqWWUArMpDvtnX_Vv_riEAsN15PL2y23rrNGxp6sdFjjzc0S0dsK_a/s1600-h/image%25255B7%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj_3HIpJ5DcfL5esupw4dRUBtKdtaBn7fAi_4ABUMkC-WmYiG7i5ncgO0tYMgImOyoTfm5_3tJfOrvPrhR8pdltuYF-IWBJnTqtQS-KoEPQG3g9qa9FbxS-XCuevnyXfObWJ-WwStdkeawl/?imgmax=800" width="161" height="240"></a>Let’s get one thing clear: This attribute is <strong>not a copout for developers!</strong> A story’s negotiability does not give developers the right to decide not to do it. The developers do <strong>not</strong> decide what the story will be, what its scope is, when it will be delivered, and what is required to make it complete. Oh, the developers <strong>can and should</strong> discuss the story and its impact with the <strong>PO</strong>, and the PO may decide to change the story based on developer input, but it is ultimately the <strong>PO’s right (and responsibility)</strong> to make any changes to the story.</p> <p align="justify">The <strong>full meaning of negotiability</strong>, is that the contents of the story (i.e. scope, priority, requirements) can be changed at any time, from the moment they are introduced, and up until the the developers commit to it (i.e. the beginning of its <strong>sprint</strong>).</p> <p align="justify">This is perhaps both the <strong>easiest</strong> attribute to add to your user stories, and the <strong>hardest</strong>. It is easy, because it requires <strong>no extra work</strong> from the PO or team. It is hard, because it may require you to let go of any preconceptions you may have of the story (i.e. those you had when you first wrote it). It requires you to allow people to <strong>move your cheese</strong>.</p> <p align="justify">The return on this investment is quite valuable, however; Your stories will be <strong>rejuvenated</strong>, and will be more valuable to the customers and user, because they have been <strong>recently revalued, evaluated and updated</strong>. This attribute is particularly synergetic with the next one:</p> <h3 align="justify">V is for <em>VALUABLE</em></h3> <p align="justify"><img style="margin: 0px 3px 0px 0px; display: inline; float: left" alt="Standish Group" align="left" src="http://agileexecutive.files.wordpress.com/2009/01/the-standish-group-2002-report.png?w=466&h=387" width="261" height="217">You’d think that given the high premium on the time of developers, and the fact that most projects are running late, as it is, it would go without saying that <strong>everything</strong> we develop is valuable. Unfortunately that is not the case. According to the CHAOS Report, by the <a href="http://blog.standishgroup.com/about-standish">Standish Group</a>, <strong>fully 64% of developed functionality is rarely or never used!</strong></p> <p align="justify">All of these features have something in common: They were added without any consideration of their value or necessity to the users or the customers!</p> <p align="justify">The <strong>valuable</strong> attribute of user stories helps reduce these numbers, by making sure that anything and everything the team develops has value to the users. When the PO comes up with a story, and cannot find a way to describe its value, it is possible that there is no value. Our tendency to add these valueless stories to the product comes from the traditional idea that you have to define everything upfront, or it won’t be in the project. Thanks to <strong>negotiability</strong>, it is possible to focus only on what is <strong>valuable</strong>.</p> <p align="justify">This attribute also protects the system from developers’ desires to build a framework (we all love developing frameworks – it’s a conditioning or something), or do any work that doesn’t translate into value to the customer. If some <strong>technical work</strong> is required for some story, add the work <strong>as a task</strong> to that story, <strong>not</strong> as a <em>technical story</em>; this will more clearly radiate to management what is required to complete a story, and will give the PO the ability to consider this extra work and its impact when evaluating the story.</p> <h3 align="justify">E is for <em>ESTIMABLE</em></h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgxou0V_aJ_fNklZ9rykx2J9PCZI_AaBdvrGGDYhPExldWh7NwZJ4EWnOm9S05h5OeC1GSDiSLA_PEhTFJcFwuQQ_rGbWHJY-lvPjVYyKh5n1qOU8Sn7AMa2YTyAvAltmPagadsEu4FFx7_/s1600-h/image%25255B15%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="http://lh5.ggpht.com/-jRqkAE-4EMo/T2XRhaYCsjI/AAAAAAAAAiA/dr8q_0YkpWU/image_thumb%25255B7%25255D.png?imgmax=800" width="174" height="194"></a>There is a lot of good literature out there on <em>how</em> to estimate properly. While there are several, equally viable techniques out there for estimating, everyone pretty much agrees that relative estimates are easier than absolute ones, and smaller items are easier than larger ones. For more info on <em>how</em> to <strong>estimate properly</strong>, you can read my previous post on the subject, <a href="http://www.softwareandi.com/2012/01/how-to-use-agile-estimation-in-scrum.html">here</a>.</p> <p align="justify">There is more to it, though, than just the techniques. The story should be <strong>clearly scoped</strong>. There should be a beginning and an end.</p> <p align="justify">Imagine a story such as “As a user, I want a<strong> text editor</strong>, so that I can take notes”. How much will it take to develop that? I have no idea. If the user only needs a multi-line textbox with persistence capabilities, then I can probably have it done in a few hours (yes – a few hours, because <strong>nothing ever takes <em>just</em> 5 minutes!</strong>). If the user is expecting RTF capabilities with copy and paste, it’ll take longer, and if he’s looking to give MS Word some serious competition, it’ll probably take a few man-years (just guessing here; It’s too big for me to give a good estimate).</p> <p align="justify">I see estimability as the culmination and grounding of the next two attributes, <strong>Size</strong> and <strong>Testability</strong> (see below).</p> <h3 align="justify">S is for <em>Size</em></h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgU9dBzhnTr9EzyJfDLAsv87D42v9KtWSW67ZwUyB_2YVfGdMSGnQaIBM5FKm3AAi4cMyahhwSD_zM28gtR7N1UekKf5U8zsQbs42yUTIUD_-3CmL07960FeuUwOVYgEx73d_tHOZIZ4gyq/s1600-h/image%25255B19%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px 4px 0px 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsvOFzxMlamRG5O9AOJ5k09sojyxQfTKcbgZOJSPln0onFAcIIBPS45K1umGLIClPk3gpJUfoPPFwjnmeQrsEO_RPfisREi_myL-snukmbb164Nn5_lQa3Vhg6J_uSw6B5CX-7qjz69bdf/?imgmax=800" width="190" height="141"></a>“Sized Appropriately”, or “Small”, as some call it means that the story is small enough to estimate. In Scrum, and other time-boxed methodologies it is expected that the story will be scoped in a way that makes it possible for the team to complete a few of them in one sprint – at the very least, they should be able to complete one story.</p> <p align="justify">This attribute requires the PO to <strong>define in detail what it is that he wants</strong> the team to deliver. In many cases, the actual user stories that the team works on are the <strong>elaboration of the broad scopes</strong> defined in the “Epics” or “over-stories” or “super-stories”.</p> <p align="justify">What the PO gains is the ability to <strong>release early and often</strong>. The team get the ability to create less complex solutions, because the <strong>problems are smaller</strong>.</p> <p align="justify">Remember, the story should be defined in terms of their <strong>business value</strong>, not the <strong>implementation details</strong>! The details are to be left to the developer tasks, and are of no interest to the users or customers.</p> <h3 align="justify">T is for <em>Testable</em></h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh-vJ_FhW8YzCklQLfp_fH3Q40jr-s7kHKNUAD-wf1Xl0KUHZdIs51jtyrD_3x5B0GytzxES4aY9T6u3aprQjOx-1NXfkAaxIdiHgco_2KFP3PnnCojKHCyaS2_7zPt9JnptPHCDvWTSiIG/s1600-h/image%25255B23%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="http://lh5.ggpht.com/-WCGl0dvV0No/T2XRliVlsQI/AAAAAAAAAik/CxDs_Gtg3bY/image_thumb%25255B11%25255D.png?imgmax=800" width="189" height="180"></a>Testability basically means that it is possible to test the product to see if it fulfills the requirements of the user story. A testable user story has a finite and measurable set of acceptance criteria, by which it is possible to prove the validity of the product. </p> <p align="justify">This last, but most certainly not least of attributes serves everybody who has a stake in the product:</p> <ul> <li> <div align="justify">By defining the story’s <strong>acceptance criteria</strong>, the <strong>PO</strong> has the opportunity to define <strong>more specific</strong> demands of the story, than what appear simply in the “title” (“As a… I want… so that…).</div></li> <li> <div align="justify">Both the <strong>Developers</strong> and the <strong>QA</strong> gain an understanding of what the <strong>scope </strong>of the story <em>is</em> and what it is <em>not</em>, thus reducing a great source of contention about whether something is a bug, or a new feature (if I had a penny…)</div></li> <li> <div align="justify"><strong>Stakeholders</strong> gain an understanding of what they are going to receive by the release.</div></li></ul> <p align="justify">The acceptance criteria, like the rest of the story, should be worded in the product’s <strong>domain language</strong>, which means that they should be defined in the users’ terms, rather than the developer / QA terms.</p> <p align="justify">The return on your INVESTment here should be obvious: The PO gains a <strong>tighter control</strong> of what will be produced, <strong>without unnecessarily elaborating on the technical solution</strong>, while the developers and QA have a better understanding of <strong>what they are required to do</strong>.</p> <h3 align="justify">In conclusion</h3> <p align="justify">I think that <em>every</em> part of the INVEST model has value. Stories that you have invested in will be:</p> <ul> <li> <div align="justify">More likely to complete on time</div></li> <li> <div align="justify">Current and updated</div></li> <li> <div align="justify">Valuable to the customer and / or the users, with less unnecessary technical fluff</div></li> <li> <div align="justify">Clearer, with less dissonance between POs, developers and testers</div></li> <li> <div align="justify">Less complex to develop, easier to test, and quicker to get feedback as well as quicker to deploy</div></li> <li> <div align="justify">Easier to prove and validate and quicker to gain acceptance by the customer / user</div></li></ul> <p align="justify">That’s all. I think it’s a worthy goal, well worth the cost. What say you?</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:379cea8a-b675-4f72-a32e-8c2c286ce4b6" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/User+Story" rel="tag">User Story</a>,<a href="http://technorati.com/tags/INVEST" rel="tag">INVEST</a>,<a href="http://technorati.com/tags/test" rel="tag">test</a>,<a href="http://technorati.com/tags/estimation" rel="tag">estimation</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com0tag:blogger.com,1999:blog-2660291115609609354.post-74386633786575041862012-02-26T19:54:00.001+02:002012-02-26T19:55:46.345+02:00Proving Pair Programming: How and Why it Works<p><img style="display: inline; float: right" align="right" src="http://zaggskins.zagg.com/custom_pr/image4cc8433c7fba4_pr.jpg" width="157" height="157"></p> <p align="justify">In the first two posts in the <a href="http://www.softwareandi.com/2012/01/demystifying-agile.html">Demystifying Agile</a>, I wrote about <a href="http://www.softwareandi.com/2012/01/demystifying-agile-how-to-plan-releases.html">how to plan release with Scrum</a> and <a href="http://www.softwareandi.com/2012/01/how-to-use-agile-estimation-in-scrum.html">how to use agile estimation techniques in a Scrum project</a>. Delving deeper into the agile software development process, there is one practice that is by far the least popular with traditional managers, and even with many developers. It is the practice of pairing on development tasks. In this post I will attempt to clear the air a bit, explaining why it works and how to make it work for you.</p> <h3>First, a story…</h3> <p align="justify">Roughly five years ago I had to rewrite a project from scratch. The details that led to that point are of lesser import, but what is important is that it was a codebase that took <strong>three developers eight months </strong>to develop and it had <strong>four months</strong> worth of <strong>ugly patches</strong> that sorely needed to be refactored. And a few <strong>breaking changes</strong> in the requirements. And I had <strong>30 days</strong>. And <strong>two developers</strong> (myself included).</p> <p align="justify">Rather than splitting the work, we decided to pair. We paired for 6-7 hours out of eight working hours every day.</p> <p align="justify">The result was more robust, extensible and better performing than before.</p> <p align="justify">And we did it in <strong>20 days</strong>.</p> <h3>Why did it work?</h3> <p align="justify">From a strictly mathematical standpoint, it shouldn’t have been done. I’ve rewritten projects before, and while it often doesn’t take as much time as it originally did, it doesn’t take <em>a lot </em>less time. We took the work of 24 man-months, and completed it in 40 man-days. </p> <p align="justify">Here are what I believe to be the reasons we achieved the results:</p> <ol> <li> <div align="justify">With two developers, equally participating on the project, we had immediate code-review done as we develop. It is a (should be) well known fact that the shorter the feedback cycle, the easier it is to act on the feedback. With <strong>near-instantaneous feedback</strong>, the <strong>improved quality</strong> is simply automatically baked in.</div> <li> <div align="justify">Two developers have two different sets of experiences, bringing in a <strong>different point of view</strong>. Any <em>iffy</em> idea is immediately examined. You don’t get to to sip your own cool-aid when you pair.</div> <li> <div align="justify">With another developer near you all day (or most of the day), you are <strong>more focused</strong> on your work. You don’t go off on a tangent, reading up on a new technique or gizmo, and you don’t get lost in the quagmire of email: You <strong>explicitly decide which distractions to acknowledge</strong> and which to postpone. And if you don’t, your pair will help you.</div> <li> <div align="justify">It’s much more <strong>difficult to cut corners</strong> with someone else (your pair) looking over your shoulder; your guilt will stop you, or his will. Any corners cut (or conversely, taking too long to complete a task) will only be the result of an explicit decision by both of you. <strong>Explicitness tends to cut down on occurrences</strong>.</div> <li> <div align="justify">Two-legged-distractions (a.k.a corporate-drive-by incidents, a.k.a. managers and coworkers) tend to <strong>bother you less when</strong> you’re sitting with someone else. They often go look for someone easier to single out if possible. <strong>There’s strength in numbers</strong>. If that fails, the fact that you’re already sitting with someone will give you a good valid excuse to ignore the distraction.</div></li></ol> <p align="justify">As you can see, these observations, my experiences, are not easily measurable. They are, however, no less real. </p> <h3></h3> <h3 align="justify">How to make it work for <em>you</em></h3> <p align="justify">First, forgive me for the following copout: YMMV (Your Mileage May Vary); nothing I can write is guaranteed to work for everybody. But I do expect the following ideas to work for most developers who are willing to give it a shot:</p> <ol> <li> <div align="justify">Give it a shot. Seriously, it won’t bite. And you can always quit (though winners don’t quit, and quitters don’t win).</div> <li> <div align="justify">Don’t do it the whole day, and don’t work a long day. Pairing is very draining because it demands a focus far greater than you are likely to achieve on your own. Work for no more than 8-9 hours a day. Pair for no more than 6-7 of them. Leave an hour or so for email, meetings, easy no-brainer tasks, and other nuisances.</div> <li> <div align="justify">Pair with someone that could review your work. Offer to pair with that developer on his task after that. </div> <li> <div align="justify">Don’t hog the keyboard. Switch every now and then. Otherwise you have one developer and a bored observer who’s wasting his or her time.</div> <li> <div align="justify">Don’t declare it – just do it. Pairing is a hard sell. Results aren’t. Besides, it is usually easier to get forgiveness than it is to get permission.</div></li></ol> <p align="justify">I hope this post helps you add a trick to your agile bag. It worked wonders for me.</p> <p align="justify">Assaf.</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:de23f2dd-3a4b-4b42-bb79-b1f527aca145" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Pair+Programming" rel="tag">Pair Programming</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com7tag:blogger.com,1999:blog-2660291115609609354.post-72929134755467287822012-02-19T13:13:00.001+02:002012-02-19T13:13:40.039+02:00Do Agile Estimation Techniques Really Account for Scrum Projects’ Successes?<p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjqxhewVcqOxp4CkMlHD7CQsttGQYt2c7KClK0gs_nxzSRacqrr5JDhrNS9mcfBihYD1dgbmeucbAYpqnTdgEyWzMS9q063ZvyRR48Qvv_3EHfp65jv9UY8A_VJifAYWFm8RbLu76Dk1gBA/s1600-h/image%25255B4%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhn2o1zS4_rhnVbKax9bEzOuX3Q3EQU4g9jkPFErjvI1Q6h7DbwCuVzqcYqujnoq4Q_3m7aZEjUTT35nUMdoGKgLU7GvJm-G47vXiZNLf-HGHRjqhneTBCw_Zjhm9hzo36P1DxxOmHDXYyk/?imgmax=800" width="142" height="142"></a>After several years of experience working with, training and coaching teams on Scrum, I have no doubt that agile (empirical) estimation techniques are better than classic, predictive estimation techniques. One question that kept nagging me over time is whether or not using <strong>story points</strong>, <strong>T-shirt sizes</strong>, or<strong> ideal hours</strong> truly explains the increased success of Scrum based techniques?</p> <p align="justify">It took me a while, but I finally figured it out. And the answer is a definite <strong>‘NO’</strong>!</p> <h3>All Estimation Techniques are Merely Guesses</h3> <p align="justify"><img style="display: inline; float: right" align="right" src="http://www.fubles.com/fublog/wp-content/gaussian.png">At the end of the day (or at least, at the end of the planning session), any estimation is just a guess: sometimes its more, and sometimes its less. This means that the distribution of the actual time versus the estimation should be pretty much <a href="http://en.wikipedia.org/wiki/Normal_distribution">normal</a>: In large numbers, about half of the actual results will be less than the estimation, and half will be more. On average, according to the <a href="http://en.wikipedia.org/wiki/Law_of_large_numbers">Law of Large Numbers</a>, it evens up.</p> <p align="justify"><img style="display: inline; float: left" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiUm3OmTnH1eEaD6NkyGVbbXlHA55DxReoKFOmbxASyFhHIXkqpG81UteIqolSBA5ixR8D9ejdN7t-jejVHPIyLbGmVKu2yZRIe8yWk8uV_yiIRerCK6EK38_huqC2o_mO_ZYGoDid56Mks/s1600/example.png" width="179" height="134">The better the estimation technique is, the steeper the curve will be, i.e. the closer actual results will be to the estimation.</p> <p align="justify">My experience is that agile techniques are in fact better at predicting the actual results, but the fact remains that if you make enough of these predictions, then regardless of the technique, the <strong>variance should cancel itself out </strong>and the <strong>sum should settle on the average</strong>!</p> <p align="justify"><strong>This means that the quality of the technique used to estimate each task has little or no impact of the success of estimating the time to complete the entire project!</strong></p> <h3 align="justify">Then Why Do Estimations Fail?</h3> <p align="justify">If estimations behave “normally” whole project estimations should not fail. I don’t buy into all that “programmers are notoriously optimistic” sentiment; I’m a developer myself and there is not a single soul alive that will call me optimistic, and yet, non-agile projects I worked on overran their deadlines, like everybody else’s. Something must be out there, that either changes the <strong>normal distribution</strong>, or <strong>invalidates the law of large numbers</strong> or both. And it has to be something that is present in classic waterfall-ish projects but not in agile ones.</p> <h3 align="justify">It Is All About the Independence!</h3> <p align="justify">The main difference, in my opinion between agile and non-agile projects is how they are planned and constructed. An agile project plan is basically a stack of user stories, with <strong>no*</strong> dependencies between them, whereas a waterfall project plan is a Gantt chart describing tasks and their interdependencies.</p> <h3 align="justify">Why Is This Important?</h3> <p align="justify">Let’s assume a task that has two dependencies. Each were estimated, and each have a normal distribution of the actual amount of time to complete vs. the estimated time. The following figure describes such a “plan”:</p> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjlgy6ByjFWS-6_ozgAVJ37OiQkooq8tWRJNAqxHq5C0rznNjbiZLmRD6aN-wqnZkDvFaLw_hfo2ZOw2XLOXtmVpCESlPkcUG4R2iPrmKA44wUywrHdsqunXtN2cRxHEePkonVAb6XO5Uz7/s1600-h/SimpleDependencies%25255B3%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: block; float: none; border-top-width: 0px; border-bottom-width: 0px; margin-left: auto; border-left-width: 0px; margin-right: auto; padding-top: 0px" title="SimpleDependencies" border="0" alt="SimpleDependencies" src="http://lh4.ggpht.com/-2gQyCtCrKsw/T0DZUmLlpTI/AAAAAAAAAfA/PkByPFKZQOY/SimpleDependencies_thumb%25255B1%25255D.png?imgmax=800" width="240" height="107"></a></p> <p align="justify">Each task has a 50% chance to be completed before time and 50% to be completed after (There is of course no statistical chance of being completed “on time”). Now, let’s say we’re interested in calculating the probability of Task C to be completed before time, or <strong>not to finish late</strong>. For the sake of ease, we’ll assume all three tasks to have the same estimated duration. For Task C to begin early, it needs <strong>both</strong> of its dependencies to complete early. Since the chance of each to complete early is 50%, the chance for both is (0.5 * 0.5) = 0.25, or 25%. The chance for this not to happen, i.e. for <strong>at least one of them </strong>to be completed late is 1-0.25 or <strong>75%</strong>. this means that there’s a 75% for Task C to complete late, and of course it has its own probability of being late, which means that the chance of <strong>Task C completing late (and making the whole project run late) is more</strong> <strong>than 75%!</strong></p> <p align="justify"><img style="display: inline; float: right" align="right" src="http://www.mzandee.net/~zandee/statistiek/stat-online/chapter1/graphics/neg_skew.gif" width="211" height="109">It is easy to see that the more complex a project is, the more dependencies each task has the greater the chance of being late is; The distribution of the actual duration of tasks with dependencies is a <a href="http://www.research-assessment-adviser.com/skewed-distribution.html">negatively skewed distribution</a>.</p> <h3>Scrum User Stories Have No Dependencies</h3> <p align="justify">With this in mind, Scrum user stories have no* interdependencies. If two stories <em>do</em> have a dependency, they are should be joined to be treated as one (and if they are too big, they can and should be split again, though in a way that doesn’t create dependencies). With no dependency (or, if you wish, a single dependency that is the completion of the prior story), we get a plan that looks like this:</p> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjl3Vkv5-4T3Cuy8anass8XcCCoAdUs8DPQOnxoG71yLNk54m3QIcQ-3UPaOCgzlJXZ_JEXWxRChzkQvgnv5loUoC_U8B_Dh7soL6teelztHAQO-y_xsnODHyuw9L8LJILfrKj0LFFC0OW2/s1600-h/NoDependencies%25255B3%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: block; float: none; border-top-width: 0px; border-bottom-width: 0px; margin-left: auto; border-left-width: 0px; margin-right: auto; padding-top: 0px" title="NoDependencies" border="0" alt="NoDependencies" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgeXiR3OuZAw3VYc_QtVXd8BAzq_yNWXmbk3tPEziqiov3t-d4IuVjAVuZztQNy7Ya3QjvcSFEOAIA-B3R7WzO3HfSk2DfaptT7iRgYwsmHDN3FAuuZXVo01ReuZDBpdt14RDOEcCjrDoGm/?imgmax=800" width="240" height="112"></a></p> <p>The chance of B starting early, which is the same chance of A ending early, is 50%. The chance of B <strong>completing </strong>early is <em>still</em> 50%! Even better the variance is reduced, which means that there is an increased probability of the total project duration being close to the the estimate (i.e. a steep probability distribution). </p> <h3>What Does This Mean?</h3> <p align="justify">This means, that while a project with multi-dependent tasks has an increased skew towards lateness with each added task, a project with no dependency (beyond sequence) has an increased tendency towards the mean, or the estimate.</p> <p align="justify">This means that by the <strong>very nature</strong> of <strong><em>what</em></strong> we are estimating, agile projects tend to succeed (i.e. be on budget and on time), than non-agile.</p> <p align="justify">Moreover, the actual estimation technique doesn’t matter – it is the estimation of <strong>independent units of work</strong> that makes the difference.</p> <p align="justify">Therefore, my conclusion, and advice is that the <strong>very first</strong> change a team needs to make is to start working on <strong>independent</strong> features – call them user stories, features, or MMFs – it doesn’t matter; just keep them independent of each other!</p> <p align="justify">Hope this helps,</p> <p align="justify">Assaf.</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:07acd213-3879-4509-ad23-bb359648e953" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Estimation" rel="tag">Estimation</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/Sprint+Planning" rel="tag">Sprint Planning</a>,<a href="http://technorati.com/tags/User+Story" rel="tag">User Story</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com6tag:blogger.com,1999:blog-2660291115609609354.post-40308825624030309372012-02-06T09:53:00.000+02:002012-04-18T14:39:05.390+03:00How to Write Automated Tests for Console Applications<div align="justify">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh1mtuiwa-bPv-ndLAM7LzeqoziCAtBDT9qgfKm1hMzgSGp5qX5SdHpob6pEi9LrTT9eoq4trB4zXzZBthd0gmlcpKvStHiwJFcpvjrwuwgtxsyQdIrpfUbDfj6NXyDxvmzHzE2lkjpxLtc/s1600-h/command_line_interface%25255B3%25255D.png"><img align="right" alt="command_line_interface" border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhFXLe51uOFqslbgZV62hk8zW-iJYRIKOfvP6FbGq3druHQIltuvWKzUesRL1UcW8_1gcnQl_hfpBIyM-olXZ_AZMCjzzjqwPTMlxKnQokiCTIgVgoF_8m7s7KuUtKb7d3EMlhiVipUNOGS/?imgmax=800" style="background-image: none; border-bottom-width: 0px; border-left-width: 0px; border-right-width: 0px; border-top-width: 0px; display: inline; float: right; margin: 0px 0px 0px 4px; padding-left: 0px; padding-right: 0px; padding-top: 0px;" title="command_line_interface" width="240" /></a>I don’t know about the rest of you, but I still find myself writing a lot of console applications. Most of the time these are utilities or services or some kind of customization or process automation scripts. Until recently, if I wanted to write automated tests for these, I would have to separate the business logic from the program itself and test the functions. While this is obviously a <strong>good practice</strong> for any moderately complex project, it sometimes might be <strong>overly complicated</strong> for what is needed. Moreover, this doesn’t work for <strong>black-box user acceptance tests</strong>.<br />
<br /></div>
<h3 align="justify">
The System.Console Class</h3>
<div align="justify">
<br />
In the .NET Framework console apps revolve around, well, the <em>Console</em> class. You get user input with <span style="font-family: 'Courier New';"><span style="color: blue;">Console</span>.Read() </span><span style="font-family: arial;">(and <span style="font-family: 'Courier New';">ReadLine()</span>, and <span style="font-family: 'Courier New';">ReadKey()</span>, and so on). Conversely, you send output to the user with <span style="font-family: 'Courier New';"><span style="color: blue;">Console</span>.Write() and <span style="font-family: 'Courier New';"><span style="color: blue;">Console</span>.WriteLine()</span></span></span><span style="font-family: arial;">. </span></div>
<div align="justify">
<span style="font-family: arial;">So let’s take a look at the code inside the .NET Framework. By the way, I used Telerik’s <a href="http://www.telerik.com/products/decompiler.aspx">JustDecompile</a> to browse the code. If you don’t already have a decompiler of choice, I suggest you take a look at it. It’s simple, elegant and free (and no, I don’t own stock).</span></div>
<div align="justify">
<span style="font-family: arial;"><br /></span></div>
<div align="justify">
<span style="font-family: arial;">So, here's the code behind <b>Console.ReadLine():</b></span></div>
<div id="codeSnippetWrapper">
<div id="codeSnippet" style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;">
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum1" style="color: #606060;"> 1:</span> <span style="color: blue;">public</span> <span style="color: blue;">static</span> <span style="color: blue;">string</span> ReadLine()</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum2" style="color: #606060;"> 2:</span> {</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum3" style="color: #606060;"> 3:</span> <span style="color: blue;">return</span> Console.In.ReadLine();</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum4" style="color: #606060;"> 4:</span> }</pre>
</div>
</div>
<br />
<div align="justify">
<span style="font-family: arial;"></span><span style="font-family: arial;">And here’s <b>Console.WriteLine()</b>:</span></div>
<div id="codeSnippetWrapper">
<br />
<div id="codeSnippet" style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;">
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum1" style="color: #606060;"> 1:</span> <span style="color: blue;">public</span> <span style="color: blue;">static</span> <span style="color: blue;">void</span> WriteLine()</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum2" style="color: #606060;"> 2:</span> {</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum3" style="color: #606060;"> 3:</span> Console.Out.WriteLine();</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum4" style="color: #606060;"> 4:</span> }</pre>
</div>
</div>
<br />
<div align="justify">
As it turns out, Console’s <strong>read </strong>and <strong>write</strong> methods are merely pass-through methods that call the same methods on the <strong>In</strong> and <strong>Out</strong> <a href="http://msdn.microsoft.com/en-us/library/system.io.textreader.aspx">TextReader</a> and <a href="http://msdn.microsoft.com/en-us/library/system.io.textwriter.aspx">TextWriter</a> properties (again - respectively).</div>
<br />
<div align="justify">
The text reader and writer classes, as so eloquently put in the class descriptions on MSDN, “represent a reader [and writer] that can read [and write] a sequential series of characters”. Well, that still is more helpful than some descriptions I’ve seen... Anyway, they are the abstract parents of the <strong>string</strong> and <strong>stream </strong>reader (and writer) classes. Why is this important? Well, the In and Out properties are by default set to the keyboard input and screen output streams.</div>
<br />
<div align="justify">
<span style="font-family: arial;">Now, if only there was a way to redirect those streams…</span></div>
<br />
<div align="justify">
Enter <span style="font-family: arial;"><span style="font-family: 'Courier New';"><span style="color: blue;"><a href="http://msdn.microsoft.com/en-us/library/system.console.setin.aspx">Console.SetIn()</a></span> and <span style="font-family: 'Courier New';"><span style="color: blue;"><a href="http://msdn.microsoft.com/en-us/library/system.console.setout.aspx">Console.SetOut()</a></span></span></span></span><span style="font-family: arial;"> respectively. Hmm, that’s a lot more respect than I usually show in a blog post…</span></div>
<br />
<div align="justify">
With <strong>SetIn</strong>, I can redirect the <strong>In</strong> text-reader to a <a href="http://msdn.microsoft.com/en-us/library/system.io.stringreader.aspx">StringReader</a>, and with <strong>SetOut</strong>, I redirect the output to a <a href="http://msdn.microsoft.com/en-us/library/system.io.stringwriter.aspx">String<em>Writer</em></a>. </div>
<br />
<div align="justify">
I can now, quite easily initialize the string reader to a value that contains whichever input, or set of inputs I want to use, and the console application will read characters or lines as needed. I can then read the output of the string writer, and compare it with expected results. </div>
<br />
<div align="justify">
And the most beautiful part of it is that there is (almost) <strong>no need to modify the console application in any way </strong>for this to work.<br />
<br /></div>
<h3 align="justify">
Example</h3>
<br />
The following example was written in C#, using MS-Test (forgive me) to test the code. The application is a simple one that plays the game <strong>7-Boom</strong> (a local variation of the game <a href="http://en.wikipedia.org/wiki/Bizz_buzz">BizzBuzz</a>). As you will see, except for making the <strong>Program </strong>class and <strong>Main()</strong> method public in lines 1 and 3, so that I can reach the code from another (test) assembly, I did nothing I wouldn’t do in any other console application:<br />
<div id="codeSnippetWrapper">
<br />
<div id="codeSnippet" style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;">
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum1" style="color: #606060;"> 1:</span> <span style="color: blue;">public</span> <span style="color: blue;">class</span> Program</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum2" style="color: #606060;"> 2:</span> {</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum3" style="color: #606060;"> 3:</span> <span style="color: blue;">public</span> <span style="color: blue;">static</span> <span style="color: blue;">void</span> Main()</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum4" style="color: #606060;"> 4:</span> {</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum5" style="color: #606060;"> 5:</span> Console.Write(<span style="color: #006080;">"Enter upper limit: "</span>);</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum6" style="color: #606060;"> 6:</span> var range = <span style="color: blue;">int</span>.Parse(Console.ReadLine());</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum7" style="color: #606060;"> 7:</span> </pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum8" style="color: #606060;"> 8:</span> <span style="color: blue;">for</span> (var i = 0; i < range; i++)</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum9" style="color: #606060;"> 9:</span> {</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum10" style="color: #606060;"> 10:</span> var num = ((i % 7 == 0) || i.ToString().Contains(<span style="color: #006080;">'7'</span>)) ? <span style="color: #006080;">"BOOM"</span> : i.ToString();</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum11" style="color: #606060;"> 11:</span> Console.Write(<span style="color: #006080;">"{0}, "</span>, num);</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum12" style="color: #606060;"> 12:</span> }</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum13" style="color: #606060;"> 13:</span> }</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum14" style="color: #606060;"> 14:</span> }</pre>
</div>
</div>
<br />
And here is a test:<br />
<div>
<br />
<div id="codeSnippet" style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;">
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum1" style="color: #606060;"> 1:</span> <span style="color: green;">// Arrange</span></pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum2" style="color: #606060;"> 2:</span> <span style="color: blue;">using</span> (var sw = <span style="color: blue;">new</span> StringWriter())</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum3" style="color: #606060;"> 3:</span> {</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum4" style="color: #606060;"> 4:</span> <span style="color: blue;">using</span> (var sr = <span style="color: blue;">new</span> StringReader(<span style="color: #006080;">"100"</span>))</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum5" style="color: #606060;"> 5:</span> {</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum6" style="color: #606060;"> 6:</span> Console.SetOut(sw);</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum7" style="color: #606060;"> 7:</span> Console.SetIn(sr);</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum8" style="color: #606060;"> 8:</span> </pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum9" style="color: #606060;"> 9:</span> <span style="color: green;">// Act</span></pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum10" style="color: #606060;"> 10:</span> SevenBoom.Program.Main();</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum11" style="color: #606060;"> 11:</span> </pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum12" style="color: #606060;"> 12:</span> <span style="color: green;">// Assert</span></pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum13" style="color: #606060;"> 13:</span> var result = sw.ToString();</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum14" style="color: #606060;"> 14:</span> Assert.IsFalse(result.Contains(<span style="color: #006080;">'7'</span>));</pre>
<pre style="background-color: white; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum15" style="color: #606060;"> 15:</span> }</pre>
<pre style="background-color: #f4f4f4; border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none; color: black; direction: ltr; font-family: 'Courier New', courier, monospace; font-size: 8pt; line-height: 12pt; margin: 0em; overflow: visible; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px; text-align: left; width: 100%;"><span id="lnum16" style="color: #606060;"> 16:</span> }</pre>
</div>
</div>
<br />
<div align="justify">
That’s it! I set the input that the user would have entered in line #7, and redirect the I/O in lines 6-7. All that remains is to assert that the output in line #14 meets the expectations.</div>
<br />
<div align="justify">
By the way, this works exactly the same in Java as it does in C#. The difference is that in Java you will use <strong>System.setIn()</strong> and <strong>System.setOut()</strong> to set the <em>PrintStreams</em> (the In and Out properties used in Console.Read & Console.Write).</div>
<br />
<div align="justify">
So now you can write test-driven (and behavior driven) console applications with greater ease. </div>
<br />
<div align="justify">
Hope this helps,</div>
<br />
<div align="justify">
Assaf.</div>
<br />
<div class="wlWriterEditableSmartContent" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:4e1c7a51-c2a5-4b1f-b242-2708e8936a09" style="display: inline; float: none; margin: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/BDD" rel="tag">BDD</a>,<a href="http://technorati.com/tags/C%23" rel="tag">C#</a>,<a href="http://technorati.com/tags/Java" rel="tag">Java</a>,<a href="http://technorati.com/tags/TDD" rel="tag">TDD</a>,<a href="http://technorati.com/tags/Test" rel="tag">Test</a>,<a href="http://technorati.com/tags/Unit+Tests" rel="tag">Unit Tests</a></div>Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com6tag:blogger.com,1999:blog-2660291115609609354.post-28657252952270380092012-01-29T13:11:00.001+02:002016-09-16T19:20:42.927+03:0010 Signs that Your Team Isn’t Really Agile<div align="justify">
[<strong>UPDATE</strong> – This post was recently translated by Choepidiui (I hope I got the name right) into Korean. For the Korean version of this post, please go to his <a href="http://choipd.wordpress.com/2012/02/11/%EB%8B%B9%EC%8B%A0-%ED%8C%80%EC%9D%B4-%EC%A7%84%EC%A0%95%ED%95%9C-%EC%95%A0%EC%9E%90%EC%9D%BC%EC%9D%B4-%EC%95%84%EB%8B%88%EB%9E%80-%EC%97%B4-%EA%B0%80%EC%A7%80-%EC%A7%95%ED%9B%84%EB%93%A4/">site</a>]</div>
<div align="justify">
With all the hype in the software industry about Agile, Scrum and so on, it is no surprise that many companies hear or read about the virtues of these methods, perhaps at a conference or in a technical white paper, and think “we need this here”. Unfortunately, some organizations are not as ready to make the mental shift required to embrace the agile way of doing things…</div>
<div align="justify">
Below is a (by no means conclusive) list of signs that your team waded in toe-deep, rather than going the whole nine yards:</div>
<h3>
You might not be truly agile if…</h3>
<br />
<h3>
</h3>
<h4>
1. Your team is not responsible for the entire story</h4>
<div align="justify">
Perhaps the most important aspect of an agile team is that it is <strong>cross functional</strong>. This means that the team, <strong>as a whole</strong>,<strong> </strong>have all the skills required to deliver a <strong>valuable product increment</strong>. If a team has only client developers, then all server-side tasks are probably relegated to a different team. In this case, the team is <strong>not</strong> handling a story from end to end; when they complete their work, no value has been added to the product – <strong>not in the eyes of the customer!</strong> Teams that work like this resemble a factory where the product sits on the conveyor belt and different layers are added to it by different teams. At no moment till the last team does its thing is the feature (or product) done.</div>
<div align="justify">
It is possible to have a successful development process without cross-functional (feature) teams, but it simply isn’t agile.</div>
<h4>
2. Testing is done by another team</h4>
<div align="justify">
Another equally important quality of an agile team is the ability to deliver a <strong>working product increment</strong>. If the developers call a feature that has merely been coded and not tested “done”, then there is a serious flaw with their <strong>definition of done</strong>. This is often another example of not being cross-functional: QA is simply another team. In order for a team’s work to be considered <strong>done</strong>, it should be tested and integrated and ready to use.</div>
<h4>
3. You are not INVESTing in your user stories</h4>
<div align="justify">
<a href="http://en.wikipedia.org/wiki/INVEST_(mnemonic)">INVEST</a>, is a mnemonic acronym coined by Bill Wake that describes the values of a good user story: <b>Independent</b> of other user stories, <b>Negotiable</b> scope up to the sprint in which they’re developed, <b>Valuable</b> to the end user or customer, <b>Estimable</b> by the development team, <b>Sized appropriately</b> so that the team can complete a few of them in one sprint, and <b>Testable</b> so that the team can prove that they have successfully completed the requirements. </div>
<div align="justify">
Only if the product owner <em><strong>INVEST</strong></em>s<em><strong> </strong></em>in the stories, will he be able to order them by their value to their customer, and be able to promise that when each is complete, the customer will receive a valuable increment to the product. Likewise, the team will be able to deliver these increments rapidly, and with confidence in their quality. </div>
<h3>
</h3>
<h4>
4. Tasks are assigned to team members by a manager</h4>
<div align="justify">
In a truly agile team, each member can pick which tasks he or she will work on next, as long as it pertains to the next most valuable user story. Traditionally, project managers or team leaders would assign tasks to team members, often months in advance. Even though this is done for the sake of optimizing a project schedule, it is a <strong><u>wasteful</u></strong> process that can’t possibly take into account how the entire project might change over time, nor what the team members’ skills and desires might be at the time. </div>
<div align="justify">
A team member may want to focus on improving his skills, or try to learn to do something outside his comfort zone. A responsible, self-managing team will find a way to make sure the tasks get done as soon as needed and in line with the reality of the project as it is at the present. The best the manager can truly hope for is to get out of the way. Besides, he has more important things to do.</div>
<div align="justify">
The only time a project manager should expend the effort of allocating resources is when a task requires a <strong>resource that the team doesn’t have</strong>. Those should be few and far between. If this is a recurring issue, it is a sign that the team isn’t cross-functional enough (see the first point, above).</div>
<h4>
5. Your team is told how much work to commit to</h4>
<div align="justify">
If a PM gives the team a certain set of resources (members), a deadline (release or sprint), and then tells them how much work they should commit to (or vetoes their commitment), then the project manager is guilty of attempting to break the iron triangle. A team should be able to commit to as much work per iteration as they believe they can (and should base their estimates on past experience). </div>
<div align="justify">
If this isn’t the case, then there is nothing agile about the plan; the plan was set in advance, etched in stone, and you aren’t willing to renegotiate it, even at the <strong>implicit expense of quality.</strong></div>
<div align="justify">
For a team to be truly agile, it must be accepted that the plan might be delivered with less than all of the stories originally planned (and it should be the least valuable ones that get booted).</div>
<h4>
6. You are reporting rather than discussing your progress</h4>
<div align="justify">
A subtle and insidious sign that you aren’t really agile is that you report your progress to the <strike>project manager</strike> scrum master, not to the team, at the daily stand up meeting. The meeting is there so that the (entire) team will have a sense of what each other is doing, what they are stuck on, and what they are planning to do. </div>
<div align="justify">
Despite the <strong>seemingly managerial </strong>nature of the three questions asked (“what did you do since then last meeting?”, “what are you planning on doing till the next one?”, “what might block your progress?”) , the questions are not there for the manager to keep tabs on the team, but to elicit another team member’s thoughts on the matter (“can I help?”, “does this affect my tasks?”, etc.).</div>
<div align="justify">
Each team member should be addressing the rest of the team. The PM should be there to listen, and perhaps answer questions; he should not become the focus of the meeting.</div>
<h4>
7. You are not focusing on completing the most important user story</h4>
<div align="justify">
Sometimes, a team may divide their work into stories and break them down into tasks, but instead of <strong>swarming</strong> on the topmost story and divide the tasks among members, the <strong>stories</strong> are divided. This has two un-agile consequences: </div>
<div align="justify">
First, at a given time, all of the stories may be partially completed (<em>regardless of value</em>), instead of part of the stories (<em>based on value</em>), totally complete. This transforms the team and the iteration plan into a waterfall-ish plan, rather than an agile one, as its success is based on the premise (hope) that everything will be completed on time, otherwise, nothing is.</div>
<div align="justify">
Second problem is that each member’s work has less impact and import to his team members. It is not <em>their</em> story he’s talking about, after all. The other members have less of an incentive to listen and help. The daily meeting becomes a mere progress report that can easily be replaced with a query to the chosen ALM tool. </div>
<div align="justify">
For a team to be agile, they have to be geared towards working on the same problem, and put all their effort into cranking out <strong><em>complete </em></strong>features, as quickly as possible.</div>
<h4>
8. You changed to agile last year, and haven’t changed a thing since</h4>
<div align="justify">
Here’s a tricky one – you think you nailed it; you may have brought in an expert way back then, and we worked out a plan, and it seems to work, and now it’s etched in stone and nobody can change it. Well guess what – you’re missing on an important part of being agile: <strong>Actually being agile!</strong> Reality changes, new ideas and new influences come up all the time. There’s always something that could be done better. </div>
<div align="justify">
An agile team holds retrospectives on a regular basis, where they put their heads together to think of what they <strong>did right</strong> since the last meeting, what they <strong>could do better</strong> in the next iteration, and <strong>what visible actions</strong> need to be taken to improve.</div>
<div align="justify">
These visible actions most often manifest as a <strong>change </strong>to the work process.</div>
<div align="justify">
<em>Note: If you are using an IT-based ALM tool to manage your work process (e.g. TFS, Greenhopper, etc., Version One) you should take care to account for the impact of the change on the tool.</em></div>
<h3>
Time to Publish</h3>
<div align="justify">
Sometimes there are unforeseeable problems that mean you reach the deadline, and you haven’t completed all of your planned work. If you storm your stories and make sure you deliver one <strong>complete story at a time</strong>, ordered by priority, you will likely have a good enough product (yes I know I made this point before, but it’s worth repeating…)</div>
<div align="justify">
So it’s time to post. I know I <strong>promised</strong> 10 signs in the title, but it turns out that I can’t. At least I came through with the most important ones, fully ready on time, no?</div>
<div align="justify">
Well, if you don’t feel that way, and you think it is more important to deliver everything, than it is to meet a deadline, then here’s sign #9.</div>
<h4>
9. You are not ready to release on time with an incomplete scope</h4>
<div align="justify">
If you can’t organize your work in such a way that you’re ready to deliver the most important features, those you’ve completed, at any given moment (especially at the deadline), then <strong>your plan isn’t agile</strong>. You are likely building your product in layers, like a house, rather than in vertical slices, of product value increment.</div>
<div align="justify">
An agile product is built one user story (or value increment, or minimal marketable feature – doesn’t matter how you call it) at a time. For more on it, read my post on <a href="http://www.softwareandi.com/2012/01/demystifying-agile-how-to-plan-releases.html">how to plan agile releases</a>.</div>
<h3 align="justify">
Here’s another one:</h3>
You can always release the remaining features at a later date, with a minor release increment…<br />
<h4>
10. You are not getting customer feedback every sprint</h4>
<div align="justify">
At the end of every sprint, an agile team demonstrates the latest increment to the product. The audience may include any and all stakeholders in the project, it definitely includes the product owner / project manager and should, when relevant, <strong>include the customer</strong>. Some teams use this as some formal milestone to show their progress, and continue with the (original) plan for the next sprint – regardless of the results! <strong>This is not agile</strong>. </div>
<div align="justify">
A truly agile team will leverage the demo to elicit comments from the stakeholders about the recent development, to make sure that they are on track, and that if the requirements or environment changed during the last sprint, these changes will be reflected in the <strong>product backlog</strong> and potentially in the <strong>upcoming sprint backlog</strong>!</div>
<div align="justify">
Remember, and agile team <strong>embraces change</strong>, rather than avoiding it.</div>
<h3 align="justify">
Summary</h3>
<div align="justify">
There. That’s 10 signs. I hope you found them enjoyable as well as educating. </div>
<div align="justify">
So do <strong>you</strong> have any more signs that should be added to this list? <strong>Please add them in the comments</strong>.</div>
Assaf.<br />
<br />
<h3>
[EDIT]</h3>
<br />
<h4 align="justify">
11. You’re not agile if you can’t deal with a change in the original scope.</h4>
<div align="justify">
Now, I know I said there’d be (only) 10 signs, but based on early, prerelease feedback, I was asked to add another one. I showed them to a friend of mine before posting, and he liked what he saw. In fact, he liked the idea so much, that he suggested another one that I might add. After the release however, he suggested I change the wording. I hope you like this one better..</div>
<div align="justify">
<img alt="Smile" class="wlEmoticon wlEmoticon-smile" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJJwulbMBGHKAZKMfv3qBnK20L3IeAhUof9OGwsp8jKosBHoDHPIDGKazn-E65_xUyz_i-U0_jda20jpIXWmuWCAh3SlTx-kLMKmwDLg_OKrj5S6WpAkK7Z_9t6jRPbJhGRncGL0eBYInZ/?imgmax=800" style="border-bottom-style: none; border-left-style: none; border-right-style: none; border-top-style: none;" /></div>
<div class="wlWriterSmartContent" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:ef9c6409-ccb6-4d31-a1bc-2ddb4d670e26" style="display: inline; float: none; margin: 0px; padding-bottom: 0px; padding-left: 0px; padding-right: 0px; padding-top: 0px;">
Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Definition+of+Done" rel="tag">Definition of Done</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/User+Story" rel="tag">User Story</a></div>
<br />
Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com11tag:blogger.com,1999:blog-2660291115609609354.post-40639421243330512382012-01-22T16:38:00.001+02:002012-01-22T16:38:31.695+02:00How to Use Agile Estimation in Scrum Projects<p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgk6vxdokVHsEw_8RtXPz3giPtMliWNJecfnt0GvRU-QXSrYCnSiSg9Cs4m2Lcrk32LW5al1p0yvyDTYsq9Z8v7ATZlvCApHvabIoFuGx9jHHWSeWgppatBidb7CDTL4dTc8NLscS-Eu03K/s1600-h/image%25255B3%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjz3zZyQ4RyRN_iiZGd6eqde39-rpSIWBCE7cyC-s7uX2hV_iiACII5qgdxsbedhQZBSgeXT5e01DcScOqE4ZuuRbB4pOP3Ez2cnVq6u3zHEivisVvvOyha_S3mZvDAaumJulpsxVxfjDLj/?imgmax=800" width="240" height="166"></a>Like it or not, estimations are a big part of professional and commercial software development. Estimations are used in most projects regardless of methodology: Waterfall or Scrum, traditional or agile, every stakeholder needs to know the numbers. Projects succeed or fail as a result of these. Unfortunately, humans, as a rule, tend to suck at estimating.</p> <p align="justify">This post will compare and contrast the different estimation techniques and applications used by both agile and non-agile methodologies, and explain how to use them (and not <em>mis</em>use them), particularly in a Scrum project.</p> <h3>What is Wrong with how We Estimate?</h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjAHBuWFwDzsVUptrZNUSMESDKvNZkmCPdTK9ypvyQf-DZxDFgheJdch4YeTRYg54ju1SdQWD10gtpYgR0qHdDzhYAS2EEU1wKcMlDyhQw_ys5CQF5gm69kbMrzWF4tXdYsJpesBXYRk8Ya/s1600-h/image%25255B7%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px 8px 0px 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjTbI6213KCfTHIgB5HXMZWZ1pov5tR0RT7vJgTXqT3aoGphiGyfVr45NbAFXfOixjllpvbFKP2PMDQsAVk7Xd8NUL2TNAHPB21oBU1V62XR7CXitDQkJZfUi73iE_2mub5hBU4-rYPInYP/?imgmax=800" width="160" height="240"></a>Traditional project plans involve using <strong>calendric</strong> estimates in order to synchronize the development efforts of the team(s) by placing the work on a time line (usually, using a Gantt chart). This means that for every part of the solution, the developers must <strong>predict</strong> the when it will be ready (i.e. the delivery date). This means they need to know when they will <em>start</em>, how much time it will take to deliver the work, and how much time will be “wasted” on <strong>impediments</strong> (both foreseeable and unforeseeable). While knowing this makes the project planners’ work easier, obtaining this knowledge is extremely difficult; Estimating the development effort is difficult enough, but predicting the total amount of time that will be spent <em>not</em> developing is near impossible. </p> <p align="justify">What’s worse, is that contrary to popular belief, the <a href="http://en.wikipedia.org/wiki/Law_of_large_numbers">Law of Large Numbers</a> does <strong>not</strong> apply to project plans! Due to the nature of dependencies, <strong>a single late dependency is enough</strong> to push the delivery date of a <em>dependent</em> component. On the other hand, in order for a component to be delivered <strong>early</strong>, it is <strong>necessary that all dependencies</strong> will be completed early. In short, <strong>lateness aggregates, while earliness does not.</strong></p> <p align="justify">A side effect of this is that the more complex the Gantt based project is, the more lateness is likely to be accumulated, as the project advances, and the further we are in the project, the more we run the risk of being late.</p> <p align="justify">Of course, a late project means that the software is delivered at a <strong>higher cost</strong>, with <strong>less features</strong>, and / or simply <strong>later than expected and agreed</strong>. This means that a late project often becomes a <strong>failed</strong> project.</p> <p align="justify">Clearly, a different method of doing things is necessary; Agile methodologists came up with different estimation techniques to reduce the chances and ramifications of failure.</p> <h3>Agile Estimations Are Easier to Make</h3> <p align="justify">The three most common agile estimations are <strong>T-Shirt Sizes</strong>, <strong>Ideal Time</strong>, and <strong>Story Points</strong>:</p> <ul> <li> <div align="justify"><strong>T-Shirt Size </strong>estimations are coarse grained separation of requirements into buckets of <strong>small</strong>, <strong>medium</strong>, <strong>large</strong>, or <strong>very-large</strong> efforts. This estimate is of course extremely easy to make intuitively, and of course insufficient as a basis for project planning due to its low resolution, but is often <strong>sufficient for the purpose of pricing single features</strong> (example scenario might be when required to give a customer a <strong>cost estimate</strong> for some <strong>custom feature</strong> in the system).</div></li> <li> <div align="justify"><strong>Ideal Time</strong> estimates are similar to <em>calendric</em> estimates in that they involve high resolution predictions of the effort involved in developing a feature. The difference is that ideal estimates are made while <strong>ignoring</strong> all <strong>surprises and interferences</strong>! The question that ideal estimates answer is “how much time will it take to develop a solution, <strong>assuming you work on nothing else, and nothing else disturbs you</strong>”. Taking the <em>unknowable</em> impediment factor out of the equation improves the accuracy of the estimates, but you can’t simply substitute ideal time for calendric time because the unknown impediments <em>still</em> <em>do</em> exist, and the fact remains that humans aren’t good at making absolute estimates, with no point of reference. In Scrum, <strong>Ideal Hours</strong> are often used to estimate the effort of completing <strong>tasks</strong>, which should be short, simple and straightforward.</div></li> <li> <div align="justify"><strong>Story Points</strong> are a radically different method of estimating development effort. With story points you do not go out and say how much work something is, in and of itself, but rather state how the <strong>effort</strong> to develop one component <strong>compares</strong> to the effort of developing another. These estimates are much easier to make, and <strong>surprisingly accurate</strong> because we are <em>much better</em> at comparing things than estimating them. Of course, comparisons and relationships have <strong>no unit of measure</strong>, and thus can’t be used to establish a timeline. At least not in the normal sense. In Scrum, <strong>Story Points</strong> are usually used to estimate the effort of completing <strong>user stories</strong> (hence the name).</div></li></ul> <h3>Agile Estimation Techniques Make Better Plans</h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgCP2CxUBRR4X8sxD7w_98f9Tyi4zexzmyoiPMKXGxMLmQvY7Sf1-qlGhzLyh0NdFVHh2_9t9MpKT9EFa_4SpAnANIq1jQPHlDL4u4j3hiFOY99-toMUlMhaQ_wkELjzwqDsWj4Fn2RQ6BJ/s1600-h/image%25255B20%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px 7px 0px 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjgsU2T5h7bTRB24hedKFLf3rx2PhzgzvUebbaBe9xretHtsnPP9vCwFt-rKIeIZoAZ_jxh33SlSrygYuHjolJzgJP5dzQeKBcQAOTAUqGA6MukuyETb8_rBT2Gyr8J_W33AydypGeEV6_s/?imgmax=800" width="106" height="128"></a>While agile estimation techniques tend to end up more accurate than calendric estimates, the estimations are still guesses, and guesses still mean risk. Agile teams try to reduce this risk by reducing the amount of guesswork involved in the project plan.</p> <p align="justify">Classic project plans involve estimating the time it will take to deliver <strong>each component</strong>, and add up all the estimates to create <strong>one big guess-of-a-plan</strong>. While agile project plans involve estimating the work on each component as well, that is where the similarity <strong>ends</strong>.</p> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuqtj8CAC3ZAdEWKOv55sGbgsHmwSWXWH54jPKBmGIuZj1it7LkCxLgtGfFSmY2cNKuPFqWYJ9PHeybqaVkSmxDP8_igzudE_M73j7LPIxgAIXVjTmR6yKYSOZDAyOLbHex1Q5GSaUT1U5/s1600-h/image%25255B16%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; margin: 0px 0px 0px 6px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEigSkUqfr0houlyVp1Y24_JPEdBiamz7h8ZVZzpL7IRPjfS1cEhMTN_5Kewk8DeDlcFb5jzi89f9ifGwLfPfhnlklwJKQ6ve3v0zgOQrW16DrkA_p_Ywv3ZNgbMsCU7nXZ584Yb3UUgrPFI/?imgmax=800" width="151" height="150"></a>The agile project plan is <strong>not</strong> based on the <strong>prediction</strong> of work effort, but rather on <strong>empirical evidence</strong>! Only the team’s first iteration (<em>ever</em>) is planned based on a prediction. The rest are based on the <strong>measured</strong> evidence of <strong>previous</strong> iterations (or <em>sprints</em>, as they are often called in Scrum-shops). The team estimates that it will successfully complete as much work in the next iteration as it did in the previous iteration(s).</p> <p align="justify">For example, if a team successfully completed 120 <strong>ideal hours</strong> worth of work (that is, the amount of work they did added up to what they estimated as 120 ideal hours), then they will estimate that they will do the same in the next iteration. This technique works the same with <strong>story points</strong>: A team that can complete an average of 50 story points in an iteration is likely to repeat that success in the next one. A team’s <em>velocity</em>, or <em>cadence</em> can then be measured in <strong>ideal hours per iteration</strong> or <strong>story points per sprint</strong>.</p> <p align="justify">What about interruptions? Well here’s the beauty of the technique: You can <strong>consistently</strong> <strong>account </strong>for the predictable ones (e.g. vacations, repeat meetings, scheduled events) and factor those out, and you can <strong>consistently ignore</strong> the unplanned ones, as they are likely to be more or less an equal part of every iteration of the team.</p> <h3>Where’s the Difference?</h3> <p align="justify">The difference between <strong>predictive</strong> <strong>plans </strong>(classic, waterfall-ish, Gantt based) and <strong>empirical plans</strong> (Agile, Scrum) are:</p> <ol> <li> <div align="justify"><strong>Predictive</strong> plans are based on more <strong>estimation</strong> (i.e. guesses, i.e. risk) than empirical ones</div></li> <li> <div align="justify"><strong>Empirical</strong> plans have an <strong>increasingly sound</strong> statistical ground as the project progresses</div></li> <li> <div align="justify"><strong>Predictive</strong> plans have an <strong>increasing chance of running late</strong>, as the project progresses</div></li> <li> <div align="justify">With <strong>predictive</strong> plans the unknown factors <strong>aggregate</strong>, with <strong>empirical</strong> plans they <strong>cancel</strong> each other out.</div></li></ol> <p align="justify">Finally, as stated in the <a href="http://www.softwareandi.com/2012/01/demystifying-agile-how-to-plan-releases.html">previous post</a>, agile plans, being based on stories that are designed to be discrete units of business-value, with <strong>as little interdependencies as possible</strong>, agile plans further mitigate the risk of estimation failure by causing the ramification to be failure to deliver on time <strong>only the least valuable features</strong>!</p> <h3>In Conclusion</h3> <p align="justify">To me, the agile choice is a no brainer. Agile plans are simply safer to execute, the chance of failure is lesser, and the result is less harmful. I would even go as far as to say that companies promising to deliver a non-trivial project without using an agile plan of some sorts are being less than honest – with themselves <em>as well as</em> the customer.</p> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgwXKj-EMf3t6Z-tudL-WIFD53xRy-3CdSYcEfGARsVP3J_ClESJYlxtH4fA34OqiLKOqjHAiGo3GJ_y4cBKNkV1cLTEFaVq441LPr8jm96ZXpWScRAY3Jih71CGPbeAadDSQf_ippg8p61/s1600-h/image%25255B24%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgsmMytudNzEqokEawsoCvO7YDHXTHXCUq5fMBW-e0j7cxtlvVjXuRbW49szxhC6OeLz4PILAVOEB9DF6JSBHVYvD0JZ1erGsHhs3ZhNoZeqcpxDFDGxfjf94krqFcx_Vwvm4UMsqMPcuhE/?imgmax=800" width="226" height="151"></a>Moreover, I think it is high time that customers <strong><em>demand</em></strong> their contractors to use agile methods in order to win contracts.</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:e7090a0c-b395-4aa2-bd83-bc120f6afd0f" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Estimation" rel="tag">Estimation</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/Release+Planning" rel="tag">Release Planning</a>,<a href="http://technorati.com/tags/Sprint+Planning" rel="tag">Sprint Planning</a>,<a href="http://technorati.com/tags/Story+Points" rel="tag">Story Points</a>,<a href="http://technorati.com/tags/Ideal+Hours" rel="tag">Ideal Hours</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com8tag:blogger.com,1999:blog-2660291115609609354.post-60787324335597660082012-01-05T18:36:00.001+02:002012-01-15T14:53:54.647+02:00Demystifying Agile: How to Plan Releases with Scrum<p align="justify"> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh3-VyG2Xk39cscy_SOe4ht2GbBAmnolY6zRop3JGWz_kXwg9uoibd7hWrbyUeGtJPA9kdW8MkUw_m0RqCOuqQu_mJ096GuFgBR-8-UfVlF5Kdow0U_726G418aEHw82XlpWR_N0pZpqbxP/s1600-h/no-release-voodoo%25255B3%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="no-release-voodoo" border="0" alt="no-release-voodoo" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgG68e2I0MS4CVapxDUjpzSpElBA7TRFcFGD5wCUP3mJJ2FoKeNXKzkrBuTmN3yW3fdA88sbwhz1vC5WiH6lFTAUt9HBxluzHbER5VLgKX3W0ZjPedpLbaU1y6qCfjNo6hA0aVMBYkEy3kh/?imgmax=800" width="223" height="240"></a>The agile release process might sometimes seem like voodoo (or even <em>dark</em> voodoo) to some managers and developers, particularly those more accustomed to the traditional way of planning processes used in waterfall projects. This post will explain the inherent problems with waterfall projects, how agile methodologies such as Scrum overcome these problems, and of course, the reasons that the agile release planning method works.</p> <h3></h3> <h3>You Can’t Control Everything</h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhZ4G9BDHeJ7ETEm2XbINRq5JTr_q1fg0RzkLajQtJ8b3CjYNeZkK8JISqRME_iJ5jNMQNUqaky9d0TKTkBfUd46Iedzjh58clG6PdtD1Q-BOja0JBT3_TKs86-UzgnT068rgFlpgPy-7-U/s1600-h/image%25255B7%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: left; border-top-width: 0px; border-bottom-width: 0px; margin-left: 0px; border-left-width: 0px; margin-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="left" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjzVVOKczS8D-E8bJ8BOANInBiR8VGFWsvYnpFHrd5-OwTWSYiorGO9GOOphVxvG9go05qNa07pi392zaaiIuWR7nLOMsL4CWKjq_utu3Jpj7CyNz55RcKTDANMDmXG4N9yIUhZ_jcVecLt/?imgmax=800" width="240" height="173"></a>The <a href="http://en.wikipedia.org/wiki/A_Guide_to_the_Project_Management_Body_of_Knowledge">PMBOK</a> call it the project management triangle; the agile community call it the <a href="http://www.ambysoft.com/essays/brokenTriangle.html">Iron Triangle</a>. Regardless of the name, it is a real and hard constraint: Of the three aspects of the project – <strong>scope</strong>, <strong>resources </strong>(or cost), and <strong>time</strong> you may pick and control any <em>two</em>. The third cannot be controlled <strong>without harming the quality</strong>, and is calculated (roughly) by the following formula:</p> <p align="center"><a href="http://lh5.ggpht.com/-TEYLclLXZIY/TwsP67rGCQI/AAAAAAAAAcs/DkZ8JIZn83g/s1600-h/image%25255B3%25255D.png"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="image" border="0" alt="image" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitz8WaAHp8QAn0_eJCTtXTJ3PJpSs_aNbIqZMs9IhObcvc5YicoGUOvlunvMhyphenhyphenrmTM48sW8u76psSJpNrr7mY5Uv61iQYqN1ZMRfEs4bm9hNUB3N4ecdn87vAnm-J2bYhTa9IFuDaAikxj/?imgmax=800" width="211" height="25"></a></p> <p align="justify">This means that if you have a project where the budget is fixed, and there is a hard deadline (i.e. release date), then you cannot control the scope that will be delivered by the team by the time of the release.</p> <p align="justify">Moreover, <a href="http://en.wikipedia.org/wiki/Brooks's_law"><strong>Brook’s Law</strong></a>, states that adding people to a late (i.e. already started) project will only make it <em>later</em>. According to this, since the cost of a <strong>software project</strong> is mostly the cost of the team members, the <strong>resources must remain fixed for the project</strong> (or release).</p> <p align="justify">Nevertheless, traditional project managers seem to try to define the entire <strong>scope</strong> of a project, define the releases and milestones (i.e. the <strong>time</strong>), with a fixed preset budget (i.e. <strong>cost</strong>).</p> <p align="justify">It is simply doomed to fail. According to the <a href="http://standishgroup.com/about/index.php">Standish Group</a> and the <a href="http://www1.standishgroup.com/newsroom/chaos_2009.php">Chaos Report</a>, most projects (68 percent) do.</p> <h3></h3> <h3>Why do Projects Fail?</h3> <p align="justify">According to <a href="http://martinfowler.com/bliki/WhatIsFailure.html">Martin Fowler</a>, it is not the <em>projects </em>that fail, but rather the <em>estimates</em> that fail; it is our attempt to calculate how much time it will take to deliver a certain scope with a certain amount of resources.</p> <p align="justify">I would argue, that the failure to estimate is the <em>reason</em> that projects fail. <a href="http://www.softwareandi.com/2011/08/another-stab-at-work-estimation.html">We really don’t know how to estimate</a>. Projects fail because they <strong>rely too heavily</strong> on the estimates.</p> <h3>How do Agile Methods Reconcile with the Iron Triangle?</h3> <p>Given values such as courage and honesty, it is no surprise that agile methodologists simply acknowledge that estimation is not a good basis for a release plan, and search for alternatives.</p> <p>Given the Iron Triangle, Brook’s Law, and the fact that most customers demand a hard release date, an agile PM accepts that he cannot control the scope that will be delivered; that is, while the PM may make guesses (i.e. estimates) as to the content that will be delivered on the deadline, he cannot be sure that every last task will be completed.</p> <p>What he can promise, and make certain of, is that he will deliver <strong>the best product possible</strong> on the release date, with the <strong>rest of the desired features in consecutive releases</strong>.</p> <h3>How do Agile Methods Deliver the Best Product on Time?</h3> <p align="justify">By slicing the entire scope into vertical slices, small increments in <em>valuable</em> functionality (often called <strong>user stories</strong>), the agile PM now has a stack of user stories to be released, or a product backlog<strong>. </strong>By defining the stories in such a way that they have as few interdependencies as possible, the PM may order them as he desires. The PM will of course, choose to order them by <strong>business value</strong> to the customer.</p> <p align="justify">The development team, in turn, will swarm on each story, by order of value (priority), and focus on completely delivering one story at a time (completely means coding, testing, integrating and anything else required).</p> <p align="justify">In this way, at any given moment, including the release date, the team has a product that is shippable and is the most valuable product they <em>could</em> <em>possibly </em>develop.</p> <h3>Is the Best Product Possible Good Enough?</h3> <p align="justify">While the best product might not be everything that was envisioned, because again – that is simply not possible: not with waterfall, not with agile, not anyway – the “<strong>Best Product” will have the capabilities most valued by the customer.</strong></p> <p align="justify">The <a href=".">findings</a> of the Standish Group show that only 20% of the features in any given product are frequently used, while <strong>64% are rarely or never</strong> used. Therefore, statistically speaking, even if you only complete 36% of your scope, you may still have a good enough product!</p> <p align="justify">Of course, assuming that you aren’t slacking, and the project’s deadline isn’t insanely short, it is more likely that you will complete a significantly larger portion of your scope. It is even possible that you will have a “good enough” product that you can ship even <strong>before the deadline</strong>! There is not a single customer that will say no to reducing <strong>time to market</strong>!</p> <p align="justify">So I’d say, yes – the Best Product <em>is</em> good enough.</p> <p align="justify">And that’s how it’s done. I hope </p> <p align="justify">How about your products? Do you work this way? Are your experiences similar? Share!</p> <p align="justify">Thanks,</p> <p align="justify">Assaf.</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:215e11d6-d3e2-44dd-9ef2-435105af4296" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Estimation" rel="tag">Estimation</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/User+Story" rel="tag">User Story</a>,<a href="http://technorati.com/tags/Release+Planning" rel="tag">Release Planning</a>,<a href="http://technorati.com/tags/Sprint+Planning" rel="tag">Sprint Planning</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com1tag:blogger.com,1999:blog-2660291115609609354.post-76461384220301004242012-01-05T18:35:00.001+02:002012-02-26T19:55:11.133+02:00Demystifying Agile<p align="justify"><img style="background-image: none; border-right-width: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" border="0" align="right" src="http://lh3.ggpht.com/_7PUa1gN7wbM/SRxE_tzQgDI/AAAAAAAACsE/JF4hkAjkCuk/crystal-ball.jpg" width="158" height="144">Understanding the mechanics of Scrum is easy; otherwise there’s no way they could be taught in 16 hours, in a Certified Scrum Master <a href="http://www.scrumalliance.org/events/results?search%5Bevent_type%5D=course">class</a>. Understanding <strong><em>why</em></strong> the mechanics work is a different thing altogether. In this series of posts, I will attempt to explain how and why they work the way they do; I firmly believe that attempting to use the mechanics of scrum without understanding the Agile spirit is a recipe for failure. I hope you enjoy the series.</p> <p align="justify">Table of Contents:</p> <ol> <li> <div align="justify"><a href="http://www.softwareandi.com/2012/01/demystifying-agile-how-to-plan-releases.html">Demystifying Agile: How to Plan Releases with Scrum</a></div> <li> <div align="justify"><a href="http://www.softwareandi.com/2012/01/how-to-use-agile-estimation-in-scrum.html">How to Use Agile Estimation in Scrum Projects</a></div> <li> <div align="justify"><a href="http://www.softwareandi.com/2012/02/proving-pair-programming-how-and-why-it.html">Proving Pair Programming: How and Why it Works</a></div> <li> <div align="justify">How to Manage a Self Managing Team</div> <li> <div align="justify">Agile Contracts: Unveiling the Trick to Happy Customers</div> <li> <div align="justify">Agile Tips & Tricks: How to Solve Real Issues with Scrum</div></li></ol> <p align="justify"><em>Bookmark this page! More posts to come… </p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:f648b828-6ca3-4bb3-8000-4c921ff4e20a" class="wlWriterSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a></div></em> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com2tag:blogger.com,1999:blog-2660291115609609354.post-82604873671976314832011-12-25T11:50:00.001+02:002011-12-25T11:50:03.027+02:00A Software Developer’s New Year’s Resolution<h4 align="justify"><em>Or: 5 Things You Can Do Today to Improve Your Software Product</em></h4> <p align="justify"><a href="http://lh6.ggpht.com/-51UCCQlfCSs/TvbxwYJqyQI/AAAAAAAAAbM/p3CK5xKPuyA/s1600-h/image%25255B3%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnZRafNQYHzJFg8NV19UHE_iOcmbopZm08cT_36iY5myGg0wlwQS2-F4KcWWPMqGC52pPuUMKc2vcAStUjBFcDOswaXVBjLmS1yYV9tyGFUnea7LSmC1xIS_HRsiErIrSYb6dzKnF35dgn/?imgmax=800" width="240" height="216"></a>New Year’s eve is around the corner. It is the end of this year, and there’s a whole new year full of potential to be better, just waiting to begin. So how can <em>you </em>make it better? If you, like me, are a professional developer, then you can improve your life (and your boss’s and your team’s) by reducing software delivery related stress. Here are 5 things you can do, effective immediately, to make your product better:</p> <h3>1. Make a Version Management Plan</h3> <p align="justify">If your version control system is a mess, the first thing you should do is straighten it out. If you are not using one, then you should begin doing so immediately. There really is no excuse not to do so. For starters, there are plenty of high quality tools out there that are open source and free (<a href="http://git-scm.com/">git</a>, <a href="http://mercurial.selenic.com/">mercurial</a>, and <a href="http://subversion.apache.org/">subversion</a> are the most common ones), as well as other commercial tools (I happen to use and consult on the use of Microsoft’s <a href="http://msdn.microsoft.com/en-us/vstudio/ff637362">TFS</a>). Either download and start using a free one, or get one that offers a trial period.</p> <p align="justify">If you are using a VCS, but it’s a mess, and you find yourself mired deeply in merge-hell every time you want to deliver your software (internally <em>or </em>externally; it doesn’t matter), then you should straighten it out. Unfortunately, if you have a considerably sized source repository, this may seem as an impossible endeavor. Here’s <em>one </em>way to alleviate at least <em>some</em> of the pains of software delivery, in a few easy steps:</p> <ol> <li> <div align="justify">Create a new root-level folder named <strong>sources</strong>. This folder will contain your new source code repository. </div></li> <li> <div align="justify">Create a branch from your current repository, and call it <strong>main</strong> (e.g. <strong>/sources/main</strong>). This will represent your latest and greatest version, and should be kept as stable as possible, at any moment. No development will be done on it; you will only merge <strong>completed changes</strong> into it. </div></li> <li> <div align="justify">Create a branch from main, named <strong>dev</strong> (e.g. <strong>/sources/dev</strong>). This branch will be the branch that developers work on to <strong>create new features</strong>, checking code in and out from there. If there are multiple independent teams, you may have multiple <strong>dev</strong> branches.</div></li> <li> <div align="justify">Create a <strong>releases</strong> folder, which will contain <strong>release branches</strong> from main. Every time you wish to release your software (internally or externally), create a <em>release branch </em>from main (e.g. <strong>/sources/releases/1.2</strong>).</div></li></ol> <p align="justify">This is just one possible branching plan. It works particularly well for agile development, where effort is made towards developing as many features as possible before a release, merging them into main when ever they are <strong>done</strong>, and branching when the iteration is over. Note the following division of work:</p> <ul> <li> <div align="justify">New features are developed <u>only</u> in <strong>dev</strong>. They are merged <em>back</em> into main when completed.</div></li> <li> <div align="justify">Fixes are developed on release branches and <em>reverse-integrated</em> into <strong>main</strong>, and then back to <strong>dev</strong>, so that they won’t get lost.</div></li></ul> <p align="justify">This structure allows you to develop new software and stabilize a release at the same time without one effort polluting another. It is also a step towards being able to release a new version <em>anytime</em>.</p> <p align="justify">If your development and release mechanism is well established, but not suited to fit this branch plan, make one that does work. Just make sure to be able to support <strong>feature and fix separation</strong> as well as the ability <strong>release anytime</strong> you need.</p> <h3>2. Automate Your Build</h3> <p align="justify">Even if all you do is copy sources from the repository to some drop folder, you have <em>some</em> sort of a build process. Automate it. Even just a part of it. Even just the compilation phase. Every step you let a computer do rather than yourself, is one less step to worry about. If you aren’t already using an automated build tool, you should start now. There are many open source tools as well as commercial ones. Most are powerful enough to suit your needs. Remember – If you can run it from command line, you can automate it as well.</p> <p align="justify">Every time you run the build, you will not only create a deployment package of your system, but you will get a good indication about the health of your product (if the product doesn’t build, you will want to know sooner rather than later). Additionally, you will have the start of a platform for testing the system.</p> <p align="justify">For a synergetic benefit with your versioning plan, schedule the following automated builds:</p> <ul> <li> <div align="justify">Build the software every time you check in changes to your code (on <strong>dev</strong> or a <strong>release</strong> branch); most build and VCS tools support this – it is called <strong>continuous integration</strong>.</div></li> <li> <div align="justify">Build the software every time you wish to merge <strong>dev</strong> to <strong>main</strong>. It is even better if you require a successful build as a <strong>prerequisite</strong> for the merge. This is called a <strong>gated check-in</strong> in many tools. </div></li> <li> <div align="justify">Schedule a nightly build on <strong>main</strong>. This will let you know what the state of your system is. Fix any problems here first. Keeping a healthy build will allow you to deliver software at the drop of a hat. Amaze your PM!</div></li></ul> <h3 align="justify">3. Add a Health Report</h3> <p align="justify">Even a simple email message to the team in case a build fails will greatly improve your ability to fix problems with your software. Shorter feedback cycles means that you can <strong>fix problems when their causes are still fresh in your mind!</strong> Let your build system email you if it fails. Almost every system supports it. Conversely, you may wish to post <strong>successful </strong>build reports to some company wiki. Let everyone know of your successes. </p> <h3>4. Add an Automated Test</h3> <p align="justify">While the benefits of TDD as a design mechanism are far greater than just having a suite of tests, we should not belittle the benefit of an automated regression test. Even a simple <strong>record & replay</strong> automated smoke test, with a black-box test tool will greatly improve your system. Start with a single test that runs through as many parts of your system as you can easily manage. (Note – this might mean you need to add a <strong>deployment</strong> action to your automated build). Report if it fails. Run it every time you build. <strong>The more tests you add, the greater confidence you’ll have in your build system!</strong> Maintain your tests; fix any tests that fail due to legitimate changes and remove those that are no longer relevant. You don’t want your system to cry wolf!</p> <h3>5. No Broken Windows!</h3> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiPRTNte9XsWvlIPKwPxbtxBGhiZ4yEWUgJvA3x0lPWtsHBF7dGQabZceaZLk0DVAxWjIhF0jsTvY_MIv-z0BMHHOiDlFFC4p639izioX2I82ElTD_zbTTc3iojDa3TPTbVNt3L9YKzhBkv/s1600-h/image%25255B7%25255D.png"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="image" border="0" alt="image" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgnTjxvd5fI7h3-e_6cntjisBRNfccnn5hid5MgzKhnhjC2BcTLY_Flz_SaBtu1wCKn7vue7RuVzUSMd5V-OBWWgWj3ONUfkXBGF5BTwze7Ak9eph8bEdywRwjBvlimvci0RP3wYhVdLdYh/?imgmax=800" width="76" height="90"></a>The most important thing you can do is to make a new year’s resolution that you will <strong>not suffer any problem with your software delivery lifecycle to remain unfixed!</strong> Once you fall off the wagon, your system will start to decay back to uncontrollable chaos. Think of maintaining your ALM like <strong>brushing your teeth</strong>. You may not like it but you do it every day (more than once), or your teeth will rot out until ultimately you won’t be able to eat!</p> <h4>In conclusion,</h4> <p align="justify">My new year’s resolution is to vigilantly keep my teams’ products “on the wagon”.What is yours?</p> <p align="justify">Happy Holidays, and Happy New Year!</p> <p align="justify">See you all next year,</p> <p align="justify">Assaf.</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:2a12d23c-948d-492a-8436-270c5b45e1af" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Build" rel="tag">Build</a>,<a href="http://technorati.com/tags/TDD" rel="tag">TDD</a>,<a href="http://technorati.com/tags/Test" rel="tag">Test</a>,<a href="http://technorati.com/tags/Report" rel="tag">Report</a>,<a href="http://technorati.com/tags/Version+Control" rel="tag">Version Control</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com1tag:blogger.com,1999:blog-2660291115609609354.post-90157506985558497622011-12-10T09:02:00.001+02:002011-12-11T06:38:24.602+02:00How to Measure Technical Debt<h5><em>Or: An Executive’s Guide to the Cost of Software Architecture Shortcuts</em></h5> <p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjgd6w6WSoyQW7n2g8NTHaCBeo3ChMTYCCj-8ry_00Ta_VZL5GzLxytXos_kKQnstL8FU4QHd01QPxzanx5HTXsigUn3gc9f1LBFHXgtcm-ganb9mBNn4in_-Or-maQWTjNGlwBrqAg7Kqu/s1600-h/poor-monopoly-guy-290x280%25255B4%25255D.gif"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="poor-monopoly-guy-290x280" border="0" alt="poor-monopoly-guy-290x280" align="right" src="http://lh5.ggpht.com/-RIv947t_n3o/TuQzvPoYunI/AAAAAAAAAaw/irzO0VyekL0/poor-monopoly-guy-290x280_thumb%25255B2%25255D.gif?imgmax=800" width="156" height="151"></a>In my experience, in any software project of sufficient complexity, it is necessary to cut corners in the software architecture. These shortcuts are decision that you make <em>now</em> so that you will be able to release your next version of the software that much earlier; these shortcuts are the result of not having enough time to do things “right”.</p> <p align="justify">This is called your project’s <a href="http://martinfowler.com/bliki/TechnicalDebt.html">Technical Debt.</a></p> <p align="justify">Like <em>financial debt</em>, which is the metaphor used to explain it, technical debt happens when you “buy” more software features than you have resources (developers and time) for. Like financial debt, it accrues interest over time. And like financial debt, if you don’t pay it back, you may eventually get foreclosed and go bankrupt. That last part is not a metaphor. Your software project simply ends up costing more to maintain than the value you derive from it, and either the project or the company gets shut down, or both.</p> <p align="justify">There are essentially two ways to deal with debt (technical, like financial):</p> <ol> <li> <div align="justify">You pay it all at once – This means that you do not “withdraw” any more features, until your debt has been fully paid. It has the benefit of being able to make a fresh start. It has the disadvantage of risking “starvation” while you try to pay the “bank”.</div> <li> <div align="justify">You pay it in installments – This means that you pay off your debt, a small part at a time, still “withdrawing” features, but less than you normally would, cutting down to essentials, for as long as you are still paying off the debt. It takes longer to finish, but you can still “eat” while paying.</div></li></ol> <p align="justify">Of course there’s the third option of continuing to withdraw as before, until you go broke, or luckily win the ‘lottery” (investment, buy-out, etc.)</p> <p align="justify">There is no one clear way to deal with debt (financial or technical). It will depend on the situation, and the players. And most of all it will depend on the <strong>amount</strong> of debt.</p> <h3 align="justify">Quantifying the Debt</h3> <p align="justify">With financial debt, it is easy to determine how much you owe. There’s the amount of money you borrowed, and the interest rate. Both are usually well known, and it is just a matter of keeping track of it, to make sure you can withstand it.</p> <p align="justify">With <em>technical debt</em>, you still have the <em>amount </em>you borrowed, and the <em>interest rate</em>, but you usually <strong>don’t know the numbers</strong>. </p> <p align="justify">Let’s start with figuring out the <strong>derived value</strong> of taking the loan. Whenever you demand that a feature or set of features be completed faster than it would normally take if the team were to maintain an appropriate quality level, you are “borrowing” from the <strong>architecture</strong>. Figure out how much <strong>time</strong> you saved, and multiply it by the <em>hourly cost </em>of the developers. That is the <strong>amount of money</strong> you borrowed from the architecture. Figure out what the <strong>reduction in the <em>Time to Market</em></strong> will earn you, and that is the <strong>derived value</strong> of the loan.</p> <p align="justify">The interest rate is not so easily calculated <em>a-priori</em>, but it can be estimated (with about as much accuracy as the development cost estimates your team makes – which may be good or bad; depends on your experience):</p> <ol> <li> <div align="justify">Map out the areas impacted by the shortcut</div> <li> <div align="justify">Estimate how much it would cost (developers x time) to develop a feature in the impacted areas, <strong>before the shortcut(s)</strong></div> <li> <div align="justify">Now, estimate the cost to develop the same feature <strong><em>after</em> introducing the technical debt</strong></div></li></ol> <p align="justify">The <em>difference</em> in the cost is the <strong>interest</strong> you are paying. <strong>Keep track</strong> of the interest as it will change with every change you make to the system. A good practice is to calculate the interest every iteration or sprint. You should consider doing this as part of the <a href="http://www.mountaingoatsoftware.com/scrum/sprint-planning-meeting"><strong>sprint planning</strong></a>. This will have the added benefit of giving the product owner the opportunity to pay off some of the debt. </p> <p align="justify">Note that like financial debt, the interest grows over time. The rate varies, and it is difficult to guess what it will be, except by projecting based on past experience. As you begin to accumulate this data, you will be able to make educated decisions on when you <strong>can afford</strong> to go into <em>technical debt</em>, and when you should <strong>avoid </strong>it. You should reassess your <strong>technical debt’s interest rate </strong><em>every</em> <strong>sprint planning</strong>.</p> <p align="justify">Armed with this knowledge, developers should now be able to collaborate with management in order to decide how to develop and whether or not it is okay to cut a corner on that next feature.</p> <p align="justify">Finally, remember: Your architecture is a <strong>cold blooded loan shark</strong>, who will just as soon take your installments, as he will bust your project’s kneecaps over a missed payment.</p> <p align="justify">What do you think? Do you have a preferred method of calculating / estimating technical debt, or a way to handle it? </p> <p align="justify">Please share!</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:5550351d-abba-40d1-9931-1fc317086120" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Estimation" rel="tag">Estimation</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/Sprint+Planning" rel="tag">Sprint Planning</a>,<a href="http://technorati.com/tags/Technical+Debt" rel="tag">Technical Debt</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com5tag:blogger.com,1999:blog-2660291115609609354.post-10486895603750167322011-12-07T18:29:00.001+02:002011-12-23T10:04:39.865+02:0010 Reasons to Avoid Test Driven Development<p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg7qy6E_WAqkwdbOC-6vHtAL27lslxORvSQFat5-pyaBJV0yWjfIvADEdGQFNzMzDEc38VP3s1Dt-KZNo2X0Bu4zjgBVT_auqpbFNORSSTywM5vrJXPnpPXf5d-O-aLmTgwXjv3hHYJbmNZ/s512/no-TDD%25255B3%25255D.png?imgmax=800"><img style="background-image: none; border-right-width: 0px; margin: 0px 0px 0px 5px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top-width: 0px; border-bottom-width: 0px; border-left-width: 0px; padding-top: 0px" title="no-TDD" border="0" alt="no-TDD" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhHxzCfgfXOHCu_lcYFTTsdM6h1voCl2sCl-CbD4U3gOR0E3w2rNX7XR-_L3w3WrXddgHAyAmRv95hfrYtufk9TQW9Z4SyimJNYxYdm3XlCKWAqNAUysQwC6JpAE5wRNRzHQQvwCv1q-uFj/s512/no-TDD_thumb%25255B1%25255D.png?imgmax=800" width="240" height="184"></a>Test Driven Development (TDD), and all of its derivatives (BDD, ATDD) are, in my opinion great methods to drive a team’s development efforts, and raise the quality of the product. But TDD is not a silver bullet. It doesn’t fit every project. The following post lists the top ten reasons <strong>not</strong> to write automated tests for your code.</p> <p align="justify"> </p> <p align="justify">If one or more of these conditions apply to you, you should consider forgoing TDD, and in fact any agile techniques, as they will be a waste of effort:</p> <h3 align="justify"><strong>10. There is no client</strong></h3> <p align="justify">Sometimes you are developing a product that will not be used by anyone. In this case, any effort expended on raising the quality is a complete waste. Nobody will care.</p> <h3 align="justify"><strong>9. The client is an avid tester</strong></h3> <p align="justify">Some people love nothing more than to beta-test new software. The joy of finding new bugs and trying to figure out what went wrong is what they live for. Others are scientists at heart, and love trying to go over stack traces, in order to reverse-engineer the code. If your client happens to be one of those, then writing automated tests will take all the fun out of using your software. Don’t do it!</p> <h3 align="justify">8. The project is short, simple and straight-forward</h3> <p align="justify">If your team can complete the project in a short period of time (no more than a few weeks), and will <strong><em>never, ever</em></strong> have to reopen it for maintenance, then the benefits of<strong> maintainability, reusability and extensibility</strong> will be lost on you. Spending time and effort on these values is wasteful.</p> <h3 align="justify"><strong>7. Your architecture is perfect</strong></h3> <p align="justify">If there is no way to improve your architecture, then there is no need for it to be extensible. TDD, by the nature of its incremental development flow, forces the architecture to be extensible, simply by making you extend it as you go, and this, like lipstick on a pig, is something you just don’t need.</p> <h3 align="justify">6. Your documentation is perfect</h3> <p align="justify">You never miss an API, and any change you make to your software gets documented instantaneously. The tests you create with TDD serve as a form of documentation, an example of how to use the API. Properly named and written tests actually explain the context of the test, so it is easy to find the test that shows you what you need to understand. <em>Your</em> documentation is so complete, that writing tests are a clear violation of the <a href="http://c2.com/cgi/wiki?DontRepeatYourself">DRY principle</a>, so you should clearly avoid tests.</p> <h3 align="justify">5. Your team never changes and all members’ memories are perfect</h3> <p align="justify">The collective memory never forgets a single line of code it wrote, nor what the context was when writing it. You therefore, do not need the tests to remind you what the code does, why it does it, or how to use it. This also means that your team members <strong>never leave</strong>, nor are any <strong>new members recruited</strong>, because if this were to happen, you’d lose memories, or have members who don’t remember the code (having not been there when it was written). If this is the case, don’t bother with tests; they will just interfere with your incredible velocity.</p> <h3 align="justify">4. “Done” means the code is checked in</h3> <p align="justify">Many teams have a <a href="http://www.allaboutagile.com/definition-of-done-10-point-checklist/">definition of done</a> (DoD) that means that the feature is “done” when it is in a state that the end user can receive and run (coded, tested, deployed, documented, etc.). Many others however, your team included, prefer a simpler and more easily achieved definition that accepts “checked in” as “done”. For you it is sufficient that the developer declared that he or she completed his part, and anything else is someone else’s responsibility. If you don’t need the code to be tested for the product owner / manager / user to accept it, then you are better served moving on to the next feature as soon as you can, instead of dragging on your relationship with <em>this</em> feature.</p> <h3 align="justify">3. You’re paid to code, not test</h3> <p align="justify">Ignoring the fact that unit tests are code (sophistry), testing is what we have testers for. Perhaps your team's testers are fast enough that they can run tests on your code and give you <strong>feedback</strong> within mere moments, pinpointing the areas where you broke the code, so you can fix it while the changes are fresh in your mind, as well as a complete regression suite on the product, in case you broke something in a different component every night (they don’t mind working nights; they love the peaceful quiet). Good for you, cherish those testers, and make sure they have enough work so they won’t get bored and move on to a more challenging company.</p> <h3 align="justify">2. Debugging doesn’t count, and testing takes too long</h3> <p align="justify">Like with any competitive company, your team must deliver on time, which means they must make estimates on the time it will take to deliver. Since your <strong>DoD</strong> doesn’t include testing, and you probably can’t guess how long it will take to debug the feature, what with all the cycling back and forth from development to QA, you estimate how long it will take to <em>code</em> it. If you want to meet your commitment, you can’t be adding a <strong>20% overhead</strong> to your delivery time or you’ll miss the deadline. Worse, if you add 20% to your estimates, your manager might call you out on padding the estimates, which is his job. If that happens, who knows what might happen? Better play it safe. </p> <h3 align="justify">1. It’s just a theory</h3> <p align="justify">Like Evolution (and Gravity), it’s just a theory. Even if all of the above reasons weren’t valid, nobody has ever successfully proven that <strong><em>this product </em></strong>could be completed faster and with better quality using new-age development methodologies like TDD. It’s just a matter of opinion.</p> <h3 align="justify"><em>Test yourself</em></h3> <p align="justify">Now, to test whether or not you should use test driven development, go over the above list. Count how many reasons apply to you. If you scored <strong>ten</strong> points, don’t use TDD. In fact, if you scored more than <strong>one</strong> (reason #8 might actually be legitimate), <em><strong>don’t write any code at all.</strong></em> Perhaps you’d be better served choosing a career that has fewer unknowns and moving parts. Perhaps paving roads? </p> <p align="justify"><em><font color="#0000ff">Disclaimer: This post was written… Aw, just figure it out yourself!</font></em></p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:9521dc30-04ab-4089-85a3-1fb02dcd3461" class="wlWriterSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/TDD" rel="tag">TDD</a>,<a href="http://technorati.com/tags/Estimation" rel="tag">Estimation</a>,<a href="http://technorati.com/tags/Unit+Tests" rel="tag">Unit Tests</a>,<a href="http://technorati.com/tags/Definition+of+Done" rel="tag">Definition of Done</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com61tag:blogger.com,1999:blog-2660291115609609354.post-29500733880162881972011-11-25T15:32:00.001+02:002011-11-26T19:50:16.284+02:00How to Break a User Story into Tasks<p align="justify"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiCPhRriWxSD-lFrQBIWZpNB1AmkG4s8oYbcirDjNYVYGxeCj6OPfrdtkcuxd3zKK9lTebXIQhgZkoC8x0-tvibe_PVfFTfYGr_Si3sd9B-Azg6rzs0Cuxz2mT1xL91P9wfwYSzThCA8RCs/s1600-h/ScrumBoard%25255B2%25255D.jpg"><img style="background-image: none; border-bottom: 0px; border-left: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: right; border-top: 0px; border-right: 0px; padding-top: 0px" title="ScrumBoard" border="0" alt="ScrumBoard" align="right" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhVHHiTOqNPP1Nvn2P9qWTAhHKRs8EOLxOhOO8D9AdPwQWEu_oJCqIbCfD00XtztsySemUWenO6h_8mDiunnkBSEIX6hOeW_Da9RJycu5pQcKVGEKlf2_mHTBuqnZwSW7XyPhqvw0WWIkX2/?imgmax=800" width="244" height="118"></a>One of the vaguest aspects of Scrum is breaking stories into tasks, which is done in (the second half of) the Sprint Planning. Most of the questions I get when training or coaching boil down to one question: “How do I break a user story into tasks”?</p> <h3></h3> <h3>Defining The Problem</h3> <p align="justify">My favorite definition for a user story is that it is a <strong>thin, vertical slice of functionality, describing a small increment in value to the user (or customer)</strong>. </p> <p align="justify">A task, on the other hand is a <strong>step taken by the development team, required to fulfill the requirements of the user story</strong>. I further like to define, as a rule of thumb, that a task should take half a day to 2 days to complete. </p> <p align="justify">The question therefore should be <strong>what are the steps the team needs to take for the story to be considered complete?</strong></p> <h3 align="justify">Look at Your Architecture</h3> <p align="justify">Explicitly or implicitly, your project has an architecture. It might be anything from a master piece drawn out in painstaking elaboration by a the architecture team, to a high-level conceptual architecture diagram. You should look at the components in your system, and ask your self <strong>which components</strong> do you need to modify (or add) for the story. </p> <p align="justify">For example, Let’s say that we have a product that is a social networking web site of some sorts. given a story such as <strong>In order to broaden my network, as a user, I want to be able to import contacts from Gmail</strong>. Looking at a typical architecture for such a product, my tasks could be something like:</p> <ul> <li> <div align="justify">Add a new <strong>Import Contacts</strong> page</div></li> <li> <div align="justify">Add a service to <strong>get contacts from Gmail</strong></div></li> <li> <div align="justify">Modify the <strong>contact</strong> class to accommodate Gmail specific data (let’s assume such exists)</div></li> <li> <div align="justify">Modify the <strong>contacts data schema</strong></div></li></ul> <p align="justify">Assuming these tasks are <em>right-sized</em> (4-16 hours), that’s it. If one of these tasks is bigger, break it down. If a task is smaller, merge it with a related one (if such exists. If not, don’t sweat it. My 4-16 rule is just a guideline). We now have all the tasks for us to complete the <em>coding</em> of the story.</p> <h3 align="justify">Look at the Definition of Done</h3> <p align="justify"> Of course, just <em>coding</em> your story isn’t sufficient for the story to be truly done. In Scrum, “done” means ready to ship, or as I like to define it: <strong>the story is as it will be received by the customer / user</strong>. Agile teams have a list of requirements that should be true for <em>any</em> story they complete. You should look at <em>your</em> <strong><a href="http://www.allaboutagile.com/definition-of-done-10-point-checklist/">Definition of Done</a> (DoD) </strong>to see what tasks remain.</p> <p align="justify">For example, let’s say your <strong>DoD </strong>includes the following:</p> <ul> <li> <div align="justify">Code Complete</div></li> <li> <div align="justify">Automated UAT (User Acceptance Tests)</div></li> <li> <div align="justify">Documentation is updated</div></li> <li> <div align="justify">Added to shipping package (e.g. InstallShield)</div></li></ul> <p align="justify">In this case, you should add tasks that help you achieve the story’s DoD. For the above example you might do the following:</p> <ul> <li> <div align="justify">Write UATs for the story</div></li> <li> <div align="justify">Document the <em>Contacts Import </em>feature</div></li></ul> <p align="justify">Assuming you didn’t have to add any new assemblies (i.e. libraries, packages, DLLs, executables, etc.), to your installation, you probably wouldn’t have any need to modify your packaging tool. No need to add a task for that.</p> <h3 align="justify">That’s It!</h3> <p align="justify">You now have 6 tasks for the story:</p> <ul> <li> <div align="justify">Add a new <strong>Import Contacts</strong> page</div></li> <li> <div align="justify">Add a service to <strong>get contacts from Gmail</strong></div></li> <li> <div align="justify">Modify the <strong>contact</strong> class to accommodate Gmail specific data (let’s assume such exists)</div></li> <li> <div align="justify">Modify the <strong>contacts data schema</strong></div></li><!--EndFragment--></ul> <ul> <li> <div align="justify">Write UATs for the story</div></li> <li> <div align="justify">Document the <em>Contacts Import </em>feature</div></li><!--EndFragment--></ul> <p align="justify">You can now estimate how much time each one will take, and are ready to move on, and break down the next story.</p> <div style="padding-bottom: 0px; margin: 0px; padding-left: 0px; padding-right: 0px; display: inline; float: none; padding-top: 0px" id="scid:0767317B-992E-4b12-91E0-4F059A8CECA8:db83f4ac-aea1-4780-8791-067b86f135d2" class="wlWriterEditableSmartContent">Technorati Tags: <a href="http://technorati.com/tags/Agile" rel="tag">Agile</a>,<a href="http://technorati.com/tags/Scrum" rel="tag">Scrum</a>,<a href="http://technorati.com/tags/Tasks" rel="tag">Tasks</a>,<a href="http://technorati.com/tags/Sprint+Planning" rel="tag">Sprint Planning</a>,<a href="http://technorati.com/tags/User+Story" rel="tag">User Story</a>,<a href="http://technorati.com/tags/Definition+of+Done" rel="tag">Definition of Done</a></div> Assaf Stonehttp://www.blogger.com/profile/14023994489658711542noreply@blogger.com8