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