Rapid Software Development: Building Stable Products

Rapid Software Development: Building Stable Products

Jon Jones
Jon Jones
5-minute read
<| BACK TO BLOG

Explore Anthroware's unique approach to rapid software development. Discover how we plan, build, test, iterate, and deliver stable software products quickly.

Picture turning around an initial version of a software product in two to three weeks. As a customer eager to see your idea alive and moving, I think that would be a pretty exciting concept (it’s a pretty exciting concept for me and I program the stuff!). Let’s be clear, though, I am not talking about some ball of wax software nightmare. I am talking about a project that is stable, secure, well-architected, and has enough tests to confidently be released into the wilds of the internet. Such a stable turnaround time is powerful stuff and I want to share how Anthroware can do precisely that.

First things first: Our product owner slides over with the lowdown for a new project – shipment management and tracking. “What we’ll need from engineering,” he says, “is a website and mobile apps, both Android and iOS, in the space of a few weeks.” Okay. Considering the scale of the web app, the use-case, and that we are going to need mobile development wrapped up quickly as well, the team decides on the following programming languages and frameworks: Ruby, Rails, and React-Native. With a broad understanding of what needs to be built, the client onboard for a Minimum Viable Product in order to prove their idea, the engineering team can move into architectural discussion and documentation.

So, the next task set before us is understanding the necessary architecture along with documenting our path forward. Settling comfortably into the realm of esoteric architectural discussion, the team begins to hash out all the bits and pieces required to get this project up and running. What will we need? Well, we have the usual suspects: Authentication and authorization; we need to make sure people can log in as well as be confident they can manage only that which they are authorized to. Considering our task of building a shipment management application, we have requirements to manage shipment orders and track them against customers. We break these requirements down into component pieces, considering all of the atomic operations that will be necessary on them.

Why so granular? Well, it reduces the amount of, “Oh, I hadn’t thought about that” scenarios right smack in the middle of development. This phase of the project specifically aims to avoid those future head-scratchers as best we are able.

Now, having sussed out the inner workings of this new application, we write it all down. We distill the knowledge gained from our internal back-and-forth discovery process to create a “roadmap” architectural document for the subsequent development process. This final document turns out to be quite specific, detailing how its constituent parts will come together and interact. So, the end result of this phase turns out to be twofold, producing this architectural “roadmap” along with identifying problem spots, and ideally resolving them, before they arise in development. All that said, the engineering team walks away from this process with a clear path forward: A list of items to check off, moving smoothly from component to component with little worry that something
unexpected will crop up.

Taking our roadmap in hand, we can begin creating the projects we previously identified. For example, the team lead can get started by creating a web project, an API (Application Programming Interface) project, as well as a project for the mobile application code. Those three will give us the base to work against enabling the team to finally hunker down and start building the application! The roadmap remains critical throughout this process. It acts as a guide that will see us through from one end of the project to the other.

The roadmap remains critical throughout this process. It acts as a guide that will see us through from one end of the project to the other.

Once we complete one component of the app all we need to do is consult the roadmap and continue on to the subsequent component. If the team is composed of multiple developers, this roadmap will allow us to more easily break up the work load and focus each team member appropriately.

As we go, churning out each successive component, we follow it up immediately, if not as we code, with unit and feature tests. The distinction between the two tests lies a bit out of scope for this post, suffice to say they ensure the code is working as expected. Personally, I consider tests to be a very important gauge of the development team hitting their stride. Tests will keep the codebase stable, lessening the likelihood of regression, as the team continues on to make changes and adding components. You may find it surprising that it isn’t altogether unusual for some change, or new feature, to unexpectedly make itself known in some far-flung component of the application. By keeping on top of our tests we make sure these unexpected bugs are caught early, lessening headaches on down the line. With this approach, tests become a “peace of mind” for the engineering team as they are consistently reassured that the codebase is stable.

Now, as this process continues, the team iteratively builds on top of successful components writing tests as we go. User accounts will be stable. Customers will be stable. Shipment tracking will be stable. The interconnected bits and pieces will be stable as we continue to confirm the “correctness” of the application via tests. As we sequentially build these components we end up with finished projects that are guaranteed stable. First, usually, will be the web project. Following that, often times, are the API resources to enable the mobile application to function properly. Finally, the engineering team will close out by building the mobile framework following the same principles.

Along with this iterative process of development, the team makes sure to keep in constant contact. We discuss what we accomplished the previous day, where we’re heading currently, and raise questions and concerns where necessary. We also keep our customer looped in – often times directly in the group chats we maintain for our own internal communication. This approach lets the entire team stay abreast of what’s happening, correct any “scope creep” from the prescribed plan, as well as involving our customer in the exciting process of watching their product as it grows and takes shape.

Well, there you have it. An Anthroware development “framework for success.” A framework I find very exciting as an engineer. This approach has enabled us to focus the engineering team, rapidly build a stable software product, and energizes the team throughout the build process. We understand your idea, plan, build, test, iterate, and wrap it up in a nice bow.

Jon Jones
Jon Jones
Co-Founder/ CEO
Asheville, NC

Jon Jones co-founded Anthroware in 2013 to build brands and products the right way— always starting from a creative, design and user-first posture. Every project is a product!