No Programmer Is an Island

Ongoing communication creates an atmosphere encouraging the best possible software outcomes.

Today we were in a design meeting for Phase Two of the new buydown feature we’re implementing in our flagship software package, the Computerized Daily Book (CDB). The gathering was an extension of the daily scrum process we run for most of our products. We were there personally because, hey, our department writes end user technical documentation and it’s always a good idea to know what a feature does before you try to describe it to someone else.

Every time we attend a meeting like this for an enhancement, the experience reinforces what we often take for granted: the number of details that must be shaped and integrated to make the new feature work and play nicely with the existing parts of the software.

These meetings definitely help; we dare say they’re indispensible. As a matter of fact, our approach to meetings at SSCS has evolved rapidly over the last six months or so, encouraging the daily rhythms of communication like those we described in this blog post from a few months ago. Those rhythms have a beneficial impact on our development focus and effectiveness, and really promote consistency in understanding the tasks to be done as developers, QA, and management go back and forth with each other regarding the details.

The process is especially important when you’re implementing a feature that applies—through technology—accuracy and speed to the daily work processes required for buydowns, those incentives extended to retailers for a finite period of time by (mostly) tobacco vendors. In this scenario, a set of existing inventory items are placed on sale (often cigarettes), with the price reduction getting passed through from the vendor to the retailer to the consumer. The vendor makes the incentive offer to the operator in return for promotional considerations such as special signage and displays, and when the promotional period ends, the supplier reimburses the retailer the difference between the original inventory price and the reduced buydown price.

That may seem simple in concept, but for the development team it means opening up the hood and performing delicate work among a host of moving parts, most of which the user never sees. This is usually the case when the focus of work is the enhancement of money flow management, of which buydowns are a part. Like the veins and arteries that transfer blood to and from every part of the human body, cash flow runs through almost every aspect of gas station/convenience store daily work and the technology built to parallel and improve it. Because cash flow “touches everything,” isolating problems in this stream once the code is in place and running can be an incredible headache. Being proactive in approach is a much better option…

…which brings us back to the daily scrum. No developer is an island, especially when it comes to programming the financial modules of a large, full featured back office system like the CDB. Our meetings help provide a structure that gives the team the best possible chance to ensure nothing is overlooked. Daily, short, efficient meetings allow us to hash out solutions, remind each other of what we may have overlooked or missed, and keep the momentum up as we create code that calculates accurate values, stays true to the end result for which the customer is really looking and is delivered in a way that the user will understand, appreciate, and use. As an approach it’s hard to beat and we’re getting better at it every day.

By the way, in case you’re wondering about our buydown feature, it’s being released in several phases. Phase One, available now in CDB release 7.5.2, adds the ability to set up, process, and report on buydowns owed, as well as sending the new list prices up to the register. We’ll keep you posted as development moves forward and we approach the release of CDB 7.5.3.