I mainly agree on this. As dragonchild says, you need to breakdown the system into a small chunks, decide how they interact with each other and document that.
However, I would suggest that you use same tools for documenting and designing the program as everybody else. That should make it easier in the future to read them, since the documentation is more consistent. You don't have to use all the tools all the time. For example if your solution doesn't involve object oriented code, UML most likely won't play as big role as it otherwise would.
| [reply] |
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
| [reply] |
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] |
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] |