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:
- 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.
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
Katascope Studio