<p>Technical Debt <a href="http://www.martinfowler.com/bliki/TechnicalDebt.html" rel="noreferrer">via Martin Fowler</a>, <a href="http://forums.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx" rel="noreferrer">via Steve McConnell</a></p>

<p>YAGNI (You Ain't Gonna Need It) <a href="http://en.wikipedia.org/wiki/You_Ain%27t_Gonna_Need_It" rel="noreferrer">via Wikipedia</a></p>

<p>BDUF (Big Design Up Front) <a href="http://en.wikipedia.org/wiki/BDUF" rel="noreferrer">via Wikipedia</a></p>

<p>UPDATE: To clarify the question, I think I can also state it this way and keep my meaning:</p>

<p><em>"In what ways do you, as an Agile practioner, find the right balance between "quick and dirty" (unintentionally risking Technical Debt while attempting to adhere to YAGNI) and over-engineering (BDUF) <strong>within</strong> each iteration?"</em></p>

[{'answer_id': 60902, 'author': 'maccullt', 'author_id': 4945, 'author_profile': 'https://Stackoverflow.com/users/4945', 'pm_score': 1, 'selected': False, 'text': '<p>I find Robert Martin\'s <a href="http://butunclebob.com/ArticleS.UncleBob.TheThreeRulesOfTdd" rel="nofollow noreferrer">Test Driven Development</a> \n(TDD) approach helps with these concerns.</p>\n\n<p>Why?</p>\n\n<ul>\n<li>You only have to write enough code to pass the next test.</li>\n<li>I think testable code is cleaner.</li>\n<li>The design has to feed into tests which can help keep the design focused.</li>\n<li>When you do have to change (refactor) you have tests to fall back on</li>\n</ul>\n\n<p>Regardless of when the test are written (before or after) I find writing \nthe test helps you make practical decisions. E.g., we picked design A or B because \nA is more testable.</p>\n'}, {'answer_id': 60903, 'author': 'Jorge Córdoba', 'author_id': 2695, 'author_profile': 'https://Stackoverflow.com/users/2695', 'pm_score': 0, 'selected': False, 'text': '<p>That\'s why it\'s always easier to write nice "acadamic papers" talking about how Agile development is good, what are the "best practices" and so on.</p>\n\n<p>That\'s why you find a lot of "suited engineers" making up new software engineering techniques.</p>\n\n<p>Process is important, keeping best practices is cool but over any other thing, common sense drive design process. Software is developed by people so YAGNI really should be: </p>\n\n<p>I might not gonna needed but maybe I will because in my concrete bussiness/company/department this thing do happen or I will need it but I just haven\'t the time right no so quick and dirty hack to make the cash and keep my job, or I might need it and refactoring later will be a pain in the ass costing 10 times more than just doing it now from the scratch, and I have the time NOW.</p>\n\n<p>So use your common sense, trust it or trust the common sense of the people working for you. Don\'t take every academic paper as proven fact, experience is the best teacher and your company should improve their way or making things with time and its own experience.</p>\n\n<p><strong>Edit:</strong> Incidentally, TDD is the opposite of YAGNI you\'re building test before even knowing if you are gonna need them. Seriously, stop listening to academics!! There\'s no magical way to produce software.</p>\n'}, {'answer_id': 60916, 'author': 'Leigh Caldwell', 'author_id': 3267, 'author_profile': 'https://Stackoverflow.com/users/3267', 'pm_score': 1, 'selected': False, 'text': "<p>The 'traditional' XP answer is refactoring combined with automated unit testing.</p>\n\n<p>But it's a very interesting question philosophically. I don't believe you need to <em>avoid</em> technical debt, just keep it at a manageable level. Steve McConnell's article is good on this balance - the reason the analogy works is that it's normal and acceptable to build up financial debt in a company, as long as you accept the costs and risks - and technical debt is fine too.</p>\n\n<p>Maybe the answer itself also lies in the principle of YAGNI. You Ain't Gonna Need the technical debt paid off until you do, and that's when you do the refactor. When you're doing substantial work on an area of the system with technical debt, take a look at how much short-term difference it will make to do the redesign. If it's enough to make it worthwhile, pay it off. McConnell's suggestion of maintaining a debt list will help you to know when to make this consideration.</p>\n\n<p>I don't suppose there is an absolute answer to this - like many things it's a judgment call based on your experience, intuition and your analysis in each particular situation.</p>\n"}, {'answer_id': 60947, 'author': 'Rob Wells', 'author_id': 2974, 'author_profile': 'https://Stackoverflow.com/users/2974', 'pm_score': 0, 'selected': False, 'text': '<p>Surely being agile is going to keep your TD down for any given project?</p>\n\n<p>The fact that you are implementing what the customer wants, i.e. with their feedback, is keeping TD to a minimum,</p>\n'}, {'answer_id': 61464, 'author': 'Jack Bolding', 'author_id': 5882, 'author_profile': 'https://Stackoverflow.com/users/5882', 'pm_score': 2, 'selected': False, 'text': '<p>There was an interesting discussion of Technical Debt based on your definition of done on HanselMinutes a couple of weeks ago -- <a href="http://www.hanselminutes.com/default.aspx?showID=137" rel="nofollow noreferrer">What is Done</a>.  The basics of the show were that if you re-define \'Done\' to increase perceived velocity, then you will amass Technical Debt.  The corollary of this is that if you do not have a proper definition of \'Done\' then you most likely are acquiring a list of items that will need to be finished before release irrespective of the design methodology.</p>\n'}, {'answer_id': 74367, 'author': 'Steve Duitsman', 'author_id': 4575, 'author_profile': 'https://Stackoverflow.com/users/4575', 'pm_score': 2, 'selected': False, 'text': '<p>It seems that if you stick with the "plan, do, adapt; plan, do, adapt" idea of agile (iterations, iteration reviews) you would avoid those things by default.  BDUF is just so contrary to the idea of <a href="https://rads.stackoverflow.com/amzn/click/com/0131479415" rel="nofollow noreferrer" rel="nofollow noreferrer">agile estimating &amp; planning</a> that if you are really agile, you wont be BDUF automatically.</p>\n\n<p>The purpose of release &amp; iteration planning meetings is to make sure you are adding the most valuable features to the project for that iteration.  If you keep that in mind, you\'ll avoid YAGNI for free.  </p>\n\n<p>I would very strongly recommend the Mike Cohn books on agile planning:</p>\n\n<ol>\n<li><a href="https://rads.stackoverflow.com/amzn/click/com/0321205685" rel="nofollow noreferrer" rel="nofollow noreferrer">User Stories Applied</a> </li>\n<li><a href="https://rads.stackoverflow.com/amzn/click/com/0131479415" rel="nofollow noreferrer" rel="nofollow noreferrer">Agile Estimating and Planning</a></li>\n</ol>\n\n<hr>\n\n<p><strong>Update:</strong>  After your clarification about avoiding YAGNI and BDUF within an iteration...</p>\n\n<p><strong>BDUF</strong>...If I felt a feature was not clearly defined before I started work on it, I would create a small "feature" or story to account for the design type portion of the work needed.  So that maybe the smaller story has a <a href="http://en.wikipedia.org/wiki/Story_points" rel="nofollow noreferrer">story point</a> estimate of 1 instead of the real feature\'s 5.  That way, the design is time-boxed into the smaller story, and you will be driven to move on to the feature itself.</p>\n\n<p>To avoid <strong>violating YAGNI</strong> I would work to be very clear about what the customer expects for a feature within an iteration.  Only do work that maps to what the customer expects.  If you think something extra should be added, create a new feature for it, and add it to the <a href="http://en.wikipedia.org/wiki/Scrum_(development)#Documents" rel="nofollow noreferrer">backlog of work</a> to be done.  You would then persuade the customer to see the benefit of it; just as the customer would push for a feature being done at a certain point in time.  </p>\n'}, {'answer_id': 76038, 'author': 'ddaa', 'author_id': 11549, 'author_profile': 'https://Stackoverflow.com/users/11549', 'pm_score': 2, 'selected': False, 'text': '<p>You seem to say that "YAGNI" implies "quick and dirty". I do not see that.</p>\n\n<p>As an agile programmer, I practice test-driven development, code review and continuous integration.</p>\n\n<ul>\n<li>Test-driven development (TDD), as a process, is a good way to avoid YAGNI. Code that\'s just there "in case it will be useful" tends to be untested and hard to test.</li>\n<li>TDD also largely removes the compulsion to BDUF: when your process is to start by sitting down and start doing something that actually delivers value, you cannot indulge in BDUF.</li>\n<li>TDD, as a design practice means that the big design will emerge as you gain experience with the problem, and refactor real code.</li>\n<li>Continous integration means that you design your process so your product is essentially releasable at any time. That means that you have a integrated quality process that tries to prevent the quality of the mainline from dropping.</li>\n</ul>\n\n<p>In my experience, the main forms of technical debt are:</p>\n\n<ul>\n<li>Code not covered by the automated test suite. Do not allow that to happen, except for very localized components that are especially hard to test. Untested code is broken code.</li>\n<li>Ugly code that violates the coding standard. Do not allow that to happen. That is one of the reasons why you need to build code review into the continous integration process.</li>\n<li>Code and tests that smell and need refactoring to be more easily modified or understood. This is the benign form of technical debt. Use your experience to know when to accumulate it, and when to repay it.</li>\n</ul>\n\n<p>Not sure if that answered your question, but I had fun writing it.</p>\n\n<blockquote>\n  <p>Troy DeMonbreun commented:</p>\n  \n  <blockquote>\n    <p>No, that wasn\'t my point... "quick and dirty" = (unintentionally risking Technical Debt while attempting to adhere to YAGNI"). That does not mean YAGNI is only quick and dirty. The phrase "quick and dirty" is what I used to quote Martin Fowler in his description of Technical Debt</p>\n  </blockquote>\n</blockquote>\n\n<p>Avoiding <a href="http://c2.com/xp/YouArentGonnaNeedIt.html" rel="nofollow noreferrer">YAGNI</a> is another way of saying <a href="http://en.wikipedia.org/wiki/KISS_principle" rel="nofollow noreferrer">KISS</a>. YAGNI increases the <a href="http://www.martinfowler.com/bliki/TechnicalDebt.html" rel="nofollow noreferrer">technical debt</a>. There is no tension between between avoiding YAGNI and keeping the technical debt low.</p>\n\n<p>I think I might still be missing the point of your question.</p>\n'}, {'answer_id': 387807, 'author': 'John Rayner', 'author_id': 46473, 'author_profile': 'https://Stackoverflow.com/users/46473', 'pm_score': 1, 'selected': False, 'text': '<p>Just do the <a href="http://www.xprogramming.com/Practices/PracSimplest.html" rel="nofollow noreferrer">simplest thing that works</a>. I agree with Ayende when he says that <a href="http://ayende.com/Blog/archive/2008/12/21/the-tests-has-no-value-by-themselves-my-most-successful.aspx" rel="nofollow noreferrer">the key to being agile</a> is to "ship it, often". A regular release cycle like this will mean that there is no time for BDUF and it will also dissuade developers from violating YAGNI.</p>\n'}, {'answer_id': 1506504, 'author': 'JB King', 'author_id': 8745, 'author_profile': 'https://Stackoverflow.com/users/8745', 'pm_score': 1, 'selected': False, 'text': '<p>Where I work, I believe the way we avoid the debt is by spinning through the cycle quickly, i.e. showing functionality to the would be end user and get either a sign off that it should be pushed to test or a rejection to say what was wrong giving an updated requirement.  By doing this repeatedly within an iteration, a lot of changes can be found about what the user wants by trying this and that.  </p>\n\n<p>A key point is to try to do exactly what the user wants as doing more violates YAGNI and brings in BDUF while the idea of refining the requirements over and over again is at the heart of Agile to my mind.</p>\n'}, {'answer_id': 45579080, 'author': 'Brad G.', 'author_id': 8396288, 'author_profile': 'https://Stackoverflow.com/users/8396288', 'pm_score': 0, 'selected': False, 'text': "<p>The problem may actually be at a higher level: with management and product owners concerned with deadlines as opposed to the developers themselves.</p>\n\n<p>At my last place of employment, I worked on legacy code but was in contact with people developing brand new code using (supposedly) Agile and TDD. </p>\n\n<p>Now TDD is supposed to be Red - Green - Refactor: write failing tests, do the minimum to pass the test, then rework the code to make it more maintainable while making sure it still passes the test.</p>\n\n<p><em>But</em>… progress was measured by how quickly user stories got implemented, i.e. how quickly new functionality got added. The thing about refactoring is it doesn’t add any new functionality. Yes, it is very important but it doesn’t have the same immediate impact as showing the product owner the new functionality or even the lines of test code to go with it.</p>\n\n<p>As deadlines loomed closer, and overtime became standard, there was the incentive to skimp on the refactoring part. The more one does this, the more quickly one gets thru the user stories, which seemed to be what management cared about.</p>\n\n<p>Now, this <em>did</em> lead to technical debt because on a number of occasions to get the next user story done it turned out to be necessary to go back and refactor - really rewrite - code for the previous bunch of user stories. Management became irate at this because from their point of view the user story in question did not look to be all that different from the previous ones so why was the estimate for it 10 times longer?</p>\n\n<p>(There was an ugly game theory aspect to things as well. If you or your team <em>were</em> conscientious about refactoring that didn't prevent you from getting stuck cleaning up after another team that <em>wasn't</em>. Of course, that other team looked better because they got more user stories done in the same amount of time.)</p>\n\n<p>My point here is perhaps TDD does not lead to technical debt if done properly. But for it to be done properly there must be genuine buy in from higher up.</p>\n"}]
['https://Stackoverflow.com/questions/60888', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/5487/']