[Javacavemaps-developers] timeout, lets huddle in the locker room so the coach can give a pep talk..

[Larry G. <jav...@ya...>]

XP methodology has a very good concept where the project's growth of source code and complexity is controlled. This control process is called the iteration.  It is also controlled via the adjustments to [time][resources][quality][scope/scale].  So if the controls are set correctly then a situation occurs where the project moves along at a steady rate.  Compare this to the solo cowboy coder. He wants a task, not time goals, no scope or scale, no help[additional resources], and by all means his code is perfect no need to question quality.  Fun Fun.  

I have a few analogies for you.  A group of 8 guys get together to play basketball from the neighborhood.  4 are skins, 4 are shirts. They are having fun working as teams killing time, no need for pay. In our case the skins are the developers and the shirts are the end users.  

Another analogy to how this thing should work would be the Mounted Horse Cavalry.  One guy leads the movement and pace, calls cadences, and the group move along together towards each milestones in their journey. One guy calls the charge, retreat, dismount, mount, etc. Their pace always remains the same.  The milestones in our case are, iteration, minor releases, milestone releases.

Another analogy for the uncontrolled fun non team work cowboy coder technique. On farms they have a weed killer called 2-4D. This thing kills weeds by actually fertilizing them so that they grow so fast they can't get enough water and nutrients and die. (Purely trivial info, this is a broad leaf killer, it will kill grape vineyards withing 1000's of feet of a corn field.)  Anyway, this is what uncontrolled grown to source code and projects can lead too. Project death. Unmanageable, crap that's only good in the eyes of the cowboy coder and not all that great for the end users.

So now lets talk about scale and scope. Same thing just different analogies.   Scale would be like map scale and scope would be like Telescope, Binoculars, Zoom lenses etc. And one more thing I call Granularity, which is a similar concept.  These principals can be applied to any part of the project, any branch, any feature, any module and to the project as a whole.  What this is really talking about is planning and tasking.  In XP this is called story cards and task cards.  We can make up many story and task cards but you only select the ones that can be completed in the next iteration for that iteration. In our case again we are talking about the feature request, bug fix request, specifications and task management.

Lets say a task is assigned to an individual and his situation changes, this means that resource is eliminated or reduced. In this case the task must be scaled down for that individual or assigned to someone else. It may have to be split into multiple task so that the scale of each task is therefore reduced, then it can be assigned to different developers.  Let me give you an example of scale.  

Small. Task: Write a class that can read and write to a text file.
Slightly larger. Task: Write a class that can read and write a pipe delimited text file.
Even Larger. Task: Write a few Classes that can read and write 3 kinds of text files. Fixed width,  Pipe delimited and simple "","", CSV style. This is tabular and data is to be expected in tabular form when read.
Super Large scale. Task:Write me an API that can handle almost every common case of text file parsing.
Extra Super Large: Eh, you know what to do, we need file IO here Lots of it, go for it, get some work done.

Granularity.  Fine grained and Course grained. Example in this case a Pixel editor.  

Course grained. We write one class, that uses the standard Java2D API to allow us to edit a simple GIF and save it using a single standard color pallet. This thing only edits small icon images.

Medium grained. We write a few helper classes to assist with the various parts of the view. A Menu class. An Editor Panel Class and a Color Selection Panel Class.

Fine grained. We write a core section with many classes and some packages. We add on extra component sections to assist in say some common special effects. The components have many classes and package each.

Extra Fine grained. We write a class for everything. A pixel even gets its own class. 

Get the picture? The finer grained solutions have cost and trade offs. So do larger scale or scope solutions. Some adjustment to scope or scale can be made based on the developer himself and his mileage with this API or that API, this technique or that technique. But the fact remains until coding is being done, no adjust to up scope or scale or granularity can be made. Also granularity has more consequences because of its burden on the computer system. Adjustments to granularity must be carefully thought out on the developer or architect level.

Another example of this is that we  have programmer type or size task, developer type or size task and archtect type or size task. 

Programmer task: Hacking code logic in a method. Write local documentation. Writing test cases.

Developer task: Writing Javadocs and Class or Interface Definitions. Perform refactoring task. Deciding scale or scope of small task within the project.

Architech task: Deciding what paterns to use as well as other major design decisions, such as what package name scheme to use, what coding style standards to go by, and what class naming scheme would be used. Major refactoring issues as well. Deciding overall scale and scope and granularity.

Now have I totally confused you guys and scared you off by now? Don't worry, it's as serious as a neighborhood basket ball game. So get the shirts off. Lets sweat a little. And enjoy a sunny day.

P.S. Don't judge my programming abilities by the source thats on this project at the moment. Things will impove and become more interesting over time. 

Thanks, and everything is apreciated though nothing is truely expected.






 Larry Gray
la...@ar...