Complexity Cost

firatroundreviewThere’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.

The Best Way of Doing Things

uxmagazine.pngUX Magazine has a recent article on balancing product User Experience (UX) and lean execution. It describes how effort put into the UX should vary depending on the stage of product development. For example, if you are at the initial ‘Technology Stage’ you probably need little UX effort and should be concentrating on a minimum viable product (MVP). Conversely, if you are at the ‘Experience Stage’ you need to concentrate heavily on the UX.

There’s more to learn from this. The preponderance of conferences, articles, webinars, blogs and even my sites describing how things should be best done are often taken to be the way they should be done. People love to latch onto the ‘best’ way when, in fact, the best way depends on the situation. You can usually recognise this when someone says ‘that’s the accepted/standard/best way’ in response to a discussion, with no further justification.

This doesn’t just apply to UX. In app development it applies to many other areas such as what server backend to use, what 3rd party libraries to use, how secure the app has to be or even what mobile OS platform to use. The next time you have a choice how to do something don’t just look at reviews/comments on the technologies available but also think about the project situation. This includes the stage of product development, the team’s skills, the budget and timescales.

If you are a startup creating a team, remember that some seemingly clever but pedantic people can send you down an expensive and deep back hole. Instead, search out cleverer pragmatic people who have previously demonstrated they can balance implementation with the needs of the company.

Programming Performance and Complexity

oracle.gifThere’s an interesting interview with Joshua Bloch on Oracle’s site. Joshua is the author of "Effective Java" that I happen to already have on my bookshelf. Joshua says some profound things about optimisation…

"It’s easy to feel like the general warnings about premature optimization don’t apply to you, because you just know which code is time-critical and how to make it fast. But no one can determine this without measuring before and after each attempted optimization."

It’s true some developers love optimising things they don’t need to. However, it’s also possible to go in the other direction and totally ignore performance. I’d say that if it’s easy to optimise something AND the code becomes clearer then there’s always a case for spending a moment for a quick read through the code to see if it can be simplified. If it’s complicated to optimise OR the code becomes less readable then we are in the usecase Joshua describes.

Joshua also says…

"In order to stay sane, most developers have a can-do attitude, and some take it too far. They say to themselves, ‘Yes, there’s a library, but I can do better.’ Maybe you can, but that doesn’t mean you should."

This is another problem with some developers. They love to invent or use mechanisms that might not be needed. I worked at a large company a long time ago, that happens to be source of this article, where there were tens of implementations of ‘String’ in the same product just because developers thought they could do better. I have also worked on others’ code that has been over ‘Design Patterned’ that has led to a technical debt.

As Leonardo da Vinci said, “Simplicity is the ultimate sophistication.” 

Mobile Application Strategy Failure

gartner136.gifToday I came across a recent Gartner press release where they identify "10 Mistakes That Lead to Mobile Customer Service Failure". While the mistakes are mentioned within the context of a customer service application, I see them as applicable to any kind of app…
  • Violation of the "three-click/tap/press" rule
  • Difficulty with ergonomics, especially text input
  • Not reusing learned behaviors — such as soft keys, navigation
  • Violating "security 101." 
  • Difficulty with navigation
  • Burying most important functions
  • Incorrect or illegible display of text or graphics
  • Inability to revise mistakes
  • Content visibility
  • Resource inefficiency
This list of mistakes, described in more detail in the press release, provides a useful "flight check" before embarking on a mobile app. I also have some missed requirements and programming complexity requirements that you might also use as flight checks.

Mobile Banking for the Masses and too Many Partners

cgap.gifIf you working in the area of mobile money, particularly in emerging markets, you should take a look at Beyond Payments: Next Generation Mobile Banking for the Masses, Strategic and operational lessons from pilots in emerging markets  (PDF) commissioned by Bill and Melinda Gates Foundation.

bankchoiceeducation.gif 

The paper explores the potential of mobile technology in providing low-income consumers with access to a wide range of financial products that go beyond simple mobile payments. It discusses such areas as distribution strategies, mobile microfinance and microfinance banks.

The ‘Findings in a nutshell’ section is an interesting read for anyone in mobile. It says…

"The strategy alignment phase between partners can often be long and can signicantly delay launch timelines" and

"It is often difficult for partners to agree on a sustainable profit model"

Both these problems are similar to my previous observations on Success Factors: Number of Partners.

Programming Complexity

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.

Mobile Success Factors Wrapup

genericmobile.gifIt’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.

Success Factor: Timing

genericmobile.gifThis 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.