Am I Cheating?

Now, I originally thought that this story would turn out to be a really challenging test of my programming process. Introduced late in the project like this, it might require us to completely change the way things worked. It would address the fear we all have in an incremental project: that something will come along later that destroys our design. But instead we aren t getting a fair test of whether this process could really work. You feel ripped off ”heck, I feel ripped off! This wasn t hard enough.


Still, there s a lesson here. When you re working with the real users and they are faced with actually spending money for features, they ll quite often decide to take something that isn t quite perfect but that costs them almost nothing, like this solution. So, Mr. Customer, we can do this in an hour. This other thing is a bit neater, but will take a couple of days. This third thing will take a couple of weeks. You choose. A customer who s working well with you will almost always say, Give me the hour thing. We ll try that a while and if it doesn t work out, we ll try something else. They do this because they trust us, trust our estimates, and ”most important ”because they know they can come back.

When we re dealing with the guy in Marketing asking for features, it s more difficult. The end users now can t come back for a quick improvement if they don t like the simple feature. The Marketing guy rightly fears delivering too little to the customer, and he (not so rightly) often chooses to err on the side of asking for too much. We can help him out, however, in much the same way, by making the cost of features clear to him. Both time and money matter when you re trying to ship a product, and if we can make those costs visible to those who serve as our customer, it will always help.

So maybe it s not cheating after all.

(It turns out that there is another special request coming up later in the book, and that one as well turns out to be almost trivial to implement. Could it be that when we build well-structured code in an incremental fashion, almost all the things we have to do turn out to be fairly straightforward? My experience is that things do happen that way.)

Extreme Programming Adventures in C#
Javaв„ў EE 5 Tutorial, The (3rd Edition)
ISBN: 735619492
EAN: 2147483647
Year: 2006
Pages: 291 © 2008-2017.
If you may any questions please contact us: