2014 new year tech resolutions

it’s that time of the year again to contemplate, appreciate how much we have come and look forward with excitement and anticipation to what is ahead. our team is growing and so the challenge. i am learning to appreciate the intricacies of managing a diverse tech team and providing a solution that is both granular and all encompassing simultaneously. it may sound like an oxymoron though i’m sure this statement holds ground for most HIT startups involved in care coordination and the BPCI program. the truth is that when dealing with standards, data feeds should be synthesized and clean. yes, being compliant with MU1 should mean just that, but the fact of the matter is that it does not. it’s easy to point a finger at the hospitals but that is just not fair. the same is true for browsers who implement web standards. if you are involved in web development you will have to optimize and tweak your code per offering. it’s just how it is. this is where i hope that one day the state HIEs will step up to provide a more robust infrastructure that is both available and clean. the winner will be the one who will have critical mass and will do somewhat of a good job. a good job may mean a decent and somewhat relevant snapshot of the patient. and then some. HIEs can and should be smarted than their users soon. that alone will justify their existence rather than aggregators. it will be  interesting to see how  shiny pans out.

so new year tech resolutions:

1. make the switch from SVN to GIT and implement gitflow. this will allow us to get releasing more quickly.
2. BDD is not just a cool term. it’s how we will ensure quality and scale.
3. quicker more rapid and agile releases. move as close as possible to continuous integration.
4. tailor a winning hybrid schema between document storage and relational. find the balance between the two.

why we have switches to git from svn

the debate within the team has been going on for a while… should we stay with svn or should we move to turvald’s git? should we stay centralized or is it time to decentralize our version control system?

on the personal level git will allow move a bit faster with a full local history for every developer and the benefit of quickly switching between branches. as a team we saw the flexible workflows was can work with under git and really take advantage of branches as frequently as we checkout an issue on jira. though the top of the pile was the lack of merge hassle. almost every developer on the team has some fear associated with merging their code and the longer they have been working on their branch – the bigger the elephant in the room grew.

1. create a read only copy of our repository
2. pull all the changes from subversion
3. migrate our toolset away from svn to git (CI, code reviews etc)
4. make the switch

re-educating the development team is one of those harder tasks. ideally there are a few git champions within the team that can infect the rest with their passion for the switch. take under account that no matter what you do, some will resist and it will take a few months before everyone is aligned and appreciative of the change.