I have worked in many software projects and have been lucky to be in the initial team of several software products. Besides, having acted both as a Developer and as a Product Manager has allowed me to have a wider view of what usually causes most friction between business and engineering: time estimates.

It usually starts with managers or customers asking “when will <this idea> be ready?” and it is usually followed by developers racking their brains to give a specific date… Needless to say, that date is likely to be dreadfully wrong, as it is the norm in the industry. There is a near-total inability of developers to predict how long a project will take, so time estimates are usually worthless.

However, applying Scrum along with some XP practices we can avoid the uncomfortable tension of asking developers for time estimates. Instead, we can calculate release dates automatically, getting infinitely more accurate time estimates, while saving all the arguments and keeping team morale high. How? Keep reading!

…That I will take into account for the next one.

Being the Founder and CEO of Vocabulary Notebook for more than 2 years (from September, 2012 to January 2015) was one of the most intense, enriching, stressful and exciting experiences I have ever lived.

During this period I went from doing some mockups alone at home and printing them in paper to use them as low fidelity MVPs for customer discovery; to close a seed funding round, found a company, build a multiplatform product, build a team of 12 people, receive several awards, participate as speaker in 3 international events, get 30 000 users in more than 130 countries, register a trademark, conduct scientific research on our product and collaborate with schools and universities from 4 different countries… As I said before, it was intense!

Sadly, two years after the beginning of this adventure we had not been able to reach the break-even point yet, we had a cost structure that we were not able to maintain and we didn’t manage to close another funding round to keep us going (to keep improving the product, launching marketing campaigns, validating new hypotheses, pivoting and improving our business model…). So, by last summer we had to start progressively reducing our cost structure, until we had no option other than shutting our startup down completely.

However, during this amazing period I learned very valuable lessons, some of which I am going to share with you now, if you keep reading:

Too often people tend to think that UX is just art: Flat design, Modern UI and animations… But art represents only a tiny part of the User Experience. Some developers go one step further and think that it also implies strong technical skills (to achieve a good performance, proper-functioning software, etc). However, that is still a very narrow perspective of User / Customer Experience.

Some of us have realized that UX is not just how beautiful our product looks or how amazing its performance is. There are several other fields that are crucial when trying to achieve a great experience for our users, as you will see in this post. And if I had to choose just one field that is definitely key to UX, it would be Psychology.

Thanks to my experience as Entrepreneur and Product Manager, I realized long ago about something that is totally counterintuitive for many other software engineers. This realization is that, when developing a software product, our main focus should always be sales. Always. Sales. I know that probably too many people have said that already, but it is so true that it is worth saying it once more, specially for my software mates: “when developing a software product our main focus should always be sales”.

However, that statement is too generic. Most people already know that selling is important… But how can we sell more? Well, experience tells me that in order to increase sales, the first thing you will probably need are many more visits (and getting those visits is way more complicated than it seems). However, that is only the beginning. Once you get enough visits and you validate most of your product main hypotheses, the next step is converting most of those visits into customers. Here is where both User Experience and KPIs (Key Performance Indicators) become probably the most important areas for product management.

The 8th of September 2012 I started to work intensively on an idea I called Vocabulary Notebook. With that idea I was planning to solve a problem that myself and many other English students experience while learning vocabulary. It has already been a year since then and that idea is now a real platform used by thousands of students and teachers around the world. I must say that I’m quite proud of what we have achieved during this year, both as an entrepreneur and as an engineer. Although I don’t have much free time now, I have forced myself to write this post to summarize what has happened around Vocabulary Notebook during this year, from idea to reality. Since there are so many things that have happened, I’m afraid this post is going to be quite long, but I think the anniversary deserves it.

In this image we can see the different components of Vocabulary Notebook. The full platform includes Android, iOS and Web Apps both for students and for teachers.

I would like to start this post anouncing that this month I am leaving Arte Consultores Tecnológicos, after one year and seven months working there as an Analyst/Programmer (Front-end Engineer). I have made this decision because right now I need to devote myself exclusively to Langproving, which is in need of my full atention at this critical moment in which our MPV is finished and we have to market it to validate our business model.

In this period of time working at Arte Consultores, I have improved significantly as an engineer. I have learnt a lot. Fortunately, I have had the great pleasure to work closely with my workmate and friend Axel Hernández, who I admire for his ability to constantly learn new technologies and for being always aware of all the new trends in software development. I’m proud to say that I have learned a lot from him. I would like to think — actually, I hope — that he has also learned something from me too while we have been working together.

One of the most valuable things I learned working at Arte was related to writing modern and usable web interfaces, not only with CSS3 animations or HTML5 new attributes and tags; but also with Javascript. In the last few years Javascript has grown up and become one of the keys of the evolution of the web. Many Javascript frameworks have emerged, ranging from those regarding DOM manipulation (jQuery) to others built to reproduce the model-view-controller (MVC) pattern in the client side, such as Backbone.js. For more than a year I have been using Backbone to create Single-page applications that provide a quick response to user interaction, without the need to re-render the full page from the server as we were used to; thus improving sifnificantly the user experience (UX).

I had this article started but uncompleted since September 2012, and as a New Year’s Resolution for 2013 I decided to finish it.

Back then, I had been working for some months as a Front-end engineer in Stat4you. In the early summer we were in a hurry to finish the alpha version of the platform, so we released it without paying too much atention to the details. A feature that was included in this release were the filters for the charts, by means of which users were able to change the positions of the dimensions and also to enable and disable the categories of those dimensions, thus changing the chart being displayed.

The images below are screenshots of the filters initially released in Stat4you:

The image above shows the filters available for the tables in the initial alpha version of the platform. The blue elements represent the containers of the dimensions which, in this case, have been also placed in a particular way to help the user understand the position in which every dimension will appear. The white elements represent the dimensions whilst the orange ones represent the categories of each dimension.

The Front-end engineer is a relatively recent role in software development, but its importance is growing everyday as the importance of Javascript does. I’ve been working as a front-end engineer in the Stat4you project since January and in this article I will try to describe this role, emphasize its importance and highlight the differences that the introduction of Javascript has brought to the development of the front-end of web applications.

I would like to introduce this article with a quote from the human-computer interaction expert Jeff Raskin that summarizes quite clearly the importance of software interfaces from the perspective of users. It reads: “As far as the customer is concerned, the interface is the product”.

Although the quote above seems quite obvious, often developers and managers tend to forget or underestimate the importance of user interfaces, blinded by the complexity of the back-ends of the applications. This blindness has led many projects to failure, but fortunately this is starting to change.

In order to continue highlighting the importance of user interfaces, there is another quote from Linus Torvalds on this topic which I also fully agree with: “In many cases, the user interface to a program is the most important part for a commercial company: whether the programs works correctly or not seems to be secondary”.

I’ve been trying to set up a new Blog for a while, but to use a nice excuse, I haven’t had enough time to do it. On Friday I was talking with my workmate Axel about Octopress and it seemed interesting to me. I have just finished the installation and deployment of it using GitHub and it has been rather easy.

While I was reading about Octopress, I found this post where the author writes about the importance of static rendering for webpages and blogs at present. Nowadays the most popular CMS systems store post and pages in a database and then they build the pages from the database on every request. Although it is also true that there are some cache plug-ins to improve this behavior, he states that this traditional implementation is inefficient. This idea reminded me that two years ago, when I built my own CMS for personal websites Sigecu CMS, I had this idea in mind, so what I did was to generate a static HTML page every time the user makes a change in the website, avoiding this problem. I would try to write some posts in the future about Sigecu.