Re^2: "Designing" a Perl program

Thankfully, I understand point #3 above. But, let me understand the first two --

"I want you to write me a program that will do this on that computer using the other tool". Let's break it down --

Responsibilities -- I have to write a program. That is my responsibility. The program has to do "this." That is the program's responsibility.

I am going to sound like a doofus, but what are the "specs"? Are this, that, and the other the specs? Generally, when I think of specs, I think the way a car has specs -- it gives 4 gallons to a mile, it seets a football team, and it is as tall as a horse. If I think if it that way, perhaps my program's specs might be that it has to do this in 24 hours, or it has to be done on that computer which has a hobbled operating system.

--

when small people start casting long shadows, it is time to go to bed

Comment on Re^2: "Designing" a Perl program

Replies are listed 'Best First'.
Re^3: "Designing" a Perl program by dragonchild (Archbishop) on Jan 14, 2006 at 21:18 UTC
Wikipedia is always a good place to check. I generally use Google as a starting point. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^4: "Designing" a Perl program by punkish (Priest) on Jan 14, 2006 at 23:41 UTC
Hi dragonchild, Perhaps my question indicated that I haven't done my homework, but it is not so. The field of software design, if there is any such beast, is full of a surprising amount of bullshit. Everyone seems to be an expert, and they all seem to be talking through a buzzword generator of some sort. They talk of "class diagrams" and "domain diagrams", and then they talk of "domain class diagrams." They ask to do "data flow analysis" and "event flow analysis," and then some hotshot asks for "data event flow analysis." All this sets my bullshit-detector flying high, and I start getting rashes. A couple years ago I had no idea what UML was. Now UML is all the rage. Everyone talks of state and sequence diagrams, and static and dynamic maps. None of the Perl books I have read talk about any of this, iirc. And they are all fine books. I've got some sensible advise on this thread, and I will try and follow that. I really want keep things as simple as possible, because, to paraphrase someone much wiser than I, I firmly believe in striving for the simplest thing that will work. Many thanks. -- when small people start casting long shadows, it is time to go to bed	[reply]
Re^5: "Designing" a Perl program by dragonchild (Archbishop) on Jan 15, 2006 at 01:27 UTC
It's not so much that I thought you hadn't done your homework as the term "specification" is such a basic and simple one. It's the checklist your program is going to have to pass in order to be considered done. It's the list of "This has to do X" and "This has to do Y". It can be as formal as an 800-page document written by consultants making more in a day than I do in a year which has been reviewed by 3 committees or as informal as a sketch on the back of a cocktail napkin. I've worked from both. In other words, it's how you know you can ship. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]