Adventures in product development
For a small company our project portfolio has an eclectic mix. We build everything from large institutional websites to innovative new products for start-ups. Each of these projects offer their own unique challenges. Products, in particular, have required a shift in our typical build process.
Charting your path
With most e-commerce or promotional projects, the confines of the task tend to be relatively well set. Are we trying to sell an item? Promote an institution? If so, our process can assume a linear path: allow user A to purchase item B, direct user C to a course registration, and so on. If we take, for example, an e-commerce check-out process, we typically follow the (mostly) linear path of: search/browse for an item, add item to cart, continue shopping? If not, direct to cart, enter billing/shipping information, complete.
However, as soon as we delve into the world of product development, our path becomes much more tree-like. While our tasks may be well defined – allow User A to book an appointment with User B – a number of associated tasks must also be considered. How does User A find User B? Are both parties required to accept the booking request? Can User B renegotiate the requested date and time? What happens if the booking isn’t accepted within a particular timeframe? How do we notify both users of a potential appointment?
As developers and project managers, our task grows from building a single item of functionality to several associated items. We have to plan for all of them, along with any other associated features that relate to those associated features.
As such, the feature list grows from a single path of functionality, to a tree of branching items all somewhat interrelated.
Planning these paths in advance is crucial to the success of the project. When dealing with features that are heavily dependent on other aspects of the application, scope creep or functionality changes can have an even greater impact on timeline and code quality than with most projects. While an ideal world would afford developers and designers the opportunity to refactor and rewrite modified functionality, this is rarely the case. With many adjustments, a feature’s code base can become muddled, even hacked when too many changes are requested without ample timeline adjustments.
The best way to avoid this is to be pre-emptive with the planning process. By charting out each of the possible branches a feature may require, how that feature will function, and discussing any potentially associated features, we can hope to mitigate the effects of future modifications to the feature list.
Within a company like Res.im, resources typically shuffle from project to project. While teams likely (and should) prioritize any bug fixes, feature requests will need to fit into an often hectic production schedule amongst other – possibly older – projects. This poses an interesting challenge for both the client and development team. At Res.im, we maintain resources in teams specific to different development types. Our “product/application development” team, for example, works specifically on those projects considered custom applications. While resources from within this team may be shared across the company when necessary, a dedicated “product team” ensures that future adjustments can be implemented without too much delay.
Testing all the things
Products are a challenge to test. A “branching” path of functionality necessarily breeds a “branching” path for testing. Testing each individual feature requires testing all associated items of functionality. Unit testing is an absolute necessity – particularly if no designated quality assurance (QA) team exists. Automated testing has been shown to have a significant positive impact on both code quality and project predictability Developer Productivity Report 2013. The more functionality covered by automated tests, the better the resulting quality of the project.
Even if you have a designated QA team, testing the full feature set of a product at the end of the development cycle can spell disaster. With many interrelated components, the likelihood of forgetting to test a particular feature grows. Quality assurance testing is necessary at every single stage of production. Finished a feature? Test it. Then test it again. Then have a non-developer test it again.
Within a robust, feature-heavy project and without rigorous testing at every stage of production, bugs and oversights necessarily arise. Automated testing, and a rigorous feature-based testing schedule prove invaluable.
Product development is often challenging – albeit exciting – work. With slight adjustments to the development process, teams can ensure that an application is built smoothly with adequate foresight into features and problems that could arise throughout the product’s lifecycle.