side-effects • You can see WHAT the change was in SCM • You need to know WHY the change was made hence the Bug # (and SCM-/Tracking integration) • Only then you can reliably fix the side-effect without breaking • previous bug fixes • other features November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
is still in the topic • She‘s able to directly fix the issues without having to re-think the situation when a bug report comes in a few days (or weeks) later • Other devs know of the problem and don‘t check out broken versions that causes them problems • Enables automated testing November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
in trunk/master • Features • Bug fixes • Reintegrate into release-branch only if 100% sure • that it‘s tested • you‘re confident in stability November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
are distracting • WTF WTF WTF • „Look at that! Can you tell me what he meant by this?“ • Reviewer needs too much time to get in the code • Unproductive and time consuming • Reviewer could mob developer • „You‘re not working with our guidelines“ • „But *Everyone* knows that {very special way of doing things here}“ November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
shoulder“ reviews • Developer seeks reviewer in person • Developer explains to reviewer • Reviewer asks questions and points to possible problems • Developer takes notes • Developer fixes • Developer checks in November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
Usual guess? • x2, or 100% • 50 % initial overhead while the pair syncs up • About 15 % overhead on the long run November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
9.2h / 2 à 4.6 h • Half a day + half an hour • Task: 8h • Alone: x1 à 8h • Alone: 8h / 1 à 8h • One full day Let‘s do the math Single Developer Pair November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
% less defects • Since costs to fix a defect later is higher than instant fixing that alone saves more than pair programming costs • About 20 % less lines of code • Better architecture • Distributed knowledge • Higher motivation • Less distraction November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
But it works http://blog.jphpsf.com/2012/09/30/OMG-test-driven-development-actually-works http://www.typemock.com/blog/2009/03/05/the-cost-of-test-driven-development
„Our experiences and distilled lessons learned, all point to the fact that TDD seems to be applicable in various domains and can significantly reduce the defect density of developed software without significant productivity reduction of the development team.“ Source: http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf
Full TDD (test first) for everything • 50% less defects - after 2 years • No mention on costs, though • Second link (study from IBM & MS) • Costs: Time only. 15% to 35% more • Gains: Bug ratio went down to 61% (and one product down to 9%!) November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
• Code is only written testable if tests are there upfront • New features within existing code are hard to cover with TDD • Writing tests is not easy and fast to learn • especially when there‘s no TDD culture and mentors around November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
TDD • Start with simple features to get used to it • If you access not-tested infrastructure, wrap it with something mockable that just passes through in production • Write tests for existing code only • when you need to do major refactorings • when you fix a bug and that code is already testable • or almost, with little work November 2012 - EKON 16 Sebastian P.R. Gingter - @PhoenixHawk
phoenixhawk
miu_crescent
lycorptech_jp
segavvy
ysakotch
oracle4engineer
marchin1989
mitchan
maruto
orimanabu
rayuron
os1ma
chanyou0311
chriscoyier
sachag
colly
bluesmoon
holman
tammyeverts
jacobian
andyhume
bryan
aleyda
carmenintech
lara
