There’s an interesting article at First Round Review by Kris Gale, VP Engineering at Yammer, on “The One Cost Engineers and Product Managers Don’t Consider”…
“Complexity cost is the debt you accrue by complicating features or technology in order to solve problems”
or put another way…
“The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product”
People tend to ask how long a feature will take to implement but there’s rarely any consideration as to the long term cost.
I believe there’s even more to the problem than complexity cost. The long term cost is also related to how well the feature is implemented. It can sometimes be implemented more than one way with different longer term costs or put it another way, different technical debt.
For example, be wary of using/overloading old mechanisms to support concepts for which they obviously weren’t designed – this is usually a sure sign of adding technical debt and complexity cost. Instead, re-design so it’s clearer and simpler.
So, when thinking about estimates, try to also think about the complexity cost and technical debt.
Mobile developers often talk about the difficulties caused by phone fragmentation. However, most projects I work on start quite simple and end up more complex due to ‘real world’ issues. Many of these issues are the same as those experienced by people creating applications for the PC or server. The ‘real world’ needs to cater for…
- Multiple time zones
- Multiple languages
- Multiple locales (e.g. date/time formats)
- Multiple encoding schemes for data
- Multiple preferred ways of paying across countries
- Multiple currencies
- Multiple country codes
- Multiple network operators
- Multiple phone number formats
- Multiple input types
Add this to commonly missed requirements and you can see why I am sometimes a bit sceptical when people come to me and say they need a simple application to be created.
It’s time to wrap up my short series on mobile success factors. I started with ‘It’s Who You Know’ and wrote about working with large organisations such as network operators that have too much inertia. Next, I noted my experiences of projects having ‘Too Many Partners’. I moved on to ‘Feasibility’ and how this is often an after thought. I gave some advice, ‘Don’t Depend On One Market’. I spoke a bit about ‘Capability’ and getting the right people for the job. I also gave some thoughts on ‘VC Funding’. Another area where I have been amazed at companies’ deficiencies is ‘Process’. I also gave some views on the need for ‘Flexibility’ and not necessarily ending up creating what was originally intended. I wrote a short piece on the importance of ‘User Experience’. Finally, I had some observations on ‘Timing’.
My aim was to post some short observations on how I have seen mobile projects succeed and fail. In writing, I often thought to myself that some of the issues were obvious, especially in hindsight. However, people starting mobile projects often ignore the obvious for some reason. Hopefully, I have given someone some additional things to think about.
This final instalment of my observations of ‘Success Factors’ in the mobile industry is on timing. Timing is something that’s usually only fully appreciated in hindsight. Nevertheless, there a few timing factors that can be managed and manipulated.
I see many mobile products arrive ‘before their time’. One topical example is UIQ which was ahead of its time for many years. The UIQ phone touchscreen was developed at a time when nearly everyone believed touchscreens weren’t acceptable due to fingerprints, oil from facial contact and lack of hardware tactile feedback. Ironically, UIQ died just as touchscreens became fashionable. Many applications and services are only now becoming viable with respect to market size.
Mobile projects started say five to ten years ago were chasing small markets. Many ran out of money too early.
Another timing issue I see is mobile products arriving late. Too many developers wait for their creation to be perfected. They continually re-implement parts until the time comes to release and they find their market has moved on or has been taken by another product.
Due to implementation fragmentation, the large mobile market has effectively consisted of lots of small OS/platform markets. Due to growth of the whole market and successes of some of these platforms, some of these small markets are now large in themselves and viable in their own right.
What can you do about timing? I’d say some successful mobile products are those that have been built on previous ideas that were before their time. When you create a product aim to release as early as possible. In this way you will discover problems earlier. Finally, the World’s economic problems aside, now is a great time create a new product or service. What where once small fragmented OS markets are each growing such that targeting just one of them is becoming viable.