The fundamental problem is that customers don't know what they want, and if they do, they envision it within a very narrow context rather than
what is possible and do-able. This in no way devalues their input, but the key to a really good software design is vision. The scenario described
above has compartmentalized vision as outside the scope of all three groups of players. This is why we need software architects that can bridge
the gap and have some idea of what is possible.
You are correct. Customers never know what they want. This is the basis of XP. So what you do is get them to try and break up what they think they want into small deliverables. And constantly be in communication with them. If possible have them part of the team. When estimates are wrong, make a note of it, track it and go back to the customer to refine the picture. If features need to be dropped or pushed until a later chunk of work, do it. You really need to read more than this article to understand it.
Finally, it seems to me that XP is still doomed as a way to write breakthrough apps simply because it generally pushes big developmet groups
and flies in the face of Bill Joy's smallness principle: Good software is never written by more than about six people. You can have a bunch of
others testing and whatnot, but all the design decisions need to be made by a small group, or you're toast...
Actually XP is exclusively for small groups. 4-10 is the optimal. It is not designed for large groups.
XP still has requirements, unit tests and intregration tests. In fact they're essential.
XP provides a framework to constantly learn, constantly change, constantly test... with confidence.
XP appears to manage risk extremely well. Constant tracking, contant testing and always doing the most important things first make your software very close to releasable.
Its true that less experienced or dumber people will slow down the really smart ones. If people are really that dumb that working with a smart one won't rub off: get rid of them. That is what XP teaches. XP isn't for every one. Its not for every team. Then again neither is programming.
If you CAN'T get rid of that person then you a bigger problem then one person slowing down another. If you can't spread knowledge around in a group, you have an even bigger problem when alpha geek leaves. Hey it happens, alpha geeks are awesome in any setting. They get hired away.
But if the person is teachable, eventually they get it. They get better. And they may even add value to you. Pointing out places where you make simple mistakes, or get lax with testing or code style.
And hey, in XP pair programming doesn't require you pair with the same person all the time. Some people just aren't good together. XP is about learning.
Unit tests in XP are for testing everything that could break. The only people who know that is the programmer. All unit tests must test 100% in the checked in code. If they don't, you must fix them before you do anything else.
Programmers don't write test specs. They write tests. In fact they don't write code first, they write tests first and then make the code work with them.
These unit tests are like smoke tests. But they are fairly comprehensive. They give you the ability to refactor your code without the fear of breaking something unknown. As soon as you make the radical change, you know what broke.
Integration testing is VERY important. So is code integration. Code should not be left unintegrated for more than a day. Then all unit tests are run.
The customer (the person who forms the requirements) helps QA create the integration testing. The integration tests express their requirements. These tests are also called acceptance tests. The project isn't done until 100% of these tests pass. And they don't have to be written all at once. New ones can be invented. Hopefully as the project progresses you'll have more of the tests pass. They should be run often (a couple times a week) but not all the time. They can help guage the progress of the project.
According to a ReplayTV vs. TiVo Comparison Chart the TiVo is expandable by sending it in (when the upgrades are available). ReplayTV supposedly should support external drives via firewire port "pending content encryption standard".
Adding any new drive wouldn't help. Apparently, the drives are special drives, like they use in video editting systems. Besides 18GB wouldn't give a lot more. The 30 hour TiVo uses a 27.2GB drive.
Given the price, I can't see a huge demand either. $700 for a "VCR", plus $200 for the TV listing. YIKES!
However, _I_ want one, or something like it. Why? I use my VCR for recording more than I use it for viewing rental tapes. I have large collections of tapes floating around my apartment. I am forever searching for a blank tape. Or fast forwarding to where I have already viewed it.
Being able to flip through a directory of recorded programs would be SO convenient. And recording them without much consideration for space (gee, how much is left on this 6 hour tape, 1:30? Oops, only 1:25, I missed the resolution to the X-Files.
Plus the pausing of live TV would be great when I have to put the kids to bed.
It is a lot different from tape. And although the TiVo doesn't make saving programs easy, Replay TV does. I disagree VCR+ is a close enough solution. With TiVo (and ReplayTV) No listings to pour through. My onscreen cable listings don't include VCR+ codes.
Altough TiVo and ReplayTV are expensive they are cool, meaning geek reviewers don't need to be paid.
Slashdot Mirror
You are correct. Customers never know what they want. This is the basis of XP. So what you do is get them to try and break up what they think they want into small deliverables. And constantly be in communication with them. If possible have them part of the team. When estimates are wrong, make a note of it, track it and go back to the customer to refine the picture. If features need to be dropped or pushed until a later chunk of work, do it. You really need to read more than this article to understand it.
Finally, it seems to me that XP is still doomed as a way to write breakthrough apps simply because it generally pushes big developmet groups and flies in the face of Bill Joy's smallness principle: Good software is never written by more than about six people. You can have a bunch of others testing and whatnot, but all the design decisions need to be made by a small group, or you're toast...
Actually XP is exclusively for small groups. 4-10 is the optimal. It is not designed for large groups.
Also get this book written by one of the pioneers of extreme programming (which has been around for 5 years BTW): Extreme Programming Explained: Embrace Change by Kent Beck.
If you CAN'T get rid of that person then you a bigger problem then one person slowing down another. If you can't spread knowledge around in a group, you have an even bigger problem when alpha geek leaves. Hey it happens, alpha geeks are awesome in any setting. They get hired away.
But if the person is teachable, eventually they get it. They get better. And they may even add value to you. Pointing out places where you make simple mistakes, or get lax with testing or code style.
And hey, in XP pair programming doesn't require you pair with the same person all the time. Some people just aren't good together. XP is about learning.
Unit tests in XP are for testing everything that could break. The only people who know that is the programmer. All unit tests must test 100% in the checked in code. If they don't, you must fix them before you do anything else. Programmers don't write test specs. They write tests. In fact they don't write code first, they write tests first and then make the code work with them. These unit tests are like smoke tests. But they are fairly comprehensive. They give you the ability to refactor your code without the fear of breaking something unknown. As soon as you make the radical change, you know what broke. Integration testing is VERY important. So is code integration. Code should not be left unintegrated for more than a day. Then all unit tests are run. The customer (the person who forms the requirements) helps QA create the integration testing. The integration tests express their requirements. These tests are also called acceptance tests. The project isn't done until 100% of these tests pass. And they don't have to be written all at once. New ones can be invented. Hopefully as the project progresses you'll have more of the tests pass. They should be run often (a couple times a week) but not all the time. They can help guage the progress of the project.
According to a ReplayTV vs. TiVo Comparison Chart the TiVo is expandable by sending it in (when the upgrades are available). ReplayTV supposedly should support external drives via firewire port "pending content encryption standard".
Adding any new drive wouldn't help. Apparently, the drives are special drives, like they use in video editting systems. Besides 18GB wouldn't give a lot more. The 30 hour TiVo uses a 27.2GB drive.
Given the price, I can't see a huge demand either. $700 for a "VCR", plus $200 for the TV listing. YIKES!
However, _I_ want one, or something like it. Why? I use my VCR for recording more than I use it for viewing rental tapes. I have large collections of tapes floating around my apartment. I am forever searching for a blank tape. Or fast forwarding to where I have already viewed it.
Being able to flip through a directory of recorded programs would be SO convenient. And recording them without much consideration for space (gee, how much is left on this 6 hour tape, 1:30? Oops, only 1:25, I missed the resolution to the X-Files.
Plus the pausing of live TV would be great when I have to put the kids to bed.
It is a lot different from tape. And although the TiVo doesn't make saving programs easy, Replay TV does. I disagree VCR+ is a close enough solution. With TiVo (and ReplayTV) No listings to pour through. My onscreen cable listings don't include VCR+ codes.
Altough TiVo and ReplayTV are expensive they are cool, meaning geek reviewers don't need to be paid.