tag:blogger.com,1999:blog-4013321723454530792024-03-13T09:17:05.278-07:00Faster Slower BetterDeveloping 'Better' software solutions is a journey. It requires dedication, creativity and talent.Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-401332172345453079.post-70093973853714915262009-10-15T20:21:00.000-07:002009-10-15T20:54:11.580-07:00Agile Tour 2009 Open Jam Part 2<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhj5EjG3K4fJkUZDaPeCQbkrxRzfFeC-1XMX7JIqfmO57xNatrlpW6ymqJVr1xJ6iIl9Sl7vShX7qFEE1tjMNUOKytBH0-fK8VHHjkefqT_tEYoHJFFueEi5iMFT76FY9Ac_Gt6qYUl5Mou/s1600-h/OpenJam.jpg"><img style="float:left; margin:0 10px 10px 0;cursor:pointer; cursor:hand;width: 150px; height: 200px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhj5EjG3K4fJkUZDaPeCQbkrxRzfFeC-1XMX7JIqfmO57xNatrlpW6ymqJVr1xJ6iIl9Sl7vShX7qFEE1tjMNUOKytBH0-fK8VHHjkefqT_tEYoHJFFueEi5iMFT76FY9Ac_Gt6qYUl5Mou/s200/OpenJam.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5393038991090513698" /></a><br />Once again Agile Tour was an exciting event in the Philadelphia area. There was lots of energy around as beginners and practitioners could find an avenue to increase their agile knowledge.<div><br /></div><div>The OpenJam gave people an opportunity to have open honest dialog around topics that they were passionate about. My blog first entry on the OpenJam covered the great topic of <a href="http://fasterslowerbetter.blogspot.com/2009/10/agile-tour-2009-open-jam-part-1.html">certifications</a>.</div><div><br /></div><div>This time I want to provide the session "Scum is Evil???" This was a great talk, where people could discuss the benefits of scrum over something like waterfall. It also got into issues where scrum just didn't go far enough.</div><div><br /></div><div>I'll start with the list of cards from Scrum is Good, it is a much shorter list.</div><div><br /></div><div>Scrum is Good:</div><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjRlcqMEp0djQ1dwg-9ziYbgtW1X0fcJew_FVvk8gwSInmgTq7wSdwtW8prw6JHIeNYRQn7mYWEhjYt28KbiQifl6qoyEiWC8Z5toOzuHlbejajUY-fn8ZMX1m8qrMOmBBDcGq5EQlqngUX/s200/ScrumIsGood.jpg" style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 150px; height: 200px;" border="0" alt="" id="BLOGGER_PHOTO_ID_5393034741708413170" /><div><span class="Apple-tab-span" style="white-space:pre"><span class="Apple-style-span" style="white-space: normal; "><span class="Apple-tab-span" style="white-space: pre; "> </span>Team Building</span></span></div><div><span class="Apple-tab-span" style="white-space:pre"><span class="Apple-style-span" style="white-space: normal; "></span> </span>Burn Down Chart</div><div><span class="Apple-style-span" style="white-space: pre;"><span class="Apple-style-span" style="white-space: normal; "><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Gave Agile Legs</div><div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Feedback Cycle</div><div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Regular Deliver of Software</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Make Crap Visible</div></div></div></span></span></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Failures have pushed evolution of Agile</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Fail Faster then Waterfall</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Customer Interaction</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Scrum failure is visibility to Failure</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Alternative to PMI<br /><span class="Apple-tab-span" style="white-space:pre"> </span>Works for Waterfall Executive Organizations</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Scrum Tackles People Problems</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Proven Process Documented</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Generates Excitement about Development</div><div><br /></div><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhtdI27AcTutOVYhJmrXA_GDb8-fBQYhuL3ZKr1xclw_VA0HYAj1gu_TV7_TX8sr6QPdQV-iW9UCVMiVAZO_z2rW6DQ3Z9536rEUvCc9iwbf9P4oZ9XDfGG-KUMzDigVhokyTY0g1XO5DjB/s200/ScrumIsEvil.jpg" style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 150px; height: 200px;" border="0" alt="" id="BLOGGER_PHOTO_ID_5393034670734171890" /><div>Scrum is Evil:</div><div><span class="Apple-tab-span" style="white-space:pre"><span class="Apple-tab-span" style="white-space:pre"> </span>Makes You Believe it Works</span></div><div><span class="Apple-tab-span" style="white-space:pre"><span class="Apple-tab-span" style="white-space:pre"> </span>Failure is Delayed</span></div><div><span class="Apple-tab-span" style="white-space:pre"><span class="Apple-tab-span" style="white-space:pre"> </span>Not Agile Revolution</span></div><div><span class="Apple-tab-span" style="white-space:pre"><span class="Apple-tab-span" style="white-space:pre"> </span>$$$ For Certification</span></div><div><span class="Apple-tab-span" style="white-space:pre"><span class="Apple-tab-span" style="white-space:pre"> </span>The Scrum Black Book </span><br /><span class="Apple-tab-span" style="white-space:pre"> </span>Outlived Initial Fame</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Easy to be Evil</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Scrum is the only Solution</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>TDD was not part until 2008</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Separate from AgileAliance</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>No Change New Word</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Product Manager on a Team</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>No Development Practices</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Title of Scrum Master</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Deceptive Marketing</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Control</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Burn Down Chart</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Intentions are Wrong</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Scrum Master is not a Coach</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>People play the wrong role</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Scrum Failure is not Agile Failure</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>People do not Venture out of Scrum</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Certification is Evil</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Feedback has no Solution</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Chicken Pig is divisive</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Micro Manage and Oppress People</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>No Tools for Solving Problems</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Leaves Staff Out</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Is a Buffet of Practices</div><div><br /></div><div><br /></div>Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.com1tag:blogger.com,1999:blog-401332172345453079.post-590536317560870522009-10-06T19:21:00.000-07:002009-10-06T20:35:46.279-07:00Agile Tour 2009 Open Jam Part 1<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuqFXxNtUm8g4PxYrj3Qh5sm7U0nvGAgSiJ-ILYkInmsOaI2YSqxa-XXvdf4gNfRhqwGwdA0ExhCMPweB3pifHvLrG0gfkYCMSO3g0sf-vX5YHR89G2dbEuxaPCCpL5mn_Jd4rRMn5enm2/s1600-h/OpenJam1.jpg"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 200px; height: 163px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjuqFXxNtUm8g4PxYrj3Qh5sm7U0nvGAgSiJ-ILYkInmsOaI2YSqxa-XXvdf4gNfRhqwGwdA0ExhCMPweB3pifHvLrG0gfkYCMSO3g0sf-vX5YHR89G2dbEuxaPCCpL5mn_Jd4rRMn5enm2/s200/OpenJam1.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5389696254955093794" /></a><br />Agile 2009 came to Philadelphia and had some great sessions. It provided information for people new to Agile as well as experienced.<div><br /></div><div>One of the three options available included an Open Jam. We had 3 topics that covered Certification, Scrum is Evil?, and Agile in a ERP. I want to thank all of the people who attended Open Jam. The discussion was great. For those who missed the sessions consider joining an open space discussion in the future.</div><div><br /></div><div>The notes I have are based on index cards that were captured as part of the discussion. This blog entry will only cover the Certification topic that took place during session one. Look for the next entries in the coming days.</div><div><br /></div><div>There were three main topics that came around our starting point of Scrum Certified Developers and scrum.org.</div><div><br /></div><div>Certification:</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Certified Developer</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Training $4,000</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Who can pay for training</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>3 day scrum training</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Can't teach in 40 hr course</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Language Specific certification is Bad</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>What skills should Agile developer have</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Agility assessment </div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>scrum.org scrum assessment online test<br /></div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Who's plan is best for training?</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Tom Mellor is the new Pres of Scrum Alliance</div><div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>World Scrum board</div><div><br /></div></div><div>Agile</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>What is Agile?</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Distributes agile</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Dev in one area, QA elsewhere</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Lean vs Scrum, XP is Dead?</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>XP, pairing, TDD</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Tracer bullet</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Product people/QA Agile training is challenge</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Team easy to work with</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>TDD is not QA</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Use Manifesto to help push Agile</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Buffet of practices</div><div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>New AgilePhilly site, no feedback</div></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>General feedback people do not give</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Start up XP/Scrum problem with no customer</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Customer quick iterations</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Feedback to create new stories</div><div><br /></div><div>Improvement</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Who tries to learn Agile</div><div></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Incremental learning</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Practices of an Agile Developer - Book</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Read books</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Participate in an Open Source project</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Warcraft Quests to level up in Agile</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Technology is always changing</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Everyone is a social Web expert</div><div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Acknowledge flaws and improve</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Blame/ownership CoCO</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Egoless developer</div><div><span class="Apple-tab-span" style="white-space: pre; "> </span>Awaken developers abound Ego hold back</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Discussion groups help learn</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Hire for behavior not knowledge</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Able to adapt to new environment</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Teach other to learn</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>Learn from others</div><div><br /></div></div>Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.com1tag:blogger.com,1999:blog-401332172345453079.post-86133084256538658452009-08-29T12:36:00.000-07:002009-08-29T13:34:41.172-07:00Faster the good way.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiReHdkN2IpDLR_76LeWyxP3Tjads90Z2Kjb0qGKU8RADcBtIyTPSC0t7irtzPlLfLUzPNnv-Avl8Mj3ETwyWu6iIdx0YaIydwbcmMkaJH7BAVPeByWAOdkNmns6c1GRNFl0V9st1tTmNYg/s1600-h/killmouse.jpg"></a>So going faster never turns out well, at least that has been my message. I have been wrong about that. Using tools that help you execute tasks quicker, is a great way to improve productivity. They will actually improve your quality, by making trivial tasks easier.<br /><br />Pretty much every developer who writes lots of JUnits learns the shortcut key to rerun a test. In my environment Eclipse it is Ctrl-F11. This simple savings of 2 or 3 seconds is important. It allows a pair to continue working without having to pause and search through a bunch of menu items.<br /><br />So how can you become faster without creating a mess? Try learning the tools you have available to you. Pretty much every good desktop application has menus with all sorts of shortcut keys. Learn them, people didn't add them because it seemed like a good idea. Simply put they allow the experienced user to perform their job quicker.<br /><br />Eclipse has a great plug in called mousefeed. Download it here: http://www.mousefeed.com/<div><br /></div><div><span class="Apple-style-span" style="color: rgb(0, 0, 238); -webkit-text-decorations-in-effect: underline; "><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiReHdkN2IpDLR_76LeWyxP3Tjads90Z2Kjb0qGKU8RADcBtIyTPSC0t7irtzPlLfLUzPNnv-Avl8Mj3ETwyWu6iIdx0YaIydwbcmMkaJH7BAVPeByWAOdkNmns6c1GRNFl0V9st1tTmNYg/s200/killmouse.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5375483845949891346" style="float: right; margin-top: 0px; margin-right: 0px; margin-bottom: 10px; margin-left: 10px; cursor: pointer; width: 200px; height: 81px; " /></span>This plugin will let you know when you select a menu item that has a menu shortcut. It gives a nice little tip that displays the shortcut keys you should have used. You can also change the tip to become a rule. So the next time you click the same menu item, you get the same popup with the action disabled. The only way to get the action to occur is to use the handy shortcut keys. This might slow you down for a short period, but the long term gain is well worth it.<br /><br />If I still used the menu bars to execute JUnits, I would have wasted hours of my day by now. If you ran 50 JUnits in an hour and the key stoke saved 2 seconds, you saved over a minute. That is real savings.<br /><br />There is another great tool for time savings called Infinitest, but I will get to that at another time. For now, you can focus on one easy task... Kill The Mouse!<br /><br /><div style="text-align: left;"><br /></div></div>Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.com0tag:blogger.com,1999:blog-401332172345453079.post-949690749771039162009-07-19T07:07:00.000-07:002009-07-20T13:25:54.322-07:00Pair it is the law!There are some obvious benefits to pairing: Shared knowledge, keeping on task, holding each other accountable, reduced bad design/code. It is all about quality. When we make a mistake we live with it forever.<br /><br />My wife works in heath care. She treats patients who have prostate cancer, with some sort of hugely expensive equipment that produces radiation. So when it comes time for a patient to receive treatment, how many people are involved in the treatment? Two, that is right two.<br /><br />I have been so busy thinking about how as software developers we are changing the way we do our work. I didn't even notice that my wife pairs every day of the week. In fact she has regulations against treating a patient by herself. The medical community doesn't want people to make mistakes.<br /><br />Why do we as programmers need to re-educate developers to not code alone? There are all sorts of regulations around treating patients with medical equipment. Shouldn't we consider our work just a critical? I say get that Bill to congress!Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.com3tag:blogger.com,1999:blog-401332172345453079.post-33077010133735137212009-04-29T16:11:00.000-07:002009-04-29T16:20:07.667-07:00Book Review: Test-Driven Development By ExampleTest Driven Development By Example is a Kent Beck book that introduces developers to the concept of driving feature development through the use of tests. This is not a new book on the subject, but it is the book that all developers should read. I have been developing using tests for quite some time, and I have used TDD techniques as part of my development methodology. Unfortunately it took me until recently to decide and read an actual book on the subject. <br /><br />Kent uses two different examples to show the steps that take place in a Test Driven solution. The first example is a Money application that uses Java for its solution. The second example is an exercise in building your own xUnit testing framework for Python. These examples show the cadence a developer uses to go from broken test to passing test. Rather then describing theory for how to write tests, Kent demonstrates. While showing the reader what steps are made and why decisions are made, he is actually building a case for specific patterns. The third section of the book looks at specific TDD patterns. <br /><br />This book does a wonderful job of demonstrating small focused tests. Create a test that fails, make it pass, refactor. Each chapter follows this pattern by focusing on a single task. Many of the chapters are less then five pages. They focus on a single test that needs to be implemented and the following implementation. This style may seem rather annoying at first, but definitely conveys the sense of being able to put down the book at any time. You can in turn pick up the book and quickly get right back into the exercises.<br /><br />This is a great book for both beginners and experienced TDD developers. Beginners will get a great first lesson on how to TDD and why it can be as successful as it is. Experts can get reinforcement on why decisions and behaviors are important.Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.com1tag:blogger.com,1999:blog-401332172345453079.post-5420957898158593162009-04-04T11:39:00.000-07:002009-04-04T12:28:49.403-07:00The SurplusI was watching the TV show "The Office" and there is an episode where there is a surplus and a decision needs to made how the extra money is spent. If they don't spend the money it goes away, and the next year they receive less money. <br /><br />Think of this, if you plan on running a 4 hour marathon. Suppose you are going to be done 30 minutes early. Would you run extra miles after the race so you can run for the full 4 hours? That would be silly. Then again would you slow down so that you hit the line an exactly 4 hours. This is the same surplus problem.<br /><br />Suppose a software team committed to delivering a project in 9 months and they finished what they agreed to in 8 months? Looks like there is a surplus. How should that time be spent? Should the team get assigned a new project? Should the team be allowed to determine what they need to do over that 1 month period?<br /><br />I see a very similar relationships between the three scenarios. Management funds projects and pays for it through money and resources. If the project cost the price or less, management gets what they asked for. If there is extra money or resources who gets to spend it. <br /><br />I would think the team gets to spend the money or time. Lets face it as teams we rarely have extra cash or time. We also are more then welcome to accept more work. I think it is time to reward teams for being good at what they do. Let them decide how to spend the extra money. Lets face it we will probably prototype out something with a long term goal in mind.Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.com0tag:blogger.com,1999:blog-401332172345453079.post-35929772889526892942009-03-23T19:03:00.000-07:002009-03-28T07:29:44.896-07:00Passion, Drive and Trust<div>I have been working on a team for nearly a year, and this is an account of the last couple of weeks. Essentially we ended up behind plan, I guess that is a whole different story to tell. With some drive and passion for success we were able to accomplish some pretty good stuff.</div><div><br /></div><div>Early on the team was able to build some core values before we were up against a deadline. Code reviews were mandatory for everything. <span class="blsp-spelling-error" id="SPELLING_ERROR_0">JUnit</span> tests were required for all work we did. <span class="blsp-spelling-error" id="SPELLING_ERROR_1">Fitnesse</span> tests were also developed in appropriate areas. I knew we had a good culture when I wasn't the only one who asked about scheduling a review or where the tests were.</div><div><br /></div><div>So we finally realized we were kind of behind with 3 sprints left. So I challenged the team to rev up up our output. It was a straight forward challenge deliver 50% more points each sprint and we would do a happy hour every two weeks. I would kick in $50 and I challenged the product owner and manager to each match the $50. </div><div><br /></div><div>There are a lot of reasons that these gimmicks don't work. There are also a bunch why they can work. First it gave the team a challenge to do the impossible. Lets face it as IT professionals we like to do the impossible. It also gave us an opportunity to socialize as a team outside of the team room.</div><div><br /></div><div>So what went right? We were able to have our first two happy hours. We are sure we are going to hit our last goal, because we ended up ahead of plan. Our management team is happy and the team feels great about what it has been able to accomplish. You would expect corners were cut to get the extra output, but because we had already changed the culture, the core values stayed strong. So rather than cut corners there is only one way to get extra output. Yes, lot of extra effort.</div><div><br /></div><div>What stuff didn't work? First I ended up sick. I guess going on 4-6 hours sleep for 2 or 3 weeks really isn't great for the body. We ramped up our development, but non-developer testing has been more difficult to to match the increase. So we have a bunch of stories waiting for acceptance from our <span class="blsp-spelling-error" id="SPELLING_ERROR_2">QA</span> team. Can we deliver the work without testing, no. We still need to fix this. I didn't say we were perfect yet. Lastly I hope my boss doesn't expect the impossible on a monthly basis.</div><div><br /></div><div>I still like the fact we are going to hit our deadline with quality. I would rather be drinking beer and making better friends along the way. I guess we would have been better off bonding as a team earlier in the release. Then again we needed to trust each other to accomplish our lofty goals.</div>Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.com2tag:blogger.com,1999:blog-401332172345453079.post-71527789676719529282009-02-16T17:59:00.000-08:002009-02-19T20:20:45.336-08:00Developing With Smaller Steps<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgf35_xh3xj9csqvQgO78uChG-5dLirdWKDSj4-v4H4fNuvqa68Wus1SzOW87C1vqLLz9-j3y_AuLKft-03vtcgCaguOelElnJH4oSAJAYI9-krvoj6PxDQZ1BdUGtSbpMZufqW42wHScVz/s1600-h/Ice-Skating-Beginner.jpg"><img style="float:right; margin:0 0 10px 10px;cursor:pointer; cursor:hand;width: 191px; height: 200px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgf35_xh3xj9csqvQgO78uChG-5dLirdWKDSj4-v4H4fNuvqa68Wus1SzOW87C1vqLLz9-j3y_AuLKft-03vtcgCaguOelElnJH4oSAJAYI9-krvoj6PxDQZ1BdUGtSbpMZufqW42wHScVz/s200/Ice-Skating-Beginner.jpg" border="0" alt="" id="BLOGGER_PHOTO_ID_5304729677519083394" /></a><br />My son has been learning to ice skate over the past months. I was lucky enough to use some of my software development skills, to help him become more successful. Here is the story of how my four year old learned how to skate and how you can build better software.<br /><br />After getting my son all suited up and ready for the ice, he had his first lesson standing by himself. His second lesson started almost immediately: getting back on his feet after falling. His third lesson was how to move his feet. This was where it got more challenging: as soon as one foot moved, he needed to try and regain his balance. He would then move the next foot as quickly as possible to “fix” things; unfortunately, this caused him to fall faster.<br /><br />He was persistent and kept trying as hard as he could. Eventually, I convinced him to take smaller steps; this allowed him to keep his balance throughout the movement and never need to react to any major changes. He moved slower like this, but he spent a lot less time getting up off the ice.<br /><br />Somewhere there must be a lesson in developing software solutions:<br /><ul><li>Small steps allow you to be in control. </li><li>Large steps expose many possibilities for failure.<br /></li></ul>So when I started coding my most recent project I started thinking about taking smaller steps. Instead of doing two or three things in my code or test, I just focused on doing one thing. I make a change and immediatly validate the outcome. If it didn't work I need to rework that modification. Once I am satified I have met my expectations, I move on to the next task.<br /><br />Small steps allow you to get from project start to the other end of the ice without falling. Don't be tempted to code in “big steps” just because you are on a creative roll. Instead, try writing down some “small steps” on index cards; if these steps are written as tests, you will have the start of a TDD solution.<br /><br />Take those index cards and start coding the solution to the first test. When you can prove that the first tests passes, you can then move onto the next test with confidence. If you suddenly realize you need a new test while coding a small step, write it down on a card. Don't stop working on that small step until it is complete.<br /><br />If I coded a solution for eight hours without any validation, I can assure you the solution would have bugs. Trying to validate those changes, certainly would take longer then the original solution. Obviously, coding for one hour (a smaller step) followed by some testing would be a better, more efficient practice. Shorten that time to less then five minutes and you will be on your way to success.<br /><br />How big are your steps? Can you make them even smaller?Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.com2tag:blogger.com,1999:blog-401332172345453079.post-70283196723258546742009-02-06T05:18:00.000-08:002009-02-13T14:41:59.570-08:00What my Xbox taught me about agileI have spent a large portion of my career trying to develop new code faster than before. This sounded like a really easy goal to accomplish. I guess my original plan was always flawed. The more I tried to develop fast, the more I needed to fix bugs. When something from 6 months past becomes a problem, things would come to a really frustrating halt.<br /><br />The first time I played Forza Motorsport 2 on my Xbox 360, I drove as fast as I could crashing into every wall. This caused my car to get turned around backwards and start driving in the wrong direction. The game seemed impossible. Then I tried something crazy. I slowed down!!! What slow down in a video game. I did and do you know what happened? My time was significantly better. Eventually I was able get better control of the car at higher speeds. Still I needed to control how fast I drove, you can't go through a hair pin turn at full speed.<br /><br />Why am I talking about video games?? Well we can learn a lot about software development from this same problem. If you are constantly pushing out as much code regardless of the quality, you will hit walls. You will need to stop what you are doing and rework code. The addition of new features will take longer because things are not stable or testable. Fixing defects requires hours of debugging sessions. <br /><br />I realize no one wants to create a mess, it just happens. The faster you go the more technical debt you build up. Does your manager have sleepless nights about the debt you are building? I doubt it, this debt is usually very hidden. It only resurfaces in defects or the inability to make changes to existing code. I can assure you that you will spend more time fixing the mess then it took to create it.<br /><br />One of my favorite techniques for delivering quality code is automated tests. Unit testing are the safety net that we need to prove what we are doing. If you are practicing TDD you are proving that your intentions are realized in code properly. Think back to before you had these tools. Has anyone wasted a day looking for a solution to a boolean expression of (variable = false). Yes it is an assignment not a boolean expression and it will always come back true. Unit testing is important.<br /><br />So why FasterSlowerBetter? I think it says a lot about how I want to develop software. I want to be faster, but experience has taught me how to get my goal accomplished. Going slower and having better deliverables sets you up for a more <span style="font-weight:bold;">productive</span> future.Doug Baileyhttp://www.blogger.com/profile/13403985765642706848noreply@blogger.com1