by Jackie Cohen | Jul 1, 2016
As Local Orbit develops new processes and features, we focus on incremental change and continuous iteration. This means that we add new components into our processes and our application without disturbing anyone’s business, including our own. This way, we can use continuous small actions to effectively solve big problems. This happens throughout the company and the businesses we work with, but in this post, I’ll be focusing on how we implement this strategy in Local Orbit’s engineering work.
Earlier, I wrote about the process of developing a new feature on the Local Orbit engineering team. That’s a high-level view of the process. I’ll zoom in to show why it’s always important for us to take things one step at a time. Incremental change in the code itself, and the application structure, allows us to implement change gradually and thoughtfully, both for Local Orbit software developers and the users of the software we build.
In the process of developing a feature, our engineering team focuses on layering in new elements without disturbing existing business processes, and we add new small structures into the code regularly, such that we can iteratively build and test small pieces of new functionality.
For example, last year, we released brand new order and product pages, allowing customers to list multiple units for the same product. Within the code, this multi-unit functionality is supported by a bunch of complex structures and relationships, but by the time customers could see and use this feature, the engineering team had been layering in incremental pieces for some time.
We set up a data structure that could support either single-unit or multi-unit products, even though all products offered through our system at that time had only one unit each. Then we built each new piece of user interface (UI) in the application that was necessary for customers to use the multi-unit functionality — but did not make these UI additions available to anyone until they had undergone testing and iteration on their own. Finally, we completed the integration of the UI to add and edit products with multiple units, and we released the feature to customers with information about how it worked.
Testing among the team does not replace feedback from real users with a diverse set of priorities. However, our incremental, iterative development process allows us to stress-test major parts of new functionality without disrupting our users, or requiring them to learn new processes over and over. By the time we released multi-unit product functionality, we were well prepared to address user feedback that came our way, and the entire development team had an understanding of how the pieces fit together. We had each worked on a different part of integrating the new functionality into our existing system, or had assisted with testing and data architecture.
For the technical development team, this type of incremental, iterative development allows us to maintain steady progress on big features — efficiently meeting the evolving needs of our customers with a small development team. Our engineering strategy is consistent with the overall strategies of the company, and how Local Orbit works to help solve complex, multi-faceted supply chain problems. We’re more successful when we break problem solutions into incremental, well-organized steps.
by Jackie Cohen | Apr 8, 2016
by Jackie Cohen, Local Orbit Software Engineer
As a software engineer at Local Orbit, of course I write code – but that’s not all. I do larger scale product development tasks with the team as well as smaller tasks, including, data management for development of team and customer reports, and creating documentation for our databases and our software. I work with the rest of the development team to engineer the software that helps us move forward as a company.
When there’s something new I want to build, I consider: the why, the where, how fast, how well, and what. The following takes you through my process as an engineer at Local Orbit, developing new features in our application.
Why
When I begin work on a new feature, the first thing I consider is why we are building it. To start with, we use user stories in an issue tracker to understand why. For example, a story might be “A market manager should be able to edit the price for a single item in an order if the order has not yet been paid for,” with some comments included that explain details of why and how customers may want to do that. We’ll have succeeded with the feature when that is a true story.
Often, there are various behaviors desired by customers and/or by the rest of our product, support, and sales teams that a single new feature is intended to fulfill or ameliorate. To prevent breaking existing functionality for any of those people while adding something new, I have to understand these whys.
Where
Sometimes new features require adding a block of new functionality somewhere in our existing Ruby on Rails application, but sometimes they require changing a piece of an existing part of the app, or altering how data flows through the system. I need to figure out what part of the application I’ll be editing.
Our team’s process lends itself to conversations that lead to further discovery for development. These discussions help build bridges between features and ideas, and they are folded into our sprint planning meetings, our overall team meetings, and pair programming between developers that happens as needed.
Having gained this “where it goes” understanding, I add a series of initial tests to our automated test suite that, at this point, should fail – using test-driven development. Making sure that we have automated tests throughout the development process allows us to make our future jobs easier, because it will allow us to see what we intend to happen if we go to change this feature later on. It also ensures that our customers will experience as little surprising behavior as possible.
How fast
I also need to determine my algorithm for solving the problem at hand, figure out how efficient my code will be in production, and try to improve the overall speed users will experience when they use the software online. I’m also concerned with how easy will it be to alter or add to in the future.
This is where step (1), why am I working on this, is particularly important. Understanding the different ways that users may want to use the new functionality I’m building helps me make decisions about tradeoffs. There’s a delicate balance between writing extremely modular code and getting a solidly built feature to production for customers to use as soon as possible, and both are important to us. Answering the “how fast?” question is really asking how we can succeed on both those counts.
How well
Once code has been written, and it all seems to work, my attention turns to the specifics – how well has the feature been implemented? This involves using our extensive automated test suite to fill in gaps my initial tests may not have covered. I’ll continue to discuss the feature with the team and receive their feedback and input about my approach.
At this point in the feature cycle I want to ensure that I completely understand the capabilities and limitations with respect to the rest of our software. Can other engineers understand what I’ve written? Is it clear what manual testing and quality assurance (QA) processes are needed before the feature is released? Once the team has finished their review, the code is moved to the master branch. The next place for the feature code is our testing environment.
What
Finally, I’ll proceed to a final individual code review from another developer. When we OK everything together, my new feature is tested by other team members in our staging environment (an internal site, where features are tested right before customers see them). The last step of my process is a set of mini-meeting conversations in which I confirm again that everything makes sense. Can I document what I’ve done clearly? Do another developer and the Product Manager understand what I’ve done? Does the feature fulfill the user story that we started out with? If the answers to all those questions are “yes,” we’ll run the automated test suite a last time. On “pass,” we’ll open the new functionality to users, and I’ll begin the feature cycle again.
