a defense of ad hoc software development
in [Lisp]
|
Prev: Some help with sort
Next: SBCL optimization
From: Marc Girod on 15 Jan 2010 04:54 On Jan 14, 10:29 pm, fortunatus <daniel.elia...(a)excite.com> wrote: > Nobody expects non-programmers to be able to generate programmers's > requirements. Unfortunately, many people do. This is bullshit from the start and results in more bullshit. How this bullshit is dealt with is an important part of everyday life nowadays. > Programmers generate requirements for themselves based on less formal > Q&A with the customer. Formality is another interesting way to glide astray from reality. Formality doesn't bind to precision, or to correctness. Formal semantics are a myth, precisely one which fights the reality of code semantics. What makes code semantics special, and thus more interesting, is that code is meant to be run, and not only to be read. That is, contrarily to any other kind of representation, code is not semantics about something else: it is embodied, operational, semantics. Now, the problem is one of communications (whether Q&A with customers or else.) > The > requirements might be in the programmer's head, and they might be > developed by evolutionary process throughout the code writing, but > they exist. Until there is a program, their existence doesn't imply 'essence', i.e may not be consistent of even feasible (no proof of convergence). > My point is that the work needs to be broken up and distributed among > team members before ambiguity is resolved. And even then. Ambiguities get resolved while merging the contributions (aka integration). Marc
From: Nick Keighley on 15 Jan 2010 06:28 On 14 Jan, 22:29, fortunatus <daniel.elia...(a)excite.com> wrote: > On Jan 14, 9:46 am, ccc31807 <carte...(a)gmail.com> wrote: > > In my own job, which requires writing software for lay users, all I > > ever get is abbreviated English language requests, and I have learned > > better than to ask users for their requirements because they have no > > idea what requirements are. > > Nobody expects non-programmers to be able to generate programmers's > requirements. but it isn't unreasonable to expect them to be able to articulate their own requirements. Do they want a word processor or an ABS? > Programmers generate requirements for themselves based on less formal > Q&A with the customer. > > No matter what, a programmer works to specific requirements that are > supposed to match the user's expectations and/or needs. The > requirements might be in the programmer's head, and they might be > developed by evolutionary process throughout the code writing, but > they exist. If there is more than one programmer on a team then there > is a need to codify requirements into documents to some degree. > > I think it is not feasible to say that requriements can be so detailed > as to be directly executable. various people have though (wrongly I think). The TDD people sometimes claim the test is an executable requirement. > In teamwork it is useful to communicate > when there remains a large degree of ambiguity, and allow team members > to contribute to resolutions. > > So you can use Lisp to capture/express requirements, no. requirements are a communication with an end user. Only the most sophisticated of end users could be epected to read lisp. > but it won't be a > complete solution to the problem before you break the work up among > team members. Yet at that stage it would normally be named a > requirements document. > > My point is that the work needs to be broken up and distributed among > team members before ambiguity is resolved. At that point there should > be some requirements written down for team members to start working > from. Therefore the requirements, at that stage, even if captured in > Lisp or other executable format, /must/ have too many holes to really > solve the whole problem, or else the team is not dividing the workload > effectively.
From: Tad McClellan on 15 Jan 2010 06:54 ["Followup-To:" header set to comp.lang.perl.misc.] Nick Keighley <nick_keighley_nospam(a)hotmail.com> wrote: > On 14 Jan, 22:29, fortunatus <daniel.elia...(a)excite.com> wrote: >> On Jan 14, 9:46 am, ccc31807 <carte...(a)gmail.com> wrote: > > >> > In my own job, which requires writing software for lay users, all I >> > ever get is abbreviated English language requests, and I have learned >> > better than to ask users for their requirements because they have no >> > idea what requirements are. >> >> Nobody expects non-programmers to be able to generate programmers's >> requirements. > > but it isn't unreasonable to expect them to be able to articulate > their own requirements. Unreasonable? No. Unrealistic. Yes. :-( -- Tad McClellan email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
From: Tamas K Papp on 15 Jan 2010 07:20 On Fri, 15 Jan 2010 03:28:57 -0800, Nick Keighley wrote: > On 14 Jan, 22:29, fortunatus <daniel.elia...(a)excite.com> wrote: >> >> Nobody expects non-programmers to be able to generate programmers's >> requirements. > > but it isn't unreasonable to expect them to be able to articulate their > own requirements. Do they want a word processor or an ABS? Reasonableness is not the right concept here. There is a market for programmers, and some employers/customers want programmers who can write software without being given super-specific formal requirements. Programmers who can cater to this market by making an effort to understand the problem domain may enjoy an advantage. The market will decide. If you don't like the market outcome, you can complain that it is "unreasonable", but no one will care. Tamas
From: Pascal Costanza on 15 Jan 2010 09:52
On 15/01/2010 12:28, Nick Keighley wrote: > On 14 Jan, 22:29, fortunatus<daniel.elia...(a)excite.com> wrote: >> On Jan 14, 9:46 am, ccc31807<carte...(a)gmail.com> wrote: > >>> In my own job, which requires writing software for lay users, all I >>> ever get is abbreviated English language requests, and I have learned >>> better than to ask users for their requirements because they have no >>> idea what requirements are. >> >> Nobody expects non-programmers to be able to generate programmers's >> requirements. > > but it isn't unreasonable to expect them to be able to articulate > their own requirements. Do they want a word processor or an ABS? Customer: "I am the owner of a company, and I want my employees to be able to do their work more efficiently using computers. Can you help me?" Programmer: "So, do you want a word processor or an ABS?" Pascal -- My website: http://p-cos.net Common Lisp Document Repository: http://cdr.eurolisp.org Closer to MOP & ContextL: http://common-lisp.net/project/closer/ |