Code Forward Data Backward

One principle we highly value at TechAscent is what we refer to as "Getting something on the screen early". When starting any new technical project we want quickly maximize communication quality. This breaks down into two flows of information: the flow of code and the flow of data. Data is both your description of your domain and the concrete data generated by what you do. Code is what we provide when standing up a system and solving your problem.

For early-stage projects it is now well understood that efficient exploration and implementation of concepts increases the chance for success. We have developed a process that quickly gets information flowing going both from you to us and vice versa. In particular, the code we write is, as much as possible, developed in terms of real data from your organization.

One way to view any project, schematically, is that we (TechAscent), as developers, stand at one end of the problem creating code. You and your customers sit at the other end of the problem producing and manipulating data. In the middle, we have several instances of the solution known as "environments", which we will now discuss.

Environments

There are several key components to a successful and fast moving project. The aspects we will focus on here are establishing a "truth" in terms of data, being able to work with real data as new features are built, and adapting to a shared and changing understanding of the problem.

Environments act as a buffering agent so that your work is not interrupted by a feature that is not ready and so that we can develop new features as fast as possible. They are separate versions of your application running with increasing stability as you move from our development machines, through a staging environment, and ultimately to the production system.

The most important environment is what we call "production". This is where the real data is edited and consumed. Behind that, is the "staging" environment, where we are able to demonstrate features that are ready for interaction and initial review but are not yet finalized. Finally we have various other "development" environments that run on our local machines, where we add new features and otherwise improve the software.

Each of these environments is insulated from one another; this means that problems in development cannot affect staging, and problems in staging cannot affect production. Moreover, an interesting aspect of this arrangement is that the data you produce and the code that we write flow in opposite directions. More detail on that now.

Code: Our Gift To You

Code moves forward through the three environments. When we write code, we write it first on our development machines with a full version of your application running locally. Here the concern is accurately capturing the main idea of the next feature. Our suite of custom code libraries helps us efficiently make computers do anything you want.

Once the feature is working, we can instantly and automatically update the "staging" environment. There, you can interact with the updated system and give us an initial round of feedback. Often iteration will happen between our development version and the staging version of a feature while we are exploring the best way to solve a particular issue or present a specific concept. Staging is the place where we are running a real system but we have removed constraints that slow down a rapid, iterative approach to refining new ideas.

Once a feature is approved on staging, we then update the "production" environment where we guarantee your data is forever safe - "never lose data". Since we have refined and verified the feature twice already (in development and staging) we can be confident everything will go smoothly in production. The production environment is where you actually interact and start to build out the data specific to your concept. This is a URL you can confidently give to an outside entity - your customer, your boss, etc. and we give our word it will work when the time comes. We do not consider any particular feature complete or bug fixed until it has been deployed to the production site.

Data: Your Gift To Us

Data moves backward from production. As you interact with the production environment you are producing some of the most valuable artifacts of your business - the data specific to your domain and problem. We have developed a careful systematized way of dealing with this data so that we can feel comfortable with one of our primary guarantees - that you will never lose data.

One of the very first things that we generally set up in any project is user accounts with roles that allow our initial power users to both see and edit all of the relevant data to a project. Once the user system is in place, we start creating pages that allow you to see all the data as well as dissect, sort, filter, and otherwise slice and dice it to ensure that what is available in the system is sensible. As early as possible, we will have ways of importing existing data in bulk into the application's database, minimizing or eliminating the need for manual data entry. Modeling more and more of your business in data creates many possibilities; from simple automation of repetitive tasks, to analysis, and machine learning to bring deeper insights to light.

Once we establish the production environment as the "source of truth" for the project, we are then free to propagate the data backward to the other environments. When we want to demonstrate a new feature or bugfix, we do so on the staging environment, and in terms of a copy of the latest data from production. doing it this way confers two main benefits:

• We can ensure that the feature or bugfix works with real data
• Data can be freely modified or deleted in staging without worrying about breaking production

A real world example will make things more concrete. One client we have recently been working with has an application that has a number of forms that need to be filled out. Part of the challenge to this problem is that the shape of the forms has changed over time, and the existing solution requires those changes the the forms be made by programmers. Instead, when we took over the project one of the first things we built was a template builder for the forms, empowering users of the application to make their own changes to the forms. Then we imported the existing form as an example template. From there, the client can view and edit the template to match their desires without programmer intervention. Working with real data early on in a project has proven to be an invaluable contributor to success.

Conclusion

We emphasize adopting your data and concepts as soon as possible - within the first few days of getting started on a project. Our tools enable immediate deployment of all three environments, together with the flow of code and data in both directions. Having this out-of-the-box allows you to see real data on a real site continuously throughout the project; this is tremendously valuable and a big part of our successes.

We hope that this post has explained some murky aspects of how we help you bring a concept from conception to congratulations. With this simple template, we have successfully developed many projects and helped teams rapidly realize value from their ideas. The use of three environments together with the concept of 'code forward and data backward' bolsters communication and leads to a shared understanding, and ultimately a successful application that we all can be proud of.

Help TechAscent help you!

Contact us