KatascopeStudio

Last edit August 12, 2006
Software Features Development Features: API Layers: Working:
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: User Stories/Requirements: 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
  • UnitTests : Almost every kind of automated test ends up useful. I use UnitTests 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.
  • AcceptanceTests : 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. 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: Public Software:
LayneThomas