/
Cheetah Release Design Goals

Cheetah Release Design Goals

Sept 07, 2010

Design Goals for the Mifos Cheetah release

  • Simplicity

    • Strive to choose the simplest solution that will solve the problem while retaining the maintainability and quality of the code base. (Note that "simplest" does not necessarily mean "easiest". For example, copy-paste-tweak reuse is often the quickest path to a solution, but adds complexity to the application, and heartburn to future maintainers...)

    • Make code as easy to understand as possible.

    • Acknowledge that in some cases the simplest workable solution to a complex problem may itself be complex. The main idea is that when complexity is introduced, we need to be able to justify why it is a better solution than a simpler alternative.

    • Make it easy to do the right thing and hard to do the wrong thing.

  • Testability

    • Strive to do test driven development (TDD). Write tests first and then implement functionality to make tests pass.

    • Write POJO (Plain old Java object) based code that can be unit tested independent of a database.

    • Each unit test should execute independently of others.

    • The entire unit test suite should execute in less than 10 minutes on "reasonable" hardware.

    • Build the web user interface so that Selenium tests don't break if the text or structure of the HTML changes (use id tags with namespaces for components).

  • Modularity

    • Code should be divided into cleanly separated modules with minimum dependencies between modules.

    • Make it easy to rewrite portions of Mifos and add new functionality in a way that impacts code outside a module as little as possible.

    • Modules should be specified as much as possible in terms of interfaces. This will allow for easy reimplementation and testing.

    • Pluggability - there should be a way to extend Mifos functionality by adding external code modules without having to recompile Mifos code.

  • Quality

    • Coding standards

      • Agree on coding standards and use pair programming, code review, and automated tools like PMD to help stick to standards.

      • Treat tests as first-level code, refactoring and modularizing as necessary.

      • Ensure valid HTML/XHTML markup

    • Acceptance tests

      • Have an easy-to-run suite of acceptance tests, using tools like Selenium and Selenium-RC. Run the tests from a continuous build system.

      • Add acceptance tests to the suite for every feature implemented or every bug that is fixed.

      • Modularize the acceptance tests to have a smoke test that tests core functionality quickly, and a slower regression suite.

    • Test coverage

      • Measure code coverage of test cases to make sure untested code isn't slipping in.

    • Quality metrics

      • Implement an automated way to measure code quality over time, possibly integrating it with the normal build process.

      • PMD

      • Findbugs

      • Automated HTML/XHTML validation

    • Approachability

      • It should be easy for developers to contribute to the project

      • Write intention revealing code which can be easily understood

      • There should be sufficient well written documentation to understand how to modify and extend the code.

  • Scalability

    • Design and code with the idea that the system should support large user bases.

    • Consider a SaaS environment and the need to support, administer and upgrade a large deployment.

  • Performance

    • Stress testing - Mifos should perform well under heavy user loads

    • Performance testing - we should be able to quantify performance so that we can measure changes in it over time.

  • Stability

    • Mifos should not crash

    • Longevity - Mifos should be able to run for extended periods of time without the need to restart.

    • Design with the goal of linear scalability across server farms

  • Usability

    • The initial 2.0 release will retain the current UI for the most part. From this starting point we will strive to understand how best to evolve the UI to make Mifos as intuitive and easy to use as possible.

    • Documentation - provide easy to understand documentation that makes Mifos easy to use.

  • Speed of delivery

    • Approach development such that functionality can be delivered within the time defined by the needs of business

    • Deliver frequent iterative intermediate releases

  • Security

    • Information in Mifos must be well protected

  • Ease of Administration

    • Monitorability

      • System should include hooks required by external monitoring tools.

      • Business activity monitoring – what are users doing in the system? What features are most heavily used? Rarely used?

    • Ability to easily identify the cause of problems