• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

What tasks are part of "coding?"

 
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
HS Thomas
Ranch Hand
Posts: 3404
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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."
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
- coding standards
- version/configuration management
- integration
 
Mark Herschberg
Author
Posts: 6055
8
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What do you consider to fall under configuration/version management?
--Mark
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
     
    author
    Posts: 11962
    5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Including stuff about configuration management is a good idea, I think. There aren't enough books on practical configuration management.
     
    Mark Herschberg
    Author
    Posts: 6055
    8
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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?
     
    Lasse Koskela
    author
    Posts: 11962
    5
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    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.
     
    Mark Herschberg
    Author
    Posts: 6055
    8
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    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
     
    Ilja Preuss
    author
    Posts: 14112
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    This one looks promising: http://www.amazon.com/exec/obidos/tg/detail/-/0201741172/
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic