How to Go Faster as a Software Development Team

When performance tuning an actual software system, one challenge is that it is possible to measure many different metrics: api response times, startup time, screen load times, etc. It can be hard to know what to measure. As developers, many times we concentrate exclusively on tuning the computational performance of the system, which is important, but fail to address our users’ performance frustrations. The things that our users think are slow will almost invariably be different from the things that our profiling tools think are slow. Focusing on the perceived performance of the system according to our user is critical. If we take steps to reduce the time between the user’s request and the visual feedback to that request, our users will generally be much more satisfied with their experience, even if the api calls have not been sped up.

Here comes the point.

The same can be said about a software development project. Every project, including ours, has sponsors – people who have asked us to do this work. They are “using” our team to accomplish something; the stakeholders are our users. We can take steps to dramatically improve our perceived performance as a software development team, even if we might feel there is not much we can do to improve our computational performance.  In other words, we might not be able to actually go faster, but if we provide our stakeholders and users with visible feedback (software they can use) more frequently, we will have more satisfied stakeholders. They will perceive our performance much differently than if we only communicate updates when they ask us for them, or if we only deliver software at infrequent intervals.

The keys to accomplishing this are 1) open, frequent, transparent communication with our stakeholders and users and 2) continuously delivering a stream of software that is designed to actually meet the needs of well-chosen users.

There many additional benefits to both the team and stakeholders in doing this , but that's a matter for another post (or 20).


@JamieMSmyth