--- title: "XP is still widely unknown black magic" url: "https://osherove.com/blog/2003/9/17/xp-is-still-widely-unknown-black-magic.md" canonical: "https://osherove.com/blog/2003/9/17/xp-is-still-widely-unknown-black-magic.html" published: "2003-09-17T19:20:00" updated: "2003-09-17T19:20:00" tags: ["Off Topic"] author: "Roy Osherove" description: "XP always interested me. I always wanted to try out real-world live XP style development but never really got the chance. The problem is, at least in Israel, most people don't even know what this acronym means, let…" usage: "Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page)." license: "https://creativecommons.org/licenses/by/4.0/" --- # XP is still widely unknown black magic By Roy Osherove September 17, 2003 In [Off Topic](https://osherove.com/blog/category/off-topic) **Historical article** · Originally published September 17, 2003; technical details may be outdated. XP always interested me. I always wanted to try out real-world live XP style development but never really got the chance. The problem is, at least in Israel, most people don't even know what this acronym means, let alone would be willing to try out pair programming (which, if you think about it a minute, you do almost daily but in short bursts instead of most of the time). Although XP has lots of facets to it, the fascinating fact is that most developers I know don't even know how to do the most basic and fundamental thing when it comes to good coding practices: Test-Driven development and defensive programming. What do I mean? Ask the developer next to you “have you ever done Unit Testing?”  its very likely that you'll get  a positive answer to that question. But ask the following questions: 1. How have you done Unit Testing? 2. Have you used any of the Unit testing frameworks? 3. Did you write or plan the unit tests before or after you've written the code? 4. Can you repeat those tests automatically to make sure nothing is broken? 5. What's the first thing you usually write inside a method body? and so on. Here are some answers you might get(or you might answer them yourself): **How have you done Unit Testing?** - _“Well, I opened the GUI and played around with it for a while to make sure the calculation engine was correct“_ - _“I created a small program that uses my component to do some stuff and make sure it doesn't crash or anything“_ - _“I had our junior developer come and play around with the code/GUI/component“_ **Have you used any of the Unit testing frameworks?** - _“What testing frameworks?“_ - _“Oh, I've heard something about that. 'Unit' something wasn't it?“_ - _“I read some article about it“_ - _“I checked it out but didn't get enough time to play with it“_ - _“Nope“_ **Did you write or plan the unit tests before or after you've written the code?** - _“After“_ - _“Write a unit test? I do it all by hand“_ - _“Plan a unit test? you must be joking. The code changes every hour!“_ - _“I wanted to do it before but my dev lead said we don't have enough time for that“_ **Can you repeat those tests automatically to make sure nothing is broken?** - _“Probably. I remember most all of them“_ - _“Yeah right“_ - _“Not really, it was all manual“_ - _“We recorded some of them with \[Insert GUI test automation tool here\]“_ **What's the first thing you usually write inside a method body?** - _“Uh.. the method body?“_ - _“What do you mean?“_ - _“Try{“_ These answers ain't **bad**. They just indicate that there's enough lack of knowledge in the developer community about agile processes to make it scary. Once a developer does get to experience some of the agile processes (test-driven development for example) its very hard to go back to the old ways. It's infectious.  The problem is getting the developer to invest their time, or better yet, getting the **company** to invest its time in learning these new processes. Even though agile methodologies have been around for quite some time now, its still very hard for developers and business managers alike to adept to them and learn them. There's a kind of “_It looks pretty weird and silly. It's never gonna work_” attitude , especially about pair programming, that is really hard to break. It **has** to come down from management, because sometimes developers just won't do themselves and their companies that favor on their own. Another problem is that social behavior makes it hard to implement on your own. You certainly can get the feeling you're just being silly trying to get a developer to sit with you on a project when everyone else just sits there looking for the slightest hint of miscalculation or error to say “_I told you it was stupid!“_. Its never gonna work if you can't back it up with your dev buddies at the helm along with you. Funny enough, this whole post was supposed to be a couple of lines about an XP link I came across on the [XP mailing list](http://groups.yahoo.com/group/extremeprogramming/): the [XP quick reference](http://xp123.com/xplor/xp0202/xp-one-page.PDF) PDF file. Oh. and the first thing you usually write inside a method body? _Assert_s and parameter checking (if needed). ## More in Off Topic [All posts in Off Topic](https://osherove.com/blog/category/off-topic) - Sep 21, 2003 ### [Looking for a reporting solution for .Net](https://osherove.com/blog/2003/9/21/looking-for-a-reporting-solution-for-net.html) - Sep 20, 2003 ### [Making a decision in 4 seconds (or: How to know what you \*really\* want to do)](https://osherove.com/blog/2003/9/20/making-a-decision-in-4-seconds-or-how-to-know-what-you-reall.html) - Sep 14, 2003 ### [Interesting research](https://osherove.com/blog/2003/9/14/interesting-research.html) - Sep 11, 2003 ### [Happy Anniversary, honey. I love you.](https://osherove.com/blog/2003/9/11/happy-anniversary-honey-i-love-you.html) --- ## About the author **Roy Osherove**: Senior Solutions Architect at AWS working on AI for production and AI-driven development; author of The Art of Unit Testing and Elastic Leadership, with about 20 years of consulting and training on unit testing, TDD, team leadership and continuous delivery. ### Sites - [RobotPaper](https://robotpaper.ai/): This blog: AI patterns and anti-patterns, AI and coding agents, and engineering leadership. - [osherove.com](https://osherove.com): Roy's personal site. Author of The Art of Unit Testing and Elastic Leadership; consulting and training on unit testing, TDD, team leadership and continuous delivery, plus about 20 years of blog posts. - [The Art of Unit Testing](https://www.artofunittesting.com): The Art of Unit Testing, 3rd Edition (Manning): readable, maintainable, trustworthy unit tests, plus TDD workshops in C#, JavaScript, Java and Kotlin. - [5whys.com](https://www.5whys.com): Roy's writing on software team leadership: self-organizing teams, surviving chaos, learning mode and the Elastic Leadership model. - [Pipeline Driven](https://pipelinedriven.org): Continuous delivery and DevOps practices: build patterns, pipeline-friendly testing, DevOps metrics and enterprise DevOps. - [Elastic Leadership](https://www.elasticleadership.com): Elastic Leadership, Roy's framework for software team leaders (survival, learning and self-organizing modes). ### Social - X: https://x.com/royosherove - LinkedIn: https://www.linkedin.com/in/osherove/ ### Contact - Contact form: https://forms.gle/jQSx5KoXvrVA1JCK7 ### License Licensed under CC BY 4.0 — reuse, quote and adapt with attribution (Roy Osherove, link to the original page). License: https://creativecommons.org/licenses/by/4.0/