a defense of ad hoc software development
in [Lisp]
|
Prev: Some help with sort
Next: SBCL optimization
From: ccc31807 on 15 Jan 2010 10:30 On Jan 14, 5:29 pm, fortunatus <daniel.elia...(a)excite.com> wrote: > Nobody expects non-programmers to be able to generate programmers's > requirements. I don't know the difference between 'requirements' and 'specification' but I assume that the requirements state what the software will do, and the specification states how the software will do it. People like to poke fun at UML use cases and use case diagrams, me included. However, use cases can describe in the language of the problem domain the functional requirements (if not the non-functional requirements as well), e.g. - customer presents the goods to the cashier - cashier determines the price of the goods - cashier calculates the total price including tax - cashier informs customer of the total price - customer tenders the price in cash, check, or plastic - cashier accepts customer's tender - cashier gives customer a receipt for the goods. > Programmers generate requirements for themselves based on less formal > Q&A with the customer. It may be more accurate to say that the programmer generates the design based on (1) functional requirements furnished by the client, and (2) an explicit or tacit specification based on those requirements. > requirements might be in the programmer's head, and they might be > developed by evolutionary process throughout the code writing, but > they exist. I've been taken to task (on c.l.p.m.) for saying that many times I just start writing code without doing any analysis or design. Obviously, for a larger project, analysis and design is essential. I think that Graham's point is that analysis, design, and implementation can be integrated with more efficiency and less work. Obviously, you can't build a sizable application this way, but just as obviously any sizable application necessarily contains problems that can only be solved by experimentation. CC.
From: Tim Bradshaw on 15 Jan 2010 18:28 On 2010-01-15 02:44:15 +0000, Barry Margolin <barmar(a)alum.mit.edu> said: > Writing specifications precise enough to be validated > mechanically *is* programming. I was going to say "and there are these programs called compilers which turn them into executable programs" but that's not quite right. A specification could just give a way of testing whether something meets it, without giving a way for that thing to be constructed, while a program has to give a way to construct that thing. So perhaps a specification is not programming: it's just something which is as hard as programming.
From: Tim X on 15 Jan 2010 18:42 Pascal Costanza <pc(a)p-cos.net> writes: > 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?" > > Even worse - the customer who thinks they know what the solution is. Instead of bringing you the problem and asking if you can solve it, they bring you the solution and want you to implement it. You take one look at the proposed solution and can see lots that is wrong or just won't achieve what the customer wants. Now you have the fun of trying to explain to them why their brilliant idea is rubbish and propose something better, but of course, 90% of what your tyring to explain they don't understand! Tim -- tcross (at) rapttech dot com dot au
From: MarkHaniford on 15 Jan 2010 18:46 On Jan 14, 8:44 pm, Barry Margolin <bar...(a)alum.mit.edu> wrote: > > That may be true, but what he says in this particular article is > correct. Read the book "Coders at Work", and you'll learn that most of > the great programmers think similarly. Programming simply cannot be > mechanized. Writing specifications precise enough to be validated > mechanically *is* programming. > Programming is already mechanized. The problem is with having "business analysts" spending 10x as much time "writing out the specs" to be mechanized than a "normal" programmer. Or on another note, your CFO could spend hours a day cleaning toilets at the office too.
From: Tim X on 15 Jan 2010 19:11
ccc31807 <cartercc(a)gmail.com> writes: > > I've been taken to task (on c.l.p.m.) for saying that many times I > just start writing code without doing any analysis or design. > Obviously, for a larger project, analysis and design is essential. I > think that Graham's point is that analysis, design, and implementation > can be integrated with more efficiency and less work. Obviously, you > can't build a sizable application this way, but just as obviously any > sizable application necessarily contains problems that can only be > solved by experimentation. > Analysis is critical because that is how, you as the programmer, get to understand the domain problem you will be working in. Design is also important, but it should not be carved in stone. I think PGs main point is that it is often during the implementation that you gain that deeper understanding of the problem that provides the insight for better solutions and you want to avoid any specification that is so detailed that you cannot adopt those better solutions because they would not fit with the specification. I've worked on projects in the past where the specification was so detailed, it included all the names of procedures/functions, the arguments they would accept and the values they would return. As a developer on that project, all you were expected to do was write those functions and procedures and at the end, it would all fall together. It was an uninspiring, horrible boring project and it was pretty much a failure. I think what PG is talking about is close to what the Agile (God I hate that term - bloody weasel word. Lets face it, who the hell doesn't want to be 'agile'!) camp has been proposing. Use user stories to get an understanding of what is required and then use test driven development to not only verify the code and protect against regressions after refactoring, but also to verify you as the programmer understand the customer/owner's requirements. This is why tests should be developed in conjunction with the product owner or representatitve/expert from the client side. Requirements and specifications are all about communication. They are there to ensure that everyone knows what the widget is and what the widget needs to be able to do. The old waterfall methodology tried to make it like dam and bridge building - eveyrthing would be specified down to the last bolt and nail. Management would know exactly how much it would cost and exactly how long it would take to build (at least, they felt reassured they did). This approach essentially failed. It failed because it was unable to take into account that programming isn't like dam and bridge building. We don't have the hundreds of years experience or the relatively well understood laws, such as the laws of physics, that engineering in the physical world has. Programming has more art than science. The solution often comes with understanding and imagination, which is acquired as you attempt to solve the problem and will seldom become obvious through analysis alone. A major point that PG was trying to make is that your development environment can assist in this process by making it easier to experiment and explore the problem domain. He argues that lisp is one of the best languages for doing this and it is why he believes a single lisp developer can be more productive than, lets say, a developer using C. This theme is also carried through in his other writings. For example, he argues that the success of viaweb was because it used lisp and they were able to add features faster than their competition. In fact, he says that their competition often thought he had spies in their team because they would release a new feature and viaweb would have incorporated it by the end of that day. Tim -- tcross (at) rapttech dot com dot au |