Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've realised that my greatest weakness as a programming student is my poor ability to comprehend other people's code.
I have no trouble whatsoever with 'textbook' code, or clearly-commented code, but when given a program of a few hundred lines, containing a dozen or so different functions and no comments, I find it very difficult to even begin.
I know this type of code is what I'm probably more likely to encounter in my career, and I think that having poor code comprehension skills is going to be a great hindrance to me, so I'd like to focus on improving my skills in this area.
What tools/techniques have helped improve code comprehension in your experience?
How do you tend to tackle unfamiliar, uncommented code? Why? What about your technique do you find helpful?
Thanks
Familiarizing yourself with foreign code
If the codebase is small enough, you can start reading it straight away. At some point the pieces will start falling together.
In this scenario, "small enough" varies, it will get larger as your experience increases. You will also start benefiting from "cheating" here: you can skip over pieces of code that you recognize from experience as "implementing pattern X".
You may find it helpful to make small detours while reading the code, e.g. by looking up a function as you see it being called, then spend a little time glancing over it. Do not stay on these detours until you understand what the called function does; this is not the point, and it will make you feel like you are jumping around and making no progress. The goal when detouring is to understand what the new function does in less than half a minute. If you cannot, it means that the function is too complicated. Abort the detour and accept the fact that you will have to understand your "current" function without this extra help.
If the codebase is too large, you can't just start reading it. In this case, you can start by identifying the logical components of the program at a high level of abstraction. Your goal is to associate types (classes) in the source code with these components, and then identify the role each class plays in its component. There will be classes used internally in a component and classes used to communicate with other components or frameworks. Divide and conquer here: first split the classes into related groups, then focus on a group and understand how its pieces fit together.
To help you in this task, you can use the source code's structure as a guide (not as the ultimate law; it can be misleading at times due to human error). You can also use tools such as "find usages" of a function or type to see where each one is referenced. Again, do not try to fully digest what the IDE tells you if you can't do it reasonably quickly. When this happens, it means you picked a complicated piece of metal out of a machine you don't quite understand. Put it back and try something else until you find something that you can understand.
Debugging foreign code
This is another matter entirely. I will cheat a little by saying that, until you amass tons of experience, there is no way you will be debugging code successfully as long as it is foreign to you.
I find that drawing the call-graph and inheritance trees out often works for me. You can use any tool you have handy; I usually just use a whiteboard.
Usually, the code units/functions are easy enough to understand on their own, and I can see plainly how each unit operates, but I often times have trouble seeing the bigger picture, and that's where the breakdown happens and I get this "I'm lost" feeling.
Start small. Say to yourself: "I want to accomplish x, so how is it done in the code?" where x is some small operation that you can trace. Then, just trace the code, making something visual that you can look back on after the trace.
Then, pick another x and repeat the process. You should get a better feel for the code every time you do this.
When it comes time to implement something, choose something that is similar (but not almost identical) to one of the things you traced. By doing this, you go from a trace-level understanding to an implementation-level understanding.
It also helps to talk to the person who wrote the code the first time.
The first thing I try and do is figure out what the purpose of the code is at a high-level -- the detail's kind of irrelevant until you understand a bit about the problem domain. Good ways to figure that out include looking at the names of the identifiers, but it's usually even more helpful to consider the context -- where did you get this code? Who wrote it? Was it part of some application with a known purpose? Once you've figured out what the code's supposed to do, you can make a copy and start reformatting it to make it easier for you personally to understand. That can include changing the names of identifiers where necessary, sorting out any weird indentation, adding whitespace to break things up, commenting bits once you've figured out what they do, etc. That's a start, at any rate... :)
Also -- once you've figured out the purpose of the code, stepping it through a debugger on some simple examples can also sometimes give you a clearer idea of what's going on FWIW...
I understand your frustration, but keep in mind that there is a lot of bad code out there, so keep your chin-up. not all code is bad :)
this is the process that I tend to follow:
look for any unit tests as they should document what the code is supposed to do...
navigate through the code using code rush / resharper / visual studio shortcuts - this should give you some ideas about the logical and physical tiers involved...
scan the code first, looking for common patterns, naming conventions, and code styles - this should give you insight into the teams standards and maybe the original coders mind set...
as I navigate through the code heirarchy I make a note of the the objects being used... typically with pen & paper drawing a simple activity diagram :
I tend to start from a common entry point, so if it is a UI, start from the view and work your way through to the data access code, if its a service start from the service boundary and work your way through to the data access code...
look for code that could be refactored - if you can see code that can be refactored, you have learned how to simplify it without changing its behavior...
practice building the same thing that you are reviewing, but in a different way...
as you read through untested code, think of ways to make it testable...
use code rush diagnostics tools to find methods that are of high maintenance complexity or cyclomatic complexity and pay special attention to these areas because chances are, this is where the most bugs are...
Good luck
Understand is a terrific code analysis tool. It was in wide use at my previous employer (L-3) so I purchased it where I currently work.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I have graduated from my university almost a year ago. Since then I have worked with many different technologies, such as PHP, JQuery, ASP.NET, C# etc. Recently I have switched to a company where powerbuilder is being used for development.
The problem is that I haven't mastered any of the above languages. I can do stuff with those but when it comes to the complex tasks I often struggle with it because I don't have enough deep knowledge about it. After looking at powerbuilder for a few days I sense that this is going to happen again because most of the application code have been done using some sort of library which requires some advanced level of skill on powerbuilder.
My question is, is it OK for me to work on different technologies without mastering a single one of them?
If you choose to specialise the you are taking an opportunity cost by making yourself unavailable for other types of work. This is good if you can be confident that your chosen specialisation will last for a reasonable length of time. However, you can guarantee (along with death and taxes) that software will change. You will always be required to learn some new framework or approach in order to remain current.
So to avoid finding yourself at an intellectual dead end (are transputers still in use anywhere?) you should adopt a doctrine of constant learning. Learning is usually fun and almost always leads to a joy of discovery of some new tool or design. And never keep this knowledge to yourself (it only has a half-life of 18 months anyway). Share what you have learned with others.
So to answer your question: don't specialise.
According to the Pragmatic Programmer book, one of the tips for a good programmer is:
Invest Regularly in Your Knowledge Portfolio
Make learning a habit.
This means that you constantly have to use, or learn about, new technologies. While becoming a master in one particular technology may be rewarding, technologies come and go, today more quickly than ever. A mastery in one particular programming language, tool or API may make you a guru today, but may mean nothing tomorrow.
IIRC they also recommended developers to master several technologies, but remain versed in many - at least in the sense of having heard about them, played around with them, being able to engage in a conversation about them.
So, I would say yes - specialization is necessary, but this doesn't mean one should ignore domains outside his own.
There is no 'right answer' to this question other than maybe, 'it depends'.
You will find it easier to find better jobs if you specialise, as you call it. I would think of it more as working with a specific language/framework. Further, it is important to solve difficult problems and gain experience, irrespective of the language chosen.
Once you've accepted the above as a truism and specialised, then I would suggest that you branch out and learn new languages. Fortunately, languages become easier to learn when you have more experience.
However, more than anything, you have to look at keeping yourself interested over a long period of time. That is the real key. If you have interest, you will continue learn and gain experience. Maybe that will mean you do something that is not particularly relevant to most jobs, such as writing a language compiler. Or maybe you will find that the rush of working for big clients on big projects is more important than a specific language/framework.
So that's it - just keep interested, and keep learning. And, where possible, build focus in the thing that interests you, as that will make it easier for you to find employment going forward.
It is important to be specialized in at least one programming language/platform, especially early on in your career. By specialized i mean reading a book about it, cover to cover, and having extensive hands on experience developing for it, at work or participating in an open source project.
The idea behind this is that when you specialize in a language, you will learn many concepts that you can carry over to different languages/platforms. e.g: The master of a language can master another with relative ease.
Further on in you career being exposed to many platforms is a good thing, as you start to shift from begin a developer to a developer/architect, and you need to make decisions about which platform to use, the pros and cons of each platform and so no.
So my advice is try to master at least one language, along with its tools and frameworks. After that you can move on to different platforms. It is important to use the right platform for the current project, you will need to determine that case by case, with the assistance of a senior developer.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 7 years ago.
Improve this question
The amount of available programming languages is both a bless and a curse, I think.
I know a lot of programming languages already, some at syntax-level only and some good enough to do actual coding (Python, C, C++, Haskell, Perl, BASH, PHP, and lots of others). I have been programming for almost as long as I've been intensivly using computers (6 years), in almost every paradigm (functional, imperative, object oriented), but I don't feel prepared for the software industry.
I've been writing a lot of bigger programs in a lot of different languages, mostly network based, including large multithreaded server/clients, and I still don't feel prepared!
Currently I'm obsessed with my "3-tier" plan, which includes a high level language like Haskell, an interpreted language like Python and a low level language like C, yet I don't feel good enough!
I know how to work in teams, and how to work along given guidelines, but I'm unsure.
Am I prepared?
Please, kind people of stackoverflow, help me out of this mess! :(
Thanks for all the answers, I wish I could chose more answers as THE answer :)
Sounds like you know an awful lot about programming, but you don't mention anything else. Being a software developer requires more than just programming as a technical skill. Brush up on topics such as source code control, unit testing/test-driven development, continuous integration, etc. Hopefully you'll land in a job where at least one of those is in use. Try and learn as many useful time-savers as you can with your tools; try to become as flexible and efficient with your IDE as possible.
Elsewhere, don't forget to develop the more personal skills; attitude and work ethic, and more related to your field, issues such as eliciting requirements, documenting issues and describing problems and solutions. Don't worry too much about these if you're going in afresh, because you're not expected to have a huge knowledge of them, but if you're at least aware of them and trying to improve, then you have a greater chance of doing so.
Try to appraise yourself of general software development issues that aren't directly coding, if you haven't already - general attitudes to security-oriented development (and testing), good design and similar best practices.
Don't sweat too much about being perfect right off the bat. If you've got no room for improvement, you aren't going to enjoy your career very long, and burning out as a programmer ain't much fun.
You know enough - there is a minimum threshold of knowledge required in the industry (which is above what some developers have), but it sounds like you are already there.
For anyone with the aptitude, new programming languages, techniques, etc, are easy to learn. A good company to work for will hire you based on your abilities, not knowledge (which can go stale very quickly).
If you want to stand out as a software developer, ensure you have rock solid communication skills for reports, e-mail, telephone, meetings, etc. That is a rarer gift in the software field, and although it is not necessary more valuable at the junior levels, it pays off in the long run.
The single most important thing I can think of to be successful in the industry is to be able to respond quickly and efficiently to change.
I recently took a programming test which I thought was a good and fair test. I passed it without a great deal of effort. I was told that 50% of the people (these are all people with programmer on the resume) don't even know where to start. Your earnestness and desire will most likely put you in the top third of most places to start with.
Knowning languages is not all you can do.
If you can, a placement/internship will do wonders. Anyone can program. Real world experience will teach you more than any tutorials, self learning or schooling will.
Naturally, gaining an internship requires some experience, so it's very much catch twenty two.
If going for an internship is not possible, get involved with an open source project. You'll find you'll learn loads by working with people smarter than you.
True knowledge exists in knowing that you know nothing.
Socrates some smart dude
I think this is pretty common among developers. Imo it´s a way better sign then if you would come to the conclusion that you were fully trained.
The only way to know for sure if you're prepared is to try. Sometimes being thrown in the deep end actually helps and you'll find you learn more in that first real world job than you did in all the books/etc that you read in the years before. Also, knowing multiple languages helps you understand underlying semantics of programming in general, but in a real job you'll likely be sticking to one or two languages day to day, so don't get hung up on knowing every language out there.
It's better to try & fail than to spend your life wondering if you're ready.
Go to dice or monster or whatever your favorite job site is and see what people are looking for. It's not Haskell, it's C++. Learn that well and you're ready to go. Once you're out in the real world, you'll learn quickly enough the things that are important. These are mostly the soft skills that school doesn't teach you. Things like how to get along with the clueless, how to present your ideas so they'll actually be considered, and how to see the forest even though you're stuck under a rock.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Its always said that more you program, the better you become. Sounds good and true.
But I was wondering if there is a proven route to becoming a better programmer.
Something like:
Learn a
Learn b
Learn c > 'Now you are good to burn the engines'
Try stuff around based on your learning.
The answer might be similar to a CS course roadmap, but I want to hear from successful programmers who might want to pitch in with something notable.
Thanks
It's not true that practice makes perfect.
It's perfect practice that makes perfect.
If all you do is keep repeating the same bad practices again and again, you'll only make it possible to create bad code faster.
By all means keep coding. But at the same time be critical of everything you do. Always have a jaundiced eye that looks for ways to do things better. Read widely to get new ideas. Talk to others about how they do things. Look at other people's code, good and bad.
There's no "sure" way to learn anything that I know of. If there was, anyone could master this.
All questions are rhetorical and meant to stimulate thought.
Technical parts:
Design Patterns - There are probably some specific to a domain but generally these are useful ways of starting parts of an application. Do you know MVC or MVP?
Basic algorithm starting points - Divide and conquer, dynamic programming, recursion, creating special data types like a heap, being greedy, etc.
Problem solving skills - How easily can you jump in and find where a bug is? Can you think of multiple solutions to the problem?
Abstract modelling - How well can you picture things in your head in terms of code or classes when someone is describing a problem?
High level versus low level - How well do you understand when one wants something high or low? This is just something I'd toss out there as these terms get through around a lot, like a high level view of something or a low level language.
Process parts:
Agile - Do you know Scrum, XP, and other new approaches to managing software projects? How about principles like YAGNI, DRY and KISS? Or principles like SOLID? Ideas like Broken Windows?
Developer Environment - How well do you know the IDE you use? Source Control? Continuous Integration? Do you know the bottle necks on your machine in terms of being productive?
xDD - Do you know of TDD, BDD, and other developments driven from a paradigm?
Refactoring - Do you go back over your old code and make it better or do you tend to write once and then abandon your code?
Soft skills:
Emotional Intelligence - Can be useful for presentations and working with others mostly.
Passions/Motivation - Do you know what gets your juices flowing and just kick butt in terms of being productive? Do you know what you would like to do for many many years?
My main piece of advice would be: don't be afraid to rewrite your own code. Look at stuff you wrote even a month ago and you will see flaws and want to rewrite stuff.
Make sure that you understand some fundamentals: collections, equality, hashcodes etc. These are useful across pretty much all modern languages.
Depending on the language you use - use lint and metric tools and run them over your code. Not all their suggestions will be applicable but learning which are important and which are not is important. E.g FindBugs, PMD etc for Java.
Above all refine and keep refining your work. Don't treat your work as abandonware!
Learn your 1st programming language a new programming paradigm or a
find a mentor you can learn from
Apply what you've learnt in a real world project
Learn from your mistakes and successes and goto step one
The trick is knowing what to learn first:
Programming languages - this is the place to start bcause you cannot write software without knowing at least one of these. After you've mastered one language try learning another.
Programming paradigm - i.e. object oriented, dynamic/functional programming etc. Try to learn a new one with each new language.
Design concepts - S.O.L.I.D, design patterns as well as architectural concepts.
People skills - learn to communicate your ideas.
Team leadership - learn how to sweep others and how to become a team or technological lead.
After that the sky is the limit.
I would look at improving roughly in this order, in iterations with each building on the previous one:
Programming concepts. Understand things like memory management, pointers, stacks, variable scope, etc.
Languages. Work on mastering several modern languages.
Design concepts. Learn about design patterns. Practice using them.
Communication. Often-overlooked. You can only become a highly valued Software Engineer if you can communicate effectively with non-tech people. Learn to listen and understand the needs that people are expressing, translate that into a set of requirements and a technical design, but then explain what you understood (and designed) back to them, in terms they can understand, for validation before you code. This is not an easy one to master, but it is essential.
Architectural concepts. Learn to understand the big picture of large, complex systems.
Learning a programming language is in many ways similar to learning a spoken language. The only way to get good at it is to do it as often as possible. In other works
Practice, practice, read and then practice more
Take time to learn about all sorts of coding techniques, tools and programming wisdom. This I have found to be crucial to my development. It's to easy to just code away and feel productive. What about what could be if you just had some more knowledge / weaponry under your belt to bang out that next widget.
Knowledge/know how is our real currency. The more we know the more we can make a better decision about how something should be done and do it faster.
For example, learn about:
•Development Practices, Software Design, Estimation, Methodologies Business Analysis Database Design (there are a lot of great books out there and online resources)
•Read Code - Open Source Projects are a good place for this. Read
Programming blogs
•Try to participate on Open Source
Projects.
•Look for programming user groups in
your town and/or someone who can mentor you.
And yes, as mentioned practice. Don't just read, do and watch how you will improve. :)
Practice, practice, practice.
Once you're over the basic hump of being able to program, you can also read useful books (i.e. Code Complete, Effective Java or equivalents, etc.) for ideas on how to improve your code.
First and foremost write code. Write as much as you can. Tackle hard problems. If you want to be a really good programmer you need to get into the guts of what you are doing. Spend a lot of time in debuggers looking at how things work. If you want to be a good programmer who really understands what is going on you need to get down to the metal and write highly async code, learn about how processors work and why SSE is so awesome. Understand threading primitives and be able to write them as well as describe what is actually happening in the processor. I could keep going here but you get the idea.
Second find someone who knows a lot more than you and learn. This relationship will work better if you are already deeply immersed in writing lots of code.
Third, spend some time in a large high quality open source code base. I learned a ton from the Quake I and Quake II code. Helped me be a better programmer.
Fourth take on hard problems. Push your limits. Build things that you thought were impossible. Right now I am writing a specialized compiler. I have learned so much just working on this for the last couple of months.
Sure, strictly speaking, the more you practice programming, the better you become at solving those sorts of problems. But is that what you really want?
Programming is a human activity more than a technological one, at its heart. It's easy to improve your computer skills, not so hard to improve your interpersonal skills.
Read "Journey of the Software Professional" by Hohmann. One of the concepts the concepts Hohmann describes is the "cognitive library," which includes both programming skills and non-programming skills. Expand your cognitive library, and your programming skill will improve too.
Read a lot of non-programming books too, and observe the world around you. Creating useful metaphors is an essential skill for the successful programmer. Why do restaurants do things how they do? What trade-offs is the garbage department making when they pick up the garbage every few days instead of every day? How does scaling affect how a grocery store does business? Be an inquisitive human to be a better programmer.
For me, there has to be a reason to learn something new... that is, unless I have a project in mind or some problem I need to solve, there's no hope. If that prerequisite is met, then I usually try to get "Hello, world" working, and after that the sky's the limit. So much of development these days is just learning new APIs. Occasionally there's some kind of paradigm shift that blows your mind, but that's not as common as people like to think, IMHO.
Find a program that intrigues you, one that solves a problem, or one that would simplify many of your tasks. Try to write something similar. You'll get up to speed very quickly and have fun doing it at the same time.
You can try learning one thing really well and then expanding out to programming areas that are associated with the things that you have learnt, so that you can offer complete solutions to customers.
At the same time, devote part of your time to explore things outside your comfort zone.
One you have learned something, try to learn something a little harder. Read and practice a lot about things that seem confusing at first time (lambda functins, threading, array manipulation, etc). It will take its time, but once you have practiced enough, what seemed confusing at first, will be familiar and easy.
In addition to the rest of the great advice already given here, don't be afraid to read about coding and good practice, but also take everything with a grain of salt and see what works best for you. A lot of advice is opinion.
Good sites to read:
-thedailywtf.com
-joelonsoftware.com
-codinghorror.com
-blogs.msdn.com/oldnewthing
A great place to get practice is programming competition websites. Those will help you learn how to write good algorithms, not necessarily maintainable code, but they're still a good place to start for learning.
The one I used to use (back when I had time) was:
http://uva.onlinejudge.org/
Learn more than one language. One at a time, definitely, but ultimately you should be fluent in a couple. This will give you a better perspective I think, and help you to become an expert at programming, rather than being an expert at a certain language.
Learn the ins and outs of computers at all levels, hardware, os, etc. Ideally you should be able to build your own system, install multiple operating systems on it, and diagnose just about every problem that can arise. I know many programmers who are not "computer tech people" and their failure to understand what is happening at every level becomes a major hindrance in diagnosing and fixing unusual bugs or performance issues.
As well as looking at 'last weeks code', talk to users of your work after delivery - be one yourself if possible.
Its not my bag, but some of the best coders I know have spent time supporting applications. The experience improved their product I'm sure.
eat breath dream the programming language your using (no seriously, it helps)
There are two kinds of learning -
1. Informal (like how you learned how to function in society- through interaction with peers and family)
2. Formal (like your high school training- through planned instruction)
If you want an entry-level programming job, formal training via an undergrad Computer Science/Engineering degree is the way to go. However, if you want to become a rock-star developer, it is best done by informal training- make unintentional mistakes and have senior developers curse at you, learn a design pattern because an app you are updating uses it, almost cry because a bad developer wrote a huge messy program lacking documentation and best practices and now you have to do several updates to it ASAP; thing of these nature.
It is hard for anyone to give you a list of all you need to know. It varies per area (e.g. a web developer vs. to a desktop developer) and it varies per company (e.g. Microsoft that sells software vs. General Motors that mainly just use it in their cars.) Informal traiing and being engaged in trying to learn to do your job better and get promoted is your best bet in my opinion.
To prove my point, everyone here has great answers but they all differ. Ask a rock-star developer how he learned something or when, why; they may not know- things just happen.
Practice, individually and collectively
Keep an open mind, always learn new things, don't limit yourself to what's familiar. Not solely from a tech perspective, ui design, people skills, ... Don't be afraid of what's new
Peer review, talk to people about your code, let people talk to you about their code, everyone has a unique way of looking at a problem and you will learn a great deal from peers
Love coding. If you love what you're doing, putting in alot of time seems effortless. Every coder needs the drive!
One small addition to these good answers. When I work on someone else's code, usually I pick up something new. If you have the opportunity to work with someone else that is of equal or greater skill, noticing their programming style can teach you tons.
For example, in C++ & Javascript I no longer use if() statements without braces. The reason is that it's just too easy to mistakenly put:
while (true) {
if (a > b)
print a
print b
}
This is an obvious typo, but very easy to introduce, especially if you're editing existing code. I just call it defensive programming in my mind, but little tricks like this are valuable at making you better.
So, find a peer or mentor, and work on their code.
I am not sure if the OP was looking for general advice on how to be a good programmer, but rather something more specific.
I know I am reviving this thread, but I found it because I was trying to see if anyone asked this question already.
What I had in mind was, can we come up with a "knowledge-map" of programming concepts similar to the map that Khan Academy uses.
As a programmer, I want to be able to visualize the dependencies and relationships between different ideas, so that I can understand what skill level I am currently at; what I need to know before tackling a challenging subject; and be able to visualize my progress.
The very belief in the roadmap's existence blocks the road to perfection.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What type of client is likely to support XP (Extreme Programming) practices?
I'm working for a company which is doing Agile (not strictly XP, but still applicable), and our client base is exclusively government organizations. Once they saw the results of the agile process at work, even those who had requirements to provide documentation in a Waterfall like manner were more than happy to continue to reap the benefits of the agile process.
And, yes, I agree with vfilby. Your customers should care about the results, not how you achieve them.
If your team achieves great results with a proven track-record, then companies desiring a successful result. If the converse is true, only companies who are wandering blindly will be interested.
There is the odd case where the client will want a certain practices followed. Like a experienced dev manager outsourcing a project to an external firm, or potentially a client who has heard that XP is good in passing but has no real knowledge or experience with it. In the former the experienced consumer will know what he wants and if you do not provide those services they will go elsewhere. If you try to fake it, they will know and be most displeased. The later, it doesn't matter so much as long as they get good results and think it was their own wisdom that brought them forth from the ground.
Either way, it is results that matter.
Now begins my diatribe which so far has inspired much ire:
Would you jeopardize your good practices just to suit a client? If you are staunchly in favour of XP, sell it! If they want you to use a methodology that you strongly disagree with. Tell them that. If you can't come to a consensus, there should be no deal.
Do I tell a baker what grain to use? How hot to have the ovens? Hell no. If I say I want poppy seeds on the buns I don't care how they are put there so long as they are there. Dp I select a baker based on his methods, or on how damn tasty the bread is? Letting a non programmer tell you how to do your craft is just plain bad.
If you are trying to extol the virtues of XP then be upfront, pitch the cost-benefits and ROI. Show them why it is better for them in terms of developer efficiency and defect reduction. If you are working for non-programmers, you are the expert, take the reigns and give advice.
If your team excels at XP and has great results you will have no problem selling any potential client on your practices. Results matter to clients; if you can prove that you consistently produce high quality products within consistent timelines you should have no problem selling your methodology. (with some exceptions that absolutely require waterfall).
Either clients who've already had good results on XP projects.
Or clients who've swallowed the Kool-Aid.
Which arguably makes these clients few and far between :-)
I think it probably takes less convincing than it used to for customers to accept agile development practices, particularly XP, since they are now much more mainstream. Customers who have had positive experiences with agile teams in the past are more likely to buy into these methods. It's probably easier for a smaller customer, or a customer with a smaller problem to accept XP if they have concerns about it. With a skeptical customer, I would suggest starting small and building confidence. And make sure you deliver on your promises!
Almost everyone else seems to be interpreting your question in the context that you are or work for an ISV writing custom software for a client. Is that the situation?
If your question had been something along the lines of what kind of company is likely to adopt XP, then I would say a company who has been burned in the past spending too much time writing developer documentation and designing for reuse only to have to throw it all away as a big waste of time and effort.
The customer has to accept iterative delivery with fixed time, fixed resources, fixed quality (it's working to 100%), and a slightly variable scope, per iteration.
However, it is much more usual that they want to fix time, resources, quality AND scope.
The type of client that is likely to support XP practices,
is one that already understands the benefits and drawbacks of the software production system that XP provides.