If the lowest common denominator means that you get code that both programmers easily understand, then isn't that a good thing? Isn't it more,likely that the code will be easily maintained in the future because any programmer is likely to be able to understand it?
Surely better than a single programmer developing 'clever' code that takes anyone else ages to decipher?
ALso, the assumption is that you don't employ crap developers on any team. If they are still learning, that's one thing, but if they are just crap, then pair programming and code reviews should weed them out pretty quickly
Well... theoretically... assuming that anyone who looks at what they do understands it -- it works OK in large organizations, but in many cases, especially in smaller startups, the pair of them may well be the only programmers in the organization - don't laugh: this happens far more often than you think...
Properly "clever" code is instantly understandable: it should be elegant and light with an obvious purpose. Tricky, write-only code isn't necessarily clever code...
[crap developers]: Have you tried employing any programmers recently? I have - it's a depressing exercise... it seems that a few years ago, a huge number of students emerged from college holding shiny new computer science degrees... and nothing else - ability, knowledge or talent, for example. There's just... too many of them!!
We've been hiring recently - so far without success. I wrote a little test for the candidates: just three questions, each of which requires a little bit of lateral thinking.
The first was an SQL question: a table containing people, a table containing sports (each of which was basically an identity column and a text field), and a link table between them for a many-to-many join. The question said, "Write a query to return the names of the people who play *every* sport." Nobody got this right, although one guy almost worked out the idea of it.
The second question said, "Write an algorithm to produce a 20-element array with the numbers 1 to 20 in random order in it. Assume you already have a function to create a random number." Nobody could do that, either. One guy said, "I can't do this. It's not a business function." The only guy who even made a basic attempt at it wrote one of those things where you think up a random number for each array element and then check to see if you've used it before, and keep thinking up more random numbers until you're done. Horrible.
The third question was:
a^=b; b^=a; a^=b; // or in C, a^=b^=a^=b -- which doesn't work in C# for some reason.
What are the values of a and b when the code has run?
Strangely, the guy who complained about the business function knew the answer immediately (that it swaps the values) -- but he was old - binary XORs were obvious to him, even though nothing else was.
To take the pressure off a bit, I told the candidates that a right answer and perfect syntax weren't the point - that the test was for me to be able to evaluate how they think... apparently, none of them could. The closest answer to question 2 was from a guy who sort of got the point, but was using things like SortedList and inbuilt Sort functions to do it -- I asked him if he could do it using a simple array and actual code, and he couldn't. Amazing.
Oh, well - it looks as though my test was pretty good!
I've said it before, I think tests like this are generally a waste of everyone's time.
The SQL one amazes me nobody got it - I'd put it in the trivial SQL pile.
The third question I wouldn't know the answer to - I have no idea what the little hat symbol is used for in this context - but i am a good developer -so your test fails.
Second question I can imagine people coming up with all sorts of answers - but what's the point? And then one comes up with an answer and you change the goalposts? Why couldn't he use a sort function etc.?
I prefer to have a conversation with interviewees - talk about what they have done, what they want to do, have them talk through some stuff.
Looking at their resumes i make a call on how competent they should be - I try to give them a look at the code base they'd be working on, introduce them to the developers they'd be working with, and let them ask me questions.
I make it exceedingly cleat that I will sack them if they're crap at what they claim to be good at on their resume.
Actually, I didn't change the goalposts -- I told them before that they had to write an algorithm, not use library functions to do it. The SQL one is harder than it looks -- it's certainly not just a bunch of joins. Once I gave that question to a guy who made $150,000 a year back in the '90s doing SQL, and he said it couldn't be done. I didn't hire him.
The point of each question was to see if they could think -- I didn't want the guy to use a library function because if he's a programmer he should be able to program, not just use other people's code. For the sake of an interview question, I want something he could write in two minutes -- the point is to find out whether he tries to fill the array one number at a time, looking over and over again for distinct numbers (inefficient and stupid) or whether he fills the array with the numbers 1 to 20 in sequence and then swaps each element with a random one (efficient).
In the third question, ^= means XOR = (which I explain in the question) -- I want to see whether these people understand anything at a level lower than the user interface they're designing. It's not possible to describe the amount of value that an understanding of machine code adds. Apparently, the only one who did was incapable of doing anything about it.
I also did have a conversation with them first -- of course that's important. But at some stage, I want to know how their brains really work.
Marc Clifton wrote: Would you read (YA) book on this topic? What would it take to get you to read such a book? --------------------------------------------------------------------------------------
With the number of books already on the market on the Software Development and XP, I couldn't imagine wanting another, unless...
Unless, that book took on a code-and-architecture implementation driven approach using an actually real world project, or better yet, series of real world projects from different industry domains and technologies, to explain each step of the Software Development process. The idea here could be (should you consider this) show just how extreme programming can be implemented in a complete traceable Software Development Life Cycle (SDLC for short) - if, indeed, this is possible.
The reason I say this is because my experience of XP leads me to see the process as strictly a creative process that can be used within a SDLC framework. This notion may sound strange but the reality is that the current (and even the tradition) SDLC frameworks have already clearly shown their strengths to account for project management for managing the Software Development effort. And, I believe, due to a number of problems including the lack of software development standards, that XP is now showing a strong means to ensure the software process gets done while allowing the developer(s) an excellent piece of mind to exercise their creativity as they are applying their skills, learning from each other, learning new technologies, and capturing a happier customer in the process.
So while the current SDLC (or perhaps, someone can introduce a modified version of XP to include a strong project management framework) can be used to manage the project, then the XP lead implementation for developers would serve as the highly aggressive approach to product delivery and developer retention. Once we have achieve this combination, I believe (that's just me) that XP will be adopted faster than I am taking to writing this message!
Of course, the title of the book can reflect on this stance and as a final point - we love stories (haven't met anyone who doesn't) and, we in the developer community, especially, crave for those stories of people (developers' experiences) at work actually doing the stuff - making the book in this fashion can make it irresistible. (Heck, I am still craving for more literature like the book called "Extreme Programming Adventures in C Sharp")
But, I believe the point is that extreme programming on its own still has to prove itself TO BE on its OWN, which I'm sure most folks will agree with me. So, if you can write something (perhaps like what I've just mentioned or better) then XP will finally have its place (and developers WORLDWIDE will be thanking you (or whoever) for their enjoyment AND piece of mind).
----------------------------- Jose Montero MONTEC Computer Software & Training Services firstname.lastname@example.org
I hope your experience of Dubai was better than mine. Overnight stops going to and from Uganda; on the way out trying to sleep on hard plastic benches, on the way home stuck for four hours because their computer systems were not working properly.
One of these days I'm going to think of a really clever signature.
My worst was only two changes: Paris and Karachi.
Paris was a PITA (as it always is), but Karachi was just stupid - 7 hours, and a body search to get into the transit lounge where the Goat Curry was. Mind you, it was good Goat curry.
If you get an email telling you that you can catch Swine Flu from tinned pork then just delete it. It's Spam.
Wake up at 02 am, to get to the airport 1,5 hours driving.
Wait there 2 hours
1,5 hours flight (Lombok -> Jakarta)
12 hours wait
6,5 hours flight (jakarta -> doha)
3 hours wait
9 hours flight (doha -> munich)
2 hours car
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.