Today was a big day for the mobile team at Íslandsbanki as we launched our new Android banking application after 10 months of continous work, combining functionality from two of the banks previously developed mobile applications, a personal finance management application (ÍSB) and a premium card management application (Kort). In due time these two will be sunset.
By having used the fantastic tool Wakatime (which I higly recommend checking out) to track my coding activity over the years, I can share some statistics about my involvement in the project.
My overall active development time during these 10 months counted up towards ~1087 hours, split between the following languages:
- Kotlin development: ~ 752 hours
- Java development: ~ 122 hours
- XML: ~ 159 hours
- Groovy: ~ 23 hours
- JSON: ~ 16 hours
- All the rest: ~ 15 hours
My longest active development day was May 9th 2019, with a whooping 12 hours and 14 minutes on record!
As a side note; these kinds of work hours are not healthy nor sustainable for any amount of time. Make sure you are not burning out if your days look like this. I would recommend checking out BurnoutIndex.org regularly as a way of keeping an eye on the stress levels.
As the stats show, the opportunity was taken to write all new code for this new application entirely in Kotlin, which has been a fantastic experience to use since day one. The natively built-in immutability of the language alone probably saved us weeks of headaches, to say nothing about all the other nice things that Kotlin brings.
Overall there are 293 Kotlin files (.kt) in the final product, accounting for just over 20k active source code lines, with the Java portion of the project counting some 187 files with 11k active source code lines. This is just a small random nugget of information as LOC really doesn’t indicate anything, good nor bad.
As each feature of the application was developed in a separate branch out of the mainline before being merged back in, Wakatime is also able to give a rough estimate on how long each feature took to develop. So in the top three spots sit:
- Transfer functionality: ~ 168 hours
- Card management functionality: ~ 104 hours
- A new authentication flow: ~ 103 hours
The architecture pattern that was chosen was Google’s own recommendation, the proven ‘Repository Pattern’, giving a clear distinction between the logical layer and the UI layer, and doing so at the package level. Entities such as cards, accounts and loans all had their logical layers implemented as seperate packages, where in the use of Dagger was heavily used in the modular construction of repository entities exposing functionality for each of these entitiy types.
The UI layer was then implemented on a separate ui package level, cointaining each user flow as a separate package within it (such as /ui/cards and /ui/transfers for example). ViewModels, injected with entity repositories as required, then expose observable data sources that are then databound into the user interface.
In the end this pattern helped us make adjustments on the fly deep within each layer as was needed, usually without it requiring any further work further down the pipe. As can be seen by the histogram above, by using clear logical separation between functionality as well as keeping external dependencies at a minimum, changes can be made without it having too much impact further down the line.
Though this is launch day, the team has numerous features planned in the coming months as well as a more iterative delivery plan where new features can be delivered and verified with much quicker with real users.
2020 is going to be a interesting year!