First class developer: who ?
in [Java Help]
|
Prev: Speaking of thread safety?
Next: solutions manual to A First Course In Probability 7th Edition by Sheldon M. Ross
From: Martin Gregorie on 13 Mar 2010 16:57 On Sat, 13 Mar 2010 12:43:53 -0700, BGB / cr88192 wrote: > well, sometimes specs are found and implemented, other times, they are > designed and then implemented, and sometimes they develop naturally and > are codified later. > I'm entirely with Lew here. Unless the application is really trivial, typically half a day or less to design, implement and fully test, you'll probably take longer to get a satisfactory end result by barrelling in and starting to code right away than if you'd say down and thought the problem out fully before you start to code. "Thinking the problem out" *may* be purely getting the design right in your head if its the half day or less sized task but if its any longer than that, then producing some form of documentation is usually called for. Examples: (1) I designed, coded and tested a mix of awk and shell script yesterday. Its purpose is to take an easily maintained list of words, phrases and regexes and construct a SpamAssassin rule from them. I spent about half the time picking a set of rules apart into lists of elements plus a few parameters to specify features of the rule as a whole. That was the design process. The resulting set of files, each containing a rule's components, when combined with what I'd learnt by disassembling them was both specification and test data. I even surprised myself by how fast the code went together. Rigorous testing? Spamassassin took care of that: if it successfully parsed the rule and produced the same results as it did when running the original rules then the rule building code is OK and I have a much easier way of maintaining these rules than I did yesterday morning. (2) If the task will take a few days, such as writing a non-trivial Java library class, say for parsing or writing CSV files, My design document is often written as an overall description of the classes purpose, functionality and processing options followed by API definitions and associated textual descriptions of their intended use. When I'm happy that the requirement is complete and doable I can turn it into a class file by making text into comments and APIs into method interfaces, add a few curly brackets and return statements and have something that is immediately compilable. Then I can generate javadocs to see if they are readable and tweak the text to suit. After that I can write a test harness, test scripts and add code into the skeleton. Just as Lew probably does, I'll often do these three in parallel but with carefully compartmentalised thought processes: its *much* better to write the test script(s) and add the call to the test harness before actually coding the content of any particular method. Additionally, you can start regression testing long before the coding is complete. -- martin@ | Martin Gregorie gregorie. | Essex, UK org |
From: Lew on 13 Mar 2010 17:47 Martin Gregorie wrote: > (2) If the task will take a few days, such as writing a non-trivial Java > library class, say for parsing or writing CSV files, My design document > is often written as an overall description of the classes purpose, > functionality and processing options followed by API definitions and > associated textual descriptions of their intended use. When I'm happy > that the requirement is complete and doable I can turn it into a class > file by making text into comments and APIs into method interfaces, add a > few curly brackets and return statements and have something that is > immediately compilable. Then I can generate javadocs to see if they are > readable and tweak the text to suit. After that I can write a test > harness, test scripts and add code into the skeleton. Just as Lew > probably does, I'll often do these three in parallel but with carefully > compartmentalised thought processes: its *much* better to write the test > script(s) and add the call to the test harness before actually coding the > content of any particular method. Additionally, you can start regression > testing long before the coding is complete. Place a ruler on your two extended index fingers. From in front of you, it looks like this: __________ O O where the little circles represent the view of the tips of your index fingers, and the line represents the ruler seen edge-on. Only your two extended index fingers support the ruler. Now slowly move your two fingers toward each other without otherwise touching the ruler: __________ O O --> <-- As your fingers move together, the ruler will wobble and regain balance repeatedly until your fingers meet. Your fingers will meet at the exact center. As they move, the ruler's friction will catch sometimes on the left index finger, letting the right one progress, and sometimes on the right index finger, letting the left one move. It's a dynamic balance that alternates movement until it meets at the perfect center. In software development, you go back and forth between the "left index finger" of planning and the "right index finger" of implementation. If you follow the correct process, some of one, then some of the other, it will converge on the exact balance point between the two. In my new project, I had to spend the first week putting together a sample of the example of the proposed prototype, since the client has no specification. This creates a working, deployable framework, upon which I can hang any reasonable interpretation of the project's goals. There's a working database, screens can navigate to each other, the program can access the database, there's a mechanism in place to control the look and feel easily, but we still don't know exactly what we want to the program to do. Coming into the second week, I have be careful lest the client expect me to somehow magically produce exactly the thing they imagine, even though they have yet actually to imagine it. That means, as architect, designer, implementer and chief bottle-washer for this proposed prototype, I must now gently and compassionately guide the client to reveal their hopes and dreams, and I must be the documenter, too, writing down and editing their fantasies to realizable specifications. Oh, yes, editing. But every change, clarification and requirement will be provably and beyond suspicion the client's idea. -- Lew "Trust me, later you'll thank me for this." Adrian Monk, /Monk/ USA Network
From: Tom Anderson on 13 Mar 2010 19:02 On Sat, 13 Mar 2010, Lew wrote: > Place a ruler on your two extended index fingers. From in front of you, it > looks like this: > > __________ > O O > > where the little circles represent the view of the tips of your index > fingers, and the line represents the ruler seen edge-on. > > Only your two extended index fingers support the ruler. > > Now slowly move your two fingers toward each other without otherwise touching > the ruler: > > __________ > O O > --> <-- > > As your fingers move together, the ruler will wobble and regain balance > repeatedly until your fingers meet. > > Your fingers will meet at the exact center. As they move, the ruler's > friction will catch sometimes on the left index finger, letting the right one > progress, and sometimes on the right index finger, letting the left one move. > It's a dynamic balance that alternates movement until it meets at the perfect > center. > > In software development, you go back and forth between the "left index > finger" of planning and the "right index finger" of implementation. If you > follow the correct process, some of one, then some of the other, it will > converge on the exact balance point between the two. I've only got a tape measure. tom -- The future will accost us with boob-slapping ferocity. -- H. G. Wells
From: George Neuner on 13 Mar 2010 19:09 On Sat, 13 Mar 2010 07:49:47 -0700, "BGB / cr88192" <cr88192(a)hotmail.com> wrote: >"logic" is then almost meaningless on natural speech, and one is probably >far better off with a probablistic interpretation. You've just defined the field of "informal logic". George
From: BGB / cr88192 on 14 Mar 2010 00:04
"Martin Gregorie" <martin(a)address-in-sig.invalid> wrote in message news:hnh1nf$pe5$1(a)localhost.localdomain... > On Sat, 13 Mar 2010 12:43:53 -0700, BGB / cr88192 wrote: > >> well, sometimes specs are found and implemented, other times, they are >> designed and then implemented, and sometimes they develop naturally and >> are codified later. >> > I'm entirely with Lew here. > > Unless the application is really trivial, typically half a day or less to > design, implement and fully test, you'll probably take longer to get a > satisfactory end result by barrelling in and starting to code right away > than if you'd say down and thought the problem out fully before you start > to code. "Thinking the problem out" *may* be purely getting the design > right in your head if its the half day or less sized task but if its any > longer than that, then producing some form of documentation is usually > called for. > in my case, I may sometimes end up spending maybe a few days or more considering possible options and possible designs, and then may often write up an "idea spec" (usually a few pages or more describing the feature I am considering). usually, this would be used for starting on the coding, but then maybe relevant observations are noted while implementing, and the design may be tweaked some in the process. another common scenario is where I really don't want to go through this much effort, and so something "close enough" is found and used as a design template (I just implement something according to a pre-existing spec or standard). othertimes, code is just left to live on over a long period of time, and may eventually mutate some as time goes on, ... > Examples: > (1) I designed, coded and tested a mix of awk and shell script > yesterday. Its purpose is to take an easily maintained list of words, > phrases and regexes and construct a SpamAssassin rule from them. I spent > about half the time picking a set of rules apart into lists of elements > plus a few parameters to specify features of the rule as a whole. That > was the design process. The resulting set of files, each containing a > rule's components, when combined with what I'd learnt by disassembling > them was both specification and test data. I even surprised myself by how > fast the code went together. Rigorous testing? Spamassassin took care of > that: if it successfully parsed the rule and produced the same results as > it did when running the original rules then the rule building code is OK > and I have a much easier way of maintaining these rules than I did > yesterday morning. > > (2) If the task will take a few days, such as writing a non-trivial Java > library class, say for parsing or writing CSV files, My design document > is often written as an overall description of the classes purpose, > functionality and processing options followed by API definitions and > associated textual descriptions of their intended use. When I'm happy > that the requirement is complete and doable I can turn it into a class > file by making text into comments and APIs into method interfaces, add a > few curly brackets and return statements and have something that is > immediately compilable. Then I can generate javadocs to see if they are > readable and tweak the text to suit. After that I can write a test > harness, test scripts and add code into the skeleton. Just as Lew > probably does, I'll often do these three in parallel but with carefully > compartmentalised thought processes: its *much* better to write the test > script(s) and add the call to the test harness before actually coding the > content of any particular method. Additionally, you can start regression > testing long before the coding is complete. > my strategy is vaguely similar, except it usually involves maybe spec'ing out the interface, and then for the actual implementation going and finding a lot of pre-existing code which can be used as templates to build the new machinery (copy/paste/edit magic, ...). yeah, getting tests working early seems to be a fairly good strategy. often, if there is no good way to test or use a piece of code, well then this is a bit of an issue... |