Welcome

Few days ago, I found myself writing a loooong answer to this post. It’s written by one of my new co-workers, so I thought a response-post could be a better idea.

I totally agree with most of the points of the article: we should get feedback from users in order to be able to give them a valid solution. Otherwise your product will be totally useless, solving “problems” that nobody has.

But the question is: what is the best way to get this feedback? and, are you and your users able to give you the right feedback when you reach them at first?

Probably those women didn’t know how important was the far-distance-well for their lives and they discovered it just when they experimented other ways. Or maybe they knew that the far-well was important, but needed to live without it, in order to balance the pros and cons or having water at home. Who knows! The fact is it use to be quite difficult to discover some kind of things with certainty without experimenting with them first.

Unfortunately, common sense (and engineering-way of thinking) told us the opposite: always try to reach the right and final solution at the first attempt, but it’s not always feasible, or it may be possible, but it needs an extremely hard planification and design phases. Engineering-way of building things (as wells, bridges or roads) spend a lof of time in these preliminary phases, just because they cannot use “trial and error”: if they fail in the first attempt, the waste of time and money is so high that they cannot afford a second chance.

But fortunately software is quite different because the cost of failure is relatively low: you can fail once, twice or even more time, learn thru the process, and deliver a better product in the next (maybe the last) try. That’s why one of the easiest ways to get right feedback in software is through prototyping and experimenting (this article about game development approaches explains it much better than me, so please, read it for more details). And this method gives to us a nice-to-have side effect: it forces you to write the code in such a way that it’s flexible, simple and ready to allow the change, no matter how big it is.

This way of working thru iterations is so powerful that even physical products are been building using this approach. Apple’s products follow this rule: first versions of gadgets tend to be very limited, and then they’re improved version by version, meeting market expectations and customers needs. It would be much faster and cheaper to build the perfect smartphone in the first shoot, but that’s a pipe-dream and they need to iterate over and over again.

In summary: if you’re writing software, don’t make too many assumptions in your first attempt, don’t waste too much time analysing, designing, architecting and planning: just build a simple enough prototype, give it life and see how it breathes (if it does). Then get real-world feedback and change towards that direction. Repeat until your users become fans, like Apple ones (:

Bash:

Enjoy!

One of the best things of changing your job is meeting new people and learning from them. And if one of your team mates was a Googler almost for 6 years, then it’s really exciting the amount of things you can learn in the day-to-day.

This time, I asked my team mates about the approach to start to write automated tests in our iPhone app. Testing is quite fun when you start your project from scratch, it gives you a nice feeling of security, self-confidence, and power. But if your code base is around 15k lines of code, then it isn’t so fun.

Next is his response. Most things are well known (sure, write a test to validate every bugfix, have a CI server and so on), but I think it’s worth reading it once again.

Here are my thoughts about unittesting.

Writing some unittests is better than writing no unittests. I don’t know much (anything) about iOS mocking frameworks, but as long as they work and they seem to do what you need them to do, making a choice is better than spending too much time in analyzing what works and what does not work.

At the same time, I feel that there is such a thing as writing too many unittests. This is something best learned with time and experience.

Having a Continuous Build somewhere will make everybody happier. Whether you want to or not, there will be a time when you won’t run the unittests before committing. I’ll do that, you will do that, we generally suck at self discipline. Having a CB notify you that you broke the build saves that awkward moment a day later when another dev sees that I’ve checked in code that breaks the tests and they’ll feel resentful towards my negligence. Besides, having this CB also helps to immediately notice what change broke what test, which becomes harder and harder when the number of code commits starts being large.

Writing clean good unittests is an art and it’s just as hard as regular software engineering. Good unittests are small, self contained, clear, the names of unittests need to be good so that when they break it’s immediately obvious what broke. This takes time to learn from my experience.

Good unittests are written to test only public interfaces of a class, never private methods. Testing private methods makes classes hard to refactor. Testing only public interfaces makes you think twice about designing the public interface of that class, which leads to better classes and better structure.

A good rule of thumb for writing a test is to write one every time you fix a bug. This can be annoying because sometimes the fix is a one-line change and the test takes you an hour. But it’s a good practice that pays off in the long run.

Hope this helps, Vivi.

Thanks Vivi, it’s been an awesome time working together

Life is a sequence of moments. Some of them are good, others are bad and few of them are great. And all of them makes your life’s memoirs, a kind of logbook that makes you what you are.

This month I’m starting a new adventure. After almost 8 years working together with my friends and mates of Unkasoft, it’s time to move on and start new things. I’m absolutely proud of the job done these years. We’ve made from scratch a great company, I met some of my current friends and a lot of talented people and I feel happy to leave them with a huge opportunity ahead to finally make a first class game with Numbered. Good luck my friends!

So when I started to look for a new project last summer, only one thing was clear: I wanted to work in a startup, as small and new as possible. It’s risky, but I really like taking risks and be commited from the very beginning. So few months later, one common friend introduced me to Lee Hoffman and Angela Kim. We started to talk (well, they talked and I barely understood) and a couple of weeks later it seemed that they were looking a guy like me and I was looking a startup like theirs. Love at first sight (:

So here we are, working in their brand new startup called YourMemoir. It’s still unveiled but soon we’ll make the public lauch.

The best thing of working with people like Angela and Lee is I can learn from them, from a superb team and from people I really admire like Joel Spolsky and Eric Ries, both advisors and investors in the company. It’s absolutely a privilege for me. And to cap it all, I’m having the opportunity to live in NYC for several months and then come back to my town.

An amazing year is ahead with lot of experiences to be lived!

Stay tuned!

Last summer, I had the chance to spend few hours with the guys of Vizzuality. They’re quite good doing time based visualizations, or “stories that matters”, as they’re used to say, and his product CartoDB is awesome for store, manage and query geospartial data.

So, because of it was a great opportunity to build something cool, we started to work together in order to make a 3D visualization of Indonisia deforestation in the last years.

The backend used was CartoDB through their SQL API and my CartoDB objective-C client. On the client side, we used and early version of WhirlyGlobe. It’s too bad some weeks after that, Steve Gifford released an easy-to-use component, so I had to fight with the codebase, which was a mess of C, C++, Objective-C and Objective-C++, pretty difficult to understand and adapt. Anyway, it seems it was not as bad as I thought, because as Steve said, “you’ve done some really advanced things and used some features even I rarely use.”

I’m pretty proud of the result, especially considering I spent two fulltime days and one week more doing 1-2 hours a day.

Here you can see it running in the iPad simulator:

Hope you like it!

UPDATE: Steve has highlighted this tiny project on his blog. I’m so honored and absolutely grateful!