DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones AWS Cloud
by AWS Developer Relations
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Partner Zones
AWS Cloud
by AWS Developer Relations
The Latest "Software Integration: The Intersection of APIs, Microservices, and Cloud-Based Systems" Trend Report
Get the report
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. Overheard: Agile Truths

Overheard: Agile Truths

Trisha Gee user avatar by
Trisha Gee
·
May. 09, 12 · Interview
Like (0)
Save
Tweet
Share
2.76K Views

Join the DZone community and get the full member experience.

Join For Free
After attending a number of conferences and events, and performing numerous interviews, I'm starting to hear the same things again and again.  Since Dan North challenged all my assumptions at QCon, I'm reluctant to outright ridicule them, but I will put forward my personal opinion.

Note: these are things I have heard from multiple sources, so with any luck I am not breaking the sanctity of the confessional interview.

I've never pair programmed, but I've frequently worked with a partner on critical production problems
I find this fascinating.  If there's one thing that needs to be fixed as fast, as correctly, as efficiently as possible, it's a production issue.  And when there is one, "everyone" knows that two heads are better than one, even The Business.

If this is the case, why is it so hard to sell pair programming as the default state of affairs?

Is it because creating new features is seen as just typing, where the bottleneck is access to the physical keyboard?  Is it because fixing defects when the pressure isn't on is suddenly easier for one person on their own without help?

This state of affairs is interesting to me as it implies that when proverbial hits the fan, the instinctive thing to do is to work collaboratively.  Why don't we do it more often?

We use Test Driven Development to get coverage
Seems weird to me to write your tests first to get coverage.  If unit test coverage is your most important metric (and other people have covered why this might not be the case), I'm not sure why you would write your tests first.  Seems to me that you'd get better coverage writing the tests after the code.  That way you can be sure you've covered every eventuality.

To me, the statement implies two assumptions which I would challenge:
a) The primary value of writing your tests first is to meet your coverage requirements
b) Coverage is a meaningful metric

TDD/BDD has a number of benefits (...and now I'm reluctant to list them here in case people repeat them back to me in an interview).  Good coverage will probably be a side effect of being forced to write your tests first, but I'm not convinced that's the best thing that will come out of using TDD.

I only test first when I know what I want to code
I've overheard people saying that they test first when they know what the code is going to look like.  So you dive straight into the code when you don't know what you're doing???

Of course there is a place for this - spikes, prototyping, getting a feel for a new library, so on and so forth.  But I feel that for most code that you write in your day job, you probably have a business requirement and possibly (probably?) a less firm idea of how you're going to code it.  To me, this translates into writing the test first (which documents what you want to deliver, which you already know) and then getting that to pass (which is writing the code, which is the bit you might not know).

If you know exactly what the code is going to look like a) I would question that statement and b) what's the point of the test?


What are the real answers?
At QCon I saw on Twitter a number of complaints because the presentations there gave opinions, guidelines, and, worst of all, a lot of "it depends".  But people seemed to want The Answers.

In my opinion, what developers get paid for is working out the "it depends" parameters and selecting an approach, technical or process-wise, that works for their situation.

So although I have strong opinions on all the above subjects, and although LMAX has specific approaches to both pair programming and automated testing, sadly I'm not going to go into lots of details about those.

Mostly because I'm still interviewing candidates, and I don't want to give away the correct answers....
unit test agile

Published at DZone with permission of Trisha Gee, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • How to Submit a Post to DZone
  • HTTP vs Messaging for Microservices Communications
  • The 5 Books You Absolutely Must Read as an Engineering Manager
  • The Path From APIs to Containers

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: