Development Life

WE’RE BIG BELIEVERS IN AGILE — ALTHOUGH NOT DOGMATICALLY.

Over the years, we’ve adapted the best parts of agile that work for us and left the rest.  We now run two fla­vors of agile – Scrum and Kan­ban. Teams pick the option that best suits their needs, but across teams we believe that all projects – no mat­ter how big – can be bro­ken down into small pieces and worked on iter­a­tively. Our tick­et­ing sys­tem (JIRA and its Agile exten­sion) keeps us hon­est about scope changes and ensures there is com­plete vis­i­bil­ity into the pro­gress of each work item. We hate rot­ting code (code that is stuck in the process rather than in pro­duc­tion in front of users) so we gen­er­ally deploy soon after code has run through our auto­mated test suite and has been user-tested.

MAKER’S SCHEDULE

Since we know engi­neers need to work on a Maker’s Sched­ule, not a Manager’s Sched­ule, we’ve done sev­eral things to ensure the sanc­tity of cod­ing time, includ­ing opti­miz­ing the office lay­out, min­i­miz­ing meet­ings, and des­ig­nat­ing an “on call” engi­neer to pre­vent unnec­es­sary inter­rup­tions.

PEER CODE REVIEW

We invest in code from the begin­ning. 100% of code goes through a peer code review process.

INTEGRATED TESTING

Tests shouldn’t be a sep­a­rate ticket or process — it’s a step in the core ticket. Since we han­dle med­ical and pay­ments data, our code needs to be right — every sin­gle time. We have an exten­sive suite of unit tests (PHPunit), inte­gra­tion tests, and front-end tests (Sele­nium). Yet, we keep the process agile. We’re not strictly Test Dri­ven, nor do we think 100% code cov­er­age is the right strat­egy – it’s about being smart and bal­anced.

CONTINUOUS IMPROVEMENT

Once a week we join together for a Ret­ro­spec­tive Meet­ing. It’s pur­pose is to talk about what can be improved about our devel­op­ment process itself. It’s how we limit the bureau­cracy and keep work mov­ing through the sys­tem smoothly. You’ll have a voice, every week.

VARIED WORK

Our work bal­ance is split pretty evenly between major pro­duct enhance­ments, brand new mod­ules, and implementation/support/maintenance. One day you’ll be build­ing IVR tele­phony appli­ca­tions and the next, a high-avail­abil­ity, robust trans­ac­tion engine. We’re solv­ing new chal­lenges every day to make our pro­duct bet­ter for our cus­tomers.

We’re a largely PHP and MySQL shop — includ­ing our back­end sys­tems. By writ­ing all of our core soft­ware in PHP, all devel­op­ers can work on any sys­tem com­po­nent and be cross-trained. Our code is clean and object-ori­ented, built around the Colony MVC Frame­work. While we gen­er­ally prefer open source soft­ware, we invest in com­mer­cial tools when it makes sense.

Our work­flow is built around the Atlas­sian Suite, using JIRA for tick­et­ing, JIRA Agile for plan­ning, Con­flu­ence for doc­u­men­ta­tion, and Stash for code reviews and build man­age­ment.