'''Software Features'''
	* LoneDeveloperProjectManagement
	* Sequenceable SceneGraph using TheInterfaceIsTheUserData pattern with a SymbolicUserInterface.
	* ProgressiveDisclosure SelfDocumentingUserInterface with links to additional DoxyGen generated AppropriateTechnicalDocumentation and UserDocumentation.
	* Two skins: SkinnedIconsWithText and PurelySymbolicIcons - Solves TheProblemWithIcons

'''Development Features:'''
	* Pure CeePlusPlus
	* Strong ConceptualIntegrity
	* CriticalMassModel design.
	* EmbeddedTests
	* Set of C++ projects in MicrosoftVisualStudio.
	* AutomatedConfigurationManagementEnvironment handles tickets,builds,backups,revisioning,documentation,artwork, and testing because AutomationIsOurFriend

'''API Layers:'''
	* Glyph - Values, Functions, and compiler for the SymbolicUserInterface
	* Component - General functions and classes.
	* Resource Layer - HierarchicalModel of Resources similar to NakedObjects. Resources have a SelfDocumentingUserInterface.
	* Kernel - The PublishedInterface

'''Working:'''
	* DefensiveProgramming or StrongErrorHandling
	* SelfDocumentingCode
----
I thought about a new project - To log the entire experience of writing a real program using the ExtremeProgrammingCorePractices. Since it is a LoneDeveloper project, I might call it "ExtremeProgramming for the LoneDeveloper"

The timeline is:
* ReleasePlanning - Gather UserStories and design the SystemMetaphor
* Create the host environment
* Create some UnitTest''''''s and the first iteration
* Create some AcceptanceTest''''''s

User Stories/Requirements:
* Flaws in KatascopeStudioBeta
* Runs on Windows or WinCE

Developer Requirements:
* All project information is contained on a USB keydrive
  * Code & Projects
  * Documentation and notes
  * Artwork
  * IssueBase
* Certain open-source tools are used
    * CVS
    * Freemind
    * Context
    * Perl
    * EddiesWiki
    * CppUnit
    * DoxyGen
* Test, Logging & Error framework: Keep TestInventory and Hierarchy Descending Tests
* Standardized meta-language for comments (DoxyGen/CppUnit/lint/etc.)

So here's how I plan to apply the 12 XpTudes
#  Fine scale feedback
    * TestDrivenDevelopment - Strong testing, and TestFirst development
    * PlanningGame - Per flow chart
    * WholeTeam - Countered by LoneDeveloper
    * PairProgramming  - Countered by LoneDeveloper
# Continuous process rather than batch
    * ContinuousIntegration DailyBuild and AutomatedUnitTests through the AutomatedConfigurationManagementEnvironment
    * DesignImprovement/RefactorMercilessly - Applied per iteration
    * SmallReleases - Applied per iteration
# Shared understanding
    * SimpleDesign/OnceAndOnlyOnce - Per Refactoring cycle
    * SystemMetaphor - From the PlanningGame
    * CollectiveCodeOwnership - Via CVS, countered by LoneDeveloper
    * CodingStandard or CodingConventions - Will establish ahead of time
# Programmer welfare
    * SustainablePace (original name: FortyHourWeek) - Applied as 1 hour per day pace

Logbook of Xp practices I like:
* CollectiveCodeOwnership : It's so obvious now. . . 
* TestingFirst : Starting with a test case is so engrained I can't think of another good way to develop new software.
* IncrementalDevelopment : Fast enough to satisfy customers, slow enough to work.
* OnceAndOnlyOnce : See RandalsRule
* UnitTest''''''s : Almost every kind of automated test ends up useful. I use UnitTest''''''s for near-app level testing though.
* Continuous Integration : Our system stays in an integrated state, but daily builds are analyzed for anomalies.

Logbook of Xp practices I don't like or haven't used:
* PairProgramming : While I understand the potential productivity benefits, it comes at too high an energy cost.
* AcceptanceTest''''''s : These are usually customer specific, sometimes non-automatable, and more universal than Xp
* ProjectVelocity : I'll get back to this one later. . .

Planning:
* User stories are written.
* Release planning creates the schedule.
* Make frequent small releases.
* The Project Velocity is measured.
* The project is divided into iterations.
* Iteration planning starts each iteration.
* Move people around.
* A stand-up meeting starts each day.
* Fix XP when it breaks. 

Designing
* Simplicity.
* Choose a system metaphor.
* Use CRC cards for design sessions.
* Create spike solutions to reduce risk.
* No functionality is added early.
* Refactor whenever and wherever possible. 

Coding
* The customer is always available.
* Code must be written to agreed standards.
* Code the unit test first.
* All production code is pair programmed.
* Only one pair integrates code at a time.
* Integrate often.
* Use collective code ownership.
* Leave optimization till last.
* No overtime. 

Testing
* All code must have unit tests.
* All code must pass all unit tests before it can be released.
* When a bug is found tests are created.
* Acceptance tests are run often and the score
* is published. 

----
An optimal balanced meta-model - try and be somewhat universal in context-get a good enough model to be able to maintain.
* Written as what must exist for the model to achieve incarnation.
* Go for good enough, but not too good. Reuse everything possible.
* Developer: BeyondTheFormlessForm
* Methodology: Phase Effect Matrix
* IssueBase
* AutomatedConfigurationManagementEnvironment
* Design: AbstractionDevelopment & SystemMetaphor
* Documentation: High-level, not code specific - "The Evolvable Construct"
* Error handling: Unit, Local, and Public ErrorControl
* Gather inspiration from all of reality

'''Write code, documentation and documentation code, but never code documentation.'''
* No human should ever write a software developer's design document. Instead, write a problem solution document and map to it from your code and interfaces. The code itself should be clean and use as self-documenting code techniques. If code documentation is needed for an API, use a tool to generate the documentation from the code.

Local ErrorControl:
* '''Internal tests result in silence, log entry, or death'''
All tests follow this rule.
* '''Logging has a configurable language'''
Date/time
Module causing error/Source file/Line
Error ID & Human readable string
Extra data
* '''Assert is private or careful'''
Assert should be used liberally in debugging, but should not make it to release versions unless the assert logs instead of exists.
* '''Errors are properly directed'''
Errors should throw exceptions of a few types (severe, moderate, mundane) and have a filter that catches them and does the appropriate action - based on program preferences.
* '''The codebase and bugbase refer to each other'''

Unsorted:
* '''A not-for-release build is run daily before work, with error notifications'''
Whether by ConfigurationManagement or AutomatedScript - Know your codestate when you get into work
* '''A form of scripting exists in the software'''
Allows simulation of a user including a timed startup and shutdown.
* '''A form of reflection allows non-breakpoint debugging'''
Whether by Backdoor, network port, or script file - Allow diagnostic viewing of internal live data
* '''A chokepoint memory tracker handles all allocations and freeing'''
Replace all malloc/free/new/delete calls with a chokepoint and use it to detect memory leaks.
----
Visuals Research:
* Hypothesis: The next-generation visuals program can be intellectually manageable, and stored in a standard SQL database.
* Hypothesis: IntellectualManageability is the major design goal.
* Hypothesis: A SceneGraph can be represented with DecomposableObjects.
* Hypothesis: Every network is a hierarchy if both is-a, and has-a relationships are allowed - i.e. a LinkingHierarchy.
* Hypothesis: DecomposableObjects can be stored in a LinkingHierarchy.
* Hypothesis: A LinkingHierarchy can be stored in a RelationalDatabase.

Public Software:
* KatascopeStudio
* KataFx I,II,III - Descriptions coming
* MegaMinimal - Description coming
----
LayneThomas