Katascope Studio

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 UnitTests and the first iteration
• Create some AcceptanceTests

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
• 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.

• 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