Part 3 of The Developer Insight Series: The Process of Writing Code by Janice J. Heiss considers (in her own words), developers reflecting "...on the actual process of writing code, how it happens, what it feels like, and how they do it."

• The 13 veteran developers Heiss interviewed offer such insights as "It's almost mystical...." (Adam Bien), adding that one must first understand the domain and the problem at hand.

• Kohusuke Kawaguchi does what sounds a lot like doodling, then attempting to derive an outline from his scribbles and notes, and then revising again and again until the problem is solved.

• Chet Haase employs what he calls the prototyping approach, which involves writing "ugly hacky code" just to get things started. Once it appears that whatever approach he has settled on will in fact work, Haase begins to refine the code, beginning with dumping whatever ugly hacky code he wrote to begin with.

• Arun Gupta relies heavily on the Unified Modeling Language (UML) tool and/or annotations in the Javadoc format, which he uses to derive class and sequence diagrams from an initial outline of the project's requirements. He then proceeds to write interfaces and implementing them, being careful to keep the interfaces separate from the implementation in order to keep the code, as he says, "modular and pluggable."

• Kelly O'Hair describes a very orderly process beginning with starting NetBeans, creating tests and templates, filling in the templates, debugging code, running tests, debugging code, and so forth, until he is satisfied with the results.

• John Marinacci likens writing code to sculpting or painting, by which he means beginning with a sketch of the final result, whether it be a feature list or an actual physical paper-and-pencil sketch. He then uses Matisse in the NetBeans IDE, which puts him in a place to implement features and fix bugs. A cardinal principle for Marinacci is "iterative development," (reproducing a bug, developing a fix, and refining the fix to address compatibility issues.

• Masood Mortazavi sums things up nicely: "From a formal standpoint, it's easy to describe: Requirements, design, implementation. From an informal standpoint, it's more subtle: interpretation, conception and imagination, creative meeting of constraints."

• What works for Shannon Hickey is a kind of action painting approach that involves "throwing together methods and prototype" until he is satisfied with the outlines of the proof of concepts that emerges on the screen. Next comes the issue of properly designing the API, he notes, keeping in mind that others will be using this code, not he alone. Especially with larger projects, Hickey says he takes a modular approach, writing small pieces that he then builds on top of.

• Richard Gabriel (Ph.D. in computer science, MFA in creative writing, poetry) practices what he preaches with his advice to train developers as you would poets and artists. "Writing software should be treated as a creative activity." He suggests studying acknowledged masterpieces of software source code and then working in something akin to an apprenticeship model under the guidance of a master developer while also submitting your code to the scrutiny of peers. A code-writing workshop, in effect.

• Tor Norbye likes to develop a "skeleton" of the project first and then fill in the gaps as he tests the code manually by executing code along the way, then writing unit tests. With those tests behind him, Norbye tackles corner cases and unit tests them as well. As he puts it, "my approach is to code the functionality first, then test later, and then to turn the process around and write tests for cases I don't expect to pass yet, and use the tests to complete the code." He adds that having iTunes playing in the background is a big help. And he notes that debugging is just as important as writing the code in the first place.

• Romain Guy takes the prototyping approach and then teasing the prototype into the actual code by refactoring it. He suggests carefully examining the code already written before tossing it all out, which is usually implicit in the prototyping approach.

• Eamonn McManus also leans toward the mystical, which calls for mastery of the developer's tools and then letting things "flow," an admittedly difficult state to attain.

• Finally, Alan Williamson expresses a fondness for the whiteboard and drawing boxes. He uses boilerplate, laying out classes and method calls and worries about the details of those methods later. UML, he finds, gets in the way of his approach.

Each of these developers expands on the above summary of his remarks through links in Heiss's article.

Parts 1 and 2 of this article series by Heiss have the concerned practiced developers offering their advice on writing good code.

More Information

Java Course Catalog

Java Tutorials

Student Developers [...read more...]

		fullsource
Print Email Current Profile Archive Blog Generate newsletter