What tasks are part of "coding?"

What things do you do during the coding phase of development. Assume a waterfall like model, roughly, or at least, not an XP one where everything is intermixed.
For example, you won't be gathering requirements during this stage (although you may be reviewing/modifying them). You may be doing code reviews.
--Mark

Well, I think to some extent, the tasks are always intermixed. When coding you need to
- analyze requirement details - it's near to impossible to state requirements in a way that at coding time no more interpretation is necessary.
- design the system - if you accept that deciding about moving a specific behaviour into a utility method (or even naming of variables) is part of design
- test the code - you need to do this at least manually, unless you really don't care about wether it works.

In addition to Illja's points, are those in a Process Pattern Programming paper that I stumbled across yesterday.

4. Stage Process Pattern � Program
An important aspect of software development, one of many to be exact, is the actual development of the source code. As experienced developers know, there is far more to programming than just sitting down at a computer and typing in source code. The Program stage process pattern describes the iterative tasks/activities of programming.
4.1 Forces
Programmers need to develop software that meets the needs of their user communities, needs that have been reflected in the form of models and documents developed during the Model stage and the Define and Validate Initial Requirements stage (Ambler, 1998b). The developed source code should reflect the information contained in these deliverables, yet at the same time may drive changes to them as programmers gain a detailed understanding of the domain (usually more detailed than the modelers have).
Furthermore, most organizations want software to be developed in a timely and efficient manner but at the same time want it to be maintainable and extensible so that changes in the future may be made efficiently and quickly.
4.2 Initial Context/Entry Conditions
Several conditions must be met before coding may begin. First, your design models should be in place for the code that you intend to write. Second, your project infrastructure should be in place, defined during the Define Infrastructure stage of the Initiate phase (see Figure 4). The infrastructure includes the development and supporting tools that your programmers will use as well as the standards and guidelines
that they will follow. Third, programmers must be available to do the work.
4.3 Solution
4.4 Resulting Context/Exit Conditions

Please see the rest at Process Patterns. This paper is by Scott Ambler in his pre XP days I think.
regards
[ August 01, 2003: Message edited by: HS Thomas ]

Why do you ask , Mark ?
Are you trying to re-jig the tasks around , ie. redefine the work involved ?
Shouldn't this be to large extent self-directed ? At least , that's the way it should be approached.
The best architectures, requirements and designs emerge from self-organising teams.
A Principle of the Agile Manifesto.
Of course ,this should be viewed along with the other Principles which can be seen here :
[ August 02, 2003: Message edited by: HS Thomas ]The Agile Manifesto
regards
[ August 03, 2003: Message edited by: HS Thomas ]

I found it fascinating when I went from "no process" to "RUP as taught by Rational" coding went from the main activity in software development to something relatively low-skilled folks did for a very small part of the project life cycle. Coders went from valued techies with an important role throughout the project to interchangable typing units to get past that nuisance coding step. Sigh. Of course that didn't work the best. The agile movement is an appropriate backlash to such thinking.
Activities during coding are whatever you say they are. Various teams do modeling, design, code reviews, knowledge sharing, unit tests in this phase, outside it, not at all, or don't even identify a "coding phase."

My ISP sucks! I didn't get notified of these replies.
In answer to your question HS, it's because I'm still a little stuck on chapter 6 of my book. Chaoter is on "coding" but I do not want to put any code in the book. I'm trying to think about other things I can talk about.
Things I cannot talk about (because they are in other chapters): requriements, business setting, QA, documentation, release, support, project management related issues (scheduling).
Thing I'm thinking of include: tools, code reviews, and build process. But this feels weak. I'm also thinking of covering issues like "the true cost of coding is in maintaining, not developing code." Still, I'd like to get other ideas.
--Mark

- coding standards
- version/configuration management
- integration

What do you consider to fall under configuration/version management?
--Mark

What do you consider to fall under configuration/version management?
I'd include things like

how to associate tasks/changes/work-packages with files (or other units of code) and with developers/teams

how to recognize and resolve change conflicts during development

what to "book in" and what to leave out

lines of code and branching/merging strategies

applying and managing changes to multiple versions and/or multiple delivered configurations

spotting "bottle-neck" files which often need to change for unrelated features (and what to do about them)

using VCS tools to log changes, compare versions, and associate the appearance of a fault with a particular change

how and when to "roll back" a change, and how to ensure that the whole system is still in a considtent state after the rollback

ways in which using a version control system can make coding easier and/or harder, practical benefits and drawbacks to the programmer

ways in which IDEs and other tools can help make using version control simpler

choosing between small, independent, project-specific, repositories and large enterprise-wide ones

I reckon all of these are firmly in the area of "coding", and don't seem to naturally fit with any of your other headings. Is that the kind of thing you were looking for?

Including stuff about configuration management is a good idea, I think. There aren't enough books on practical configuration management.

Yes, that helps. Thanks! (Although more suggestions are also welcome)
I included about half that sutff under "build process." I think configuration management is the better term. You also listed topics I didn't consider.
Lasse, I agree, there should be books like that. (Long ago I was tempted to write one.) My book, however, won't get into too much detail, since it's more of a concept book. You should also post that comment here.
So any other topic ideas?
--Mark

Originally posted by Lasse Koskela:
There aren't enough books on practical configuration management.

In which way(s) aren't the books amazon finds for "configuration management" practical?

In which way(s) aren't the books amazon finds for "configuration management" practical?

There are plenty of books explaining the theory of versions, revisions, branching, and so on but these books tend to stay on the "nice pictures" level. That's not bad, it's just not the full picture. Similarly, the existing books for particular tools are too task-focused (how to checkout a file).
What I would like to see come out would be step-by-step and out-of-the-box type of setups for particular CM tools and particular software processes (mainly agile versus not-so-agile). Agile Configuration Management Using CVS would be a candidate best seller, I think. I would buy it.

Well, I don't really want to further hijack my own thread, but another good book would be tips, tricks, and strategies.
For example, I create Java programs with version numbers. It's surprisingly difficult. You can't put it in a prop file, since that can be overwritten (I suppose you could if you hashed the file in-house). Instead you embed it in the code. I could do it by hand, but I might forget. Plus the version number appears in many places: about dialog, readme file, installer, documents, etc. I would use some type of pre-compiler (usually a perl script) to update all files before they got packaged up together and released. I only know to do this because I learned it from someone else.
--Mark

This one looks promising: http://www.amazon.com/exec/obidos/tg/detail/-/0201741172/