TrackAbout Developer Mike Mertsock published the following post on his blog Running | Code. Drawing on his experience developing TrackAbout’s APIs, Mike provides 11 tips for successful collaboration between mobile and API development teams.
API-driven mobile app development requires more than good engineers and the latest technology. Whether your organization is a startup, or an established company expanding into the mobile space, you may be creating the app and API in parallel. The mobile and API teams will need to collaborate effectively in order to launch a successful product. In fact, I would say that communication and teamwork can be more important than the choice of server-side and client-side technologies.
Mobile and API developers can write great code in their respective silos, but if the interaction between the two teams is not top-notch, the interaction of the app and API will reflect that. Teams will end up with divergent understanding of the work. Timelines will get out of sync. Developers will be fighting to get the client and server to work together as anti-patterns and incompatible interfaces emerge. Every new feature will repeat a cycle rehashing the same bugs, fighting the same structures, duplicating slight variations of boilerplate “solutions” to the architecture problems. Friction will rule both the programming work and team dynamics.
At TrackAbout, we already do a lot of system performance measurement. We’re about to start doing even more. Database performance plays a large role in the overall performance of the TrackAbout service. In this blog series, we will discuss a new approach to measuring and monitoring the performance of queries against our Microsoft SQL Server relational database environment.
The performance of our software is an important part of our end-user experience. We encourage all developers to adopt the philosophy that performance is a feature. Apps and services that perform well yield many benefits. At its simplest:
- Speed makes users happy
- Efficiency keeps costs down, in the form of requiring less hardware to get the work done. This enables us to scale up our company more easily.
In technology, many performance problems can be solved by throwing money at them. Throwing money generally boils down to either (1) upgrading or adding hardware and infrastructure or (2) improving the code. Sometimes it’s not clear which approach yields the best price/performance. First, you need to know where the bottlenecks are. That means measurement.
Ultimately, we intend to define internal Service Level Agreements (SLAs) for query performance to which our engineers will strive to adhere. We do not know yet what our target SLA numbers are going to be. We will have a clearer idea once we start gathering and analyzing current performance data for our queries.
Understanding why certain queries are slow will enable us to better educate our developers as to how to avoid creating performance problems in the first place.
We are open-sourcing all the code we develop as part of this effort. You can find it on GitHub in our sql-perf-monitoring repository.
Today we are introducing TrackAbout’s new Status Page: http://status.trackabout.com
The status page provides transparency into the health of the TrackAbout services. It’s hosted independently of our services so if our services go down, the status page stays up.