07.20.2011 Developer Meeting

Weekly Developer Meeting - 07.20.2011
On the Call:
Keith Woodlock - Ireland
Krishnan - India
Ed - Seattle, USA
Kojo - Ghana
Udai - India
Adam Monsen - Fargo, USA (via IRC/typewith.me only)
Discussion Topic: End Objective of Potential Mifos X

Exceed the current level of functionality of Mifos

Current architecture of Mifos make it too difficult to build new features

Some features could be added to existing codebase.

Effort/investment to continue with refactoring outweighs rewrite (too much technical debt)

Too difficult for people to get on code base and deliver value.

Medium-Long term play

Krishnan: should we add these features into Mifos today or in Mifos X?
Krishnan: thinks it will be difficult to bring current customers over to Mifos X - need migration tool.
Krishnan: what is current progress?

Van: Spring/Roo

Keith W: Spring-based app & Java

Mid-August: demo of loans/clients functionality on new version.

Difficulties with Current Codebase:

KeithW: everything is pretty much wrong from architecture perspective with current Mifos.

Learnings we're starting with:

Krishnan: What are some of these difficult features that are mising?

KeithW: Meeting dependencies, flexibility of loans/scheduling

Better integration amongst savings/loans

Meet more needs of SACCOs, SHGs

Krishnan's missing gaps (Mifos must do better)

Reporting:

Better integrated support for reporting - shouldn't have to use separate tool to do fairly flexible reporting. Reporting is what MIS ultimately means to end users

Be able to create reports without different tools, architecture, framework, separate set of tools.

Udai: what tool in mind? How do you solve problem without using separate tool?

APIs

Can't create flexible and functional API with current codebase (lot of effort not useful over long period of time)

KeithW: good amount of work getting service facades across Mifos but proper APIs still require a lot of effort.

Accounting

Don't have any accounting functionality in Mifos so anything we add would be a bonus.

KeithW: not looking at it straight away.

Krishnan: early idea - accounting can stay independent of MIS/transaction handling capability - stand alone application to take care of most accounting requirements which has interface that is flexible enough for Mifos or other product to communicate with (use message queuing, batch communications, different kind of things)

Build accounting engine which resides and runs indepenently and be integrated with mifos to serve its needs.

Changes be made to accounting while Mifos has a fairly stable interface to it.

Develop a standard accounting interface for microfinance.

KeithW: should accounting pull infor or MIS push information accounting app.

Udai: Lots of code will be lost if do complete rewrite - will you be integrated code from existing modules?

KeithW: whereever we can reuse we will.

Udai: in Mifos itself, we've completely replaced code (i.e. remove Struts) and breaks other functionality.

Why not just rip out bad code from current Mifos rather than restart from scratch?

KeithW: mifos over-engineered at every level (400 independent acceptance tests)

rewrite: not a technical exercise with rewrite - focus on getting product right.

Krishnan:

Code that models domain, entities, etc.

Code that looks at how loans, interest, payments scheduled.

Modules that we can take from existing Mifos:

KeithW: little beyond question groups.

Krishnan: other volunteers can work on different aspects

Flexibility around loans:

Someone who thinks about loans module should be designed has smaller challenge than thinking about how entire architecture should look and work. Reasonably self-sufficient things that can be dropped in new product architecture.

Tons more flexibility with loans required with way microfinance has been shifting/evolving (especially in India)

Using Git:

Release faster and frequently, allow customers more flexibility in working with code through git.

Do current customers (like GK) have their own git branches?

KeithW: we have release branches and master branch but no customer-specific branches.

Use git to respond to customer needs much faster.

Krishnan: can have certain git branch for new features.

Udai: can use branch by concept/feature - can directly cut a branch with feature using a feature toggle.

Krishnan: branch per customer. Udai: fear that diverge too far from master, risk of not merging back into main branch.

More stable branches for customer - not having to have bleeding edge code from master.

can try features in much easier manner.

What Language will be will be build in?

Spring/Roo is pretty close to Grails in terms of philosophy.

Krishnan: not too confident in Groovy - not stable enough to build entire software in.

Big Bang vs. Creeping Approach

KeithW: been doing incremental, building on top but can't behind design flaws at the core. Too long to fix everything which is needed.

Reporting Architecture:

How do we achieve this flexible reporting without separate tool?

Programming, UI-based?

Krishnan: For MostFit, ORMapper - easy to create relatively complicated short amount of time - focused more on what you want out of report rather than code to get report.

Focus on Functional Logic: 90% of code to generate new report - queries to find out about loans, status. Not too much time for SQL.

Udai: similar to a DSL for reports? --> Krishnan: use models (ruby's eqivalent for java class)