Simplicity is the ultimate sophistication

I can't take credit for the title of this post. It's one of Steve Jobs maxims and was used in Apple's first brochure. I also like "less is more" and after reading his autobiography, I liked the fact that he pushed to remove and simplify at every step of product development.

We are constantly told to simplify a product or service but never really told why or how. I particularly liked Jony Ive's philosophy. He said that we like simple products or services because we feel like we can dominate them.

This is a great way to look at it because if we feel like we can dominate them, we are more likely to feel like we are in control and consequently, use them more.

He also said that simplicity isn't just a visual style. It's not just minimalism or the absence of clutter. It involves digging through the depth of complexity. To be really simple, you have to go really deep. You have to understand everything about it and it's essence in order to get rid of the parts which are not essential.

When you look at some of the user experiences in software and the web today, you can immediately tell where the the product or service owner has gone deep and where they haven't.

Can you think of any examples where you can tell? Let me know.

If in doubt, under promise and over deliver

A company I used to work for had 5 fundamental rules which it asked all it's team members to follow, of which number 3 was "Always deliver what we promise. If in doubt, under promise and over deliver".

I always have this rule in the back of my mind during sprint planning as there is always some degree of doubt when you first estimate a task. Therefore, the estimate is usually slightly higher than the amount of time I think it will take me to do the task.

If I come in early, I've exceeded expectations and if I found it was taken me longer than I thought, I come in on time and have matched expectations.

If I didn't follow that rule at all, I would have been late leading to client frustration and loss of trust in the future so I think it's a nice rule to follow sometimes.

What do you think?

Thoughts On Native v Cloud Apps a.k.a. UX v Sharing

With all the recent news of the wonders of the cloud with Apple releasing iCloud and Google releasing Chromebooks, I thought I would write a post on my own thoughts on the subject. Feel free to post you own thoughts on this subject by commenting below.

The title of this post could be misleading because it suggests that these are competing technologies, and to some extent, they are. However, they also complement each other in many ways, and when choosing your own strategy, you need to think carefully about what is important to you.

I strongly believe in user experience (UX), it's what I first started off doing in my career and have still have a keen interest in. It's one of the hardest things to get right, but when you do, it's great, and users love it.

In my view, you cannot beat the UX of native apps as they work using the API's directly offered to them from the hardware you used to download them from be it a mobile phone, tablet or laptop. They are quick, don't need the internet to run and we have all enjoyed using them for many years before the internet was just a twinkle in Sir Tim Berners-Lee eye.

After being very creative on these native apps, the next thing you want to do is share what you've done with others and have their creativity contribute to the success of the work. This is where the cloud comes in and things get complicated. Let me explain.

The cloud let's you share your work easily because it's just a bunch of computers connected to each other and its those connections which makes it possible but by it's very nature, the cloud is a layer of abstraction from the device meaning that the native API's no longer become available and you loose that native UX. You also get ads as the providers have to make their money somehow.

I've found a mixture of native and cloud apps works best for me depending on what I'm doing at the time. What works for you?

Red Bee Media: A Retrospective

Today is my last day at Red Bee Media so I thought I would write a retrospective of my time here.

The strongest aspect of Red Bee has been the diversity of it's talent. We've had guys working here from places I can only dream of visiting from Réunion to Xinjiang. I hope that, maybe one day, I will visit these places as I regard many people not only as colleagues, but as friends.

While everyone came from different places, we were united in many ways like work ethic, technologies and our ability to deliver projects.

This was reflected by everything we achieved in those years. When I look at the position we are in now and what we have delivered in that time given the people we had, it was been nothing short of remarkable and I think I leave the guys in an excellent position to continue that success.

I have always felt that the team was at it's best when individuals and interactions were favoured over anything else and this reflected in the speed at which we delivered projects. Let's hope this continues in the years to come.

I can honestly say that the learning experiences I have gained here, working with what I considered to be the brightest minds in the industry, has been phenomenal. In particular, many aspects of agile development including test driven development which, if you are a regular reader of this blog, you will notice that I strongly believe in.

My first thank you has to go to Stacey Anklam who gave me the job. I never thought it would turn out the way it has. For their leadership, Shams Uddin and Ross Weaver who have given me advice and support during my time here, and for their technical leadership, Dilshat Hewzulla and Bertrand Payet who's knowledge never fails to impress.

They were the reason why my time here flew by.

I hope that I get the opportunity to work with the guys again sometime soon but in the meantime, I will miss them all.

Don't spend too long on tests

If you are a regular reader of this blog, you will know that I strongly believe in test driven development (TDD). However, I wanted to share my experience of learning TDD with you so that if you are learning it for the first time, you don't fall into the same traps I did.

When you are writing your tests first, and find that it is taking some time, stop and ask yourself, why is it taking so long? The tests, like the development, should be simple and quick to do. Don't forget you still have to do the actual development and the project manager will be asking you to demonstrate what you've done before you know it.

So, if they are taking some time, it usually means that you have began to do the following:

• Started to test features that you shouldn't be testing. Remember that you should only be testing what you've developed, not what somebody else has. Check your test boundaries, make sure you haven't gone outside them. If your test is something like 'Test call a web service should return back a response', make sure that your not testing 'Test call a web service should return back a response and make another web service call'. Ask yourself, what are my inputs and outputs? In the example before, the input would be the call to the web service, the output, the response. You can then write your assertions on the outputs.
• Asserting things that you should be asserting. If you are spending some time on writing some complex assertions, make sure that they are relevant to your test. Go back to your pass and fail criteria and make sure that they are covered. If they are, finish your assertions.
• Write a test which has too much set up. If you find that you've just spent the last hour just writing the set up data, ask yourself, is this test worth it? This problem is usually a design problem where there is too much tight coupling with means you have to endlessly inject dependency data to get the test running. Take another look at your design and make sure that the components are loosely coupled and can be tested in isolation. TDD forces you to make good design decisions, whether you like it or not! It makes you think about things that you wouldn't normally think about.

That's all I can think of right now but I'm sure there are more. If I think of any, I'll update this post.

I'm interested to know what your learning experiences have been around TDD. Why not add them as a comment below.