On Jan 16, 2008 7:18 PM, Darren New <[EMAIL PROTECTED]> wrote: > Bob La Quey wrote: > > Of course you do not have a customer who knows what they want. > > That is one reason why definition is hard and requires a lot > > of face to face. I must say I have almost never had a > > customer who knew what they wanted. > > Which means writing it down in advance and then saying "is this what you > want?" generally doesn't work very well.
The approach to the customer is face to face and very interactive. It is only after a lot of back and forth that one begins to have a written item. This back and forth may also include prototype UI's etc. But no code development that takes very long. Strictly RAD. > >> (b) you can figure out what the customer wants, > > > > If you cannot then you really should _not_ be doing the job. > > Worse I would say you are failing. Now, admittedly many projects > > and many consultants fail at this point. > > Yep. Sometimes the customer knows what they want but are unable to > express it. That's what I was trying to say. So you show them various > versions and zero in on what they actually think they want. Same answer as above. > >> (c) the requirements don't change in the time it takes to write it, > > > > Then you are taking too long to write them. > > No, the "it" there referred to the code, not the specs. OK. > >> and never even met the customer > > > > This is an advantage. It forces you, the system definer, > > to do your job. Why must the implementer meet the customer? > > > I worked for a decade as an outsourcer for a guy who was > > contracted to a Norwegian oil company. I _never_ met the > > customer, but David K. Walker, could tell me what to > > implement. Now I will admit that DKW is good. But dammit, > > that is my point. You need to be very good to do a decent > > job of system architecture and definition. > > So you're saying define everything so exactly that no misunderstandings > can occur and no misinterpretations are possible and nothing at all > needs to be assumed. No most such projects have versions. I do not see that it has to be set in concrete. But one can have months between versions rather than say days. > Sure, maybe, but it's probably cheaper not to outsource in that case. Maybe, maybe not. I think you have to look at each situation on a case by case basis. You also have to understand that many of your in house people will have a natural bias against outsourcing. Getting their cooperation can be a major issue. > > (e) that you convince the outsourcees that > >> they should do what you need rather than what's easiest and most > >> profitable for them, > > > > The same exact problem lies with any organization that contracts to > > have another organization develop software for them. > > Exactly, yes. > > >> and (f) you have a way of telling that what you got > >> back is what you asked for, and > >> (g) you can tell before you start which > >> outsourcing group will actually be able to accomplish what you're paying > >> them for, > > > > Clearly you have no clue how to manage a software project. > > Uh huh. And you've obviously never worked on something totally new > where the customers *cannot* know what they want in advance.[*] Actually I have rarely worked on anything except totally new things. And it is a fact that it is often a serious puzzle to find a customer for them, i.e. someone who "get's it" and has the resources to buy it. > > Understand that I'm talking about your premise, which is "1 - create > spec, 2 - throw over wall to implementers, 3 - take back results and use." > > With more and tighter cycles, this might work, of course. Maybe that is the main difference. I am not talking about a system of development where there is no feedback between the spec writers and the coders. That would be absurd. I am simply saying that on a large project you better have a damn good idea of what you want to do (i.e. a spec of some sort) before you start the doing. Do you really argue otherwise. > >> By the > >> time you can clearly write unambiguous specs and have an inexpensive way > >> of ensuring that the result meets those specs and is flexible enough to > >> meet your future needs, you have reduced the problem to something you > >> might as well just finish yourself - you've already done 90% of the work. > > > > This depends on the project. I used to agree with you. I no > > longer do. For small projects it is true. For larger projects, > > where the architecture is critical, I think you are wrong and > > that your approach will not work. > > What's the "my approach" that you think isn't working? It's kind of > funny, because I didn't say what my approach is, and here you're telling > me it's wrong. Ok. I apologize. I must have inferred from your comments that you considered the spec so difficult that it consumed 90% of the effort. I see it as more like 25% of the effort. Perhaps you would like to elaborate on your approach and clear up my misperception. > > An alternative approach that some say is the only way that > > ever works is to start with a small project then when that > > is successful to flesh it out. I always want to see what I > > call a "tall thin man", a prototype that touches all of the > > bases with as many stubs as necessary as early as possible. > > Yep. And then as you flesh it out, you find there are dozens of > interfaces and functionalities and failures-of-underlying-support that > were not and could not be considered. Yes, that can happen. Especially if you take a pure top down approach, which I have never done. My approach is to build thin bottom up layer tied to a tall thin top down layer. Then to flesh out the in between. Pure top down tends to develop exactly the problems that you are describing. > > The "tall thin man" encapsulates the architecture but will > > not have much functionality. I literally consider this the > > most important part of the spec. > > Yeah, it's a good part of it. > > Maybe I've just never worked on a project the right size to be > outsourced. I've done medium-scale things, and dozen-person things, and > one-two-three person things, but never something like an OS from scratch. > > [*] Not that I believe this is true, but I have as much reason for > saying it as you have of impuning my skills. Again I apologize for my misunderstanding. Software development is difficult because of the issues you mention many of which can be characterized as ambiguity. Indeed one might say that software development is simply the reduction of ambiguity to zero. I suggest that one advantage of having say separate groups work on a project is that the interfaces between the groups and their work products need to be written and rather formal, not the sort "Hey Joe, what is in that struct" sort of informality that often goes on in a single tight knit group. This means that documentation is being produced along with the work product (be that product code or spec) and this is a good thing. Nowhere have I said it was easy. Nor have I said that every project is suitable for outsourcing. But sometimes it is a good solution. Indeed there are many cases, which we do not call outsourcing, but which require groups to work together in order to build something that have the exact same problems as outsourcing. If you can figure out a way to build those systems without any formal and structured communications between the groups then you have solved one of the biggest problems around. BobLQ -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
