Why processes/methodologies are no silver bullets for software development

Every time you hear that a new process is about to be implemented at your company to increase productivity or software quality or creativity you should open wide your eyes and look around. Chances are that the problems are not processe related in the first place. 


Let me start with a true story about bolts, washers, and nuts. I was in the 5th or 6th grade when all the boys from my class had the privilege to understand the working class: once a week we were taken to a factory and given the task to put together a bolt, two washers (split and flat), and a nut (these Kafkaesque tasks were common during the communist regime). In front of us on huge steel tables was a pile and we had a quota. After a while we realised that if we split in teams and each person does only one task we will finish the job faster. A simple change in the process increased our productivity while the people working on were the same. Continue reading

Keep Walking

I had the time of my life at Adobe, especially the time spent as an evangelist. I still remember the day I met Ben Forta for the firs time and he offered me the chance to join Adobe’s Platform Evangelism team.

Right there I knew that it was a big opportunity. But even so I couldn’t imagine the impact will have on me not only from a professional point of view but from a citizen of this planet too. As developers we think that we know our clients and users. Some might actually know. But for the most of us it is always more about the ride then the summit. And for software products you have to make happy your clients otherwise there will be no trip anymore. Continue reading

Vienna and Creativity

Last week I spent two full days in Vienna with no business obligations – just me, my wife, and the city. It wasn’t my first time over there and yet I had so much more fun than I thought I would have. With the images and experiences still fresh I thought I should share them with you.


In one of the museums I visited I saw these words (won’t tell you where, you have to read until the end):

Our real illiteracy is not the ignorance to read and write and not the incapability to repeat other people’s knowledge, but the inability to create.

There is something about these words both powerful and worrisome. At least to me.

Continue reading

9 years and counting

This post is not about technology so here is your chance to let this pass by and do something else. You’ve been warned :)

Around this time of the year I started my journey at Adobe, nine years ago. And what a journey it has been so far! I started as an engineer on a team that was mainly building web products using HTML/JS/CSS/PHP/ColdFusion/MySQL. Two years later I joined the Flash Builder team and worked with Java and Eclipse platform on this crazy Eclipse-based IDE. Finally, about five years ago I was given the opportunity to join the Adobe Platform Evangelism team as a developer evangelist – and this was (and still is) the dream job I’ve been dreaming about :).

Just to give you some context. I was born in a communist country “enjoying” one of the harshest dictatorships from the past 40 years in the civilised world. Things like freedom of speech and traveling abroad were just some distant theoretical concepts. Even computers were really hard to find during that time. I remember that it took my parents about 3 years to get me a HC-90 clone. Until I got my first computer, I used a piece of paper and a pen to write programs. That was a dark time; fortunately it cost me only my first 13 years. Looking at my life now I feel like I live in a dream. A good and warm dream, not a nightmare with some Kafka twists in it.

I wouldn’t be where I am today if some people didn’t believe in me. I want to say thank you to Ducu, Ben Forta, Enrique Duvos, Kevin Hoyt, and Andrew Shorten. Your advice was (and is) deeply appreciated.

This is just the tip of the iceberg because there are many others that helped me to better understand the developer ecosystem: people I met at conferences and customer visits, people from all over the world. And with some I became friends. This is why I feel at home in places like Zagreb, Zurich, Oslo, Lisbon and Porto, Copenhagen, or Milan.

And finally I want to say thank you to my wife. Only she knows what it takes to take care of two little children while her husband is flying somewhere over and over again. Thanks honey and I am looking forward to another amazing 9 years!

About web standards, speed, and time

If your work targets the web then it is almost impossible not to hear something like this:  “Man, the standards are moving so slow!” every now and then. Usually this introductory statement is followed by a second part that you wouldn’t say in front of your mom/dad/children.

Basically, the belief is that if there were enough motivation it would have been a matter of months (maybe weeks if you are the type who sees unicorns without consuming stuff legal in Amsterdam and illegal in the rest of the world). Fewer people choose to question not the motivation/drive of the people involved in the standards but their abilities: “if we only have smarter people there”.

If you believe that these are the two main reasons that prevent standards from moving faster than let me tell you that YOU ARE WRONG!

Let me give you an example that illustrates the fact that things cannot be speed up by getting the smartest people around and proper motivation. Let’s start with motivation. What better motivation can a human have then fighting for his own survival? And what about having the smartest guys for the job actually on your team? Basically something even better than an “A” team?

Such a thing actually happened in the 20th century. I am talking about the Manhattan Project (this project created the first nuclear bombs). Despite having the best scientists of the time (and arguably one of the all time best), people like Albert Einstein, Enrico Fermi, J. Robert Oppenheimer, and despite having the best motivation (develop the atomic bomb before the enemy or else the war could have been lost) they needed about seven years to complete the task while spending the equivalent of $25.8 billion and employing more than 130,000 people.

The sad truth is that complicated things take time. And the web browsers and the standards have long passed the point of becoming something that can be called uncomplicated.

In the past two years I have been fortunate to work close with a team at Adobe that is involved in  writing CSS proposals and implementing those proposals in WebKit. I’ve seen ideas moving from inception to hacks/prototypes, and finally to proposals. You know things like CSS Regions, CSS Exclusions, or CSS Custom Filters. And I’ve seen how things that seem to be simple in isolation become complex when considering the whole. Basically, if you add something new to CSS you have to make sure that it will play nicely with the rest of the CSS features.

Another thing you have to take into consideration is to make sure you have throroughly thought though the security implications of a new feature. The Custom Filter spec was on hold at some point this year because there was a possibility (although only theoretical) that a pixel shader could be used to find what links where visited.

For browsers vendors a security issue is also something that can crash the browser. A poor implementation of a complex thing does crash the browser. No one wants this to happen at least not to his browser :D

If it sounds like there is nothing you can do to speed up this process then keep reading for some ideas :). I think that the people who use these standards in their daily jobs web developers and web designers can actually help. And from my point of view these are things you can do:

  1. Make sure you follow the new standards that make sense to you (help your projects/clients). In the unicorn’s country you’d follow all the standards. In the real world this is not going to work thus focus on what you’ve decided that it is important to you.
  2. Create examples that use these standards and make sure you share them (blog posts, conferences, etc). This is hugely important as it helps to validate a proposal. If more people find that spec useful and capable of solving problems then there is a greater chance that that spec is spot on.
  3. Make sure you are vocal about your support for your favorite new specs. One good example of being vocal is Mr. Stephen Hay aka Captain Flexbox. Let the people who are working on the proposal know what you’ve built and ask people involved in the standards what they think about these specs. These days if you go to a web conference at least here in Europe you could easily bump into people from W3C, Chrome, Mozilla, Opera, RIM, Nokia and so forth.

Of course I may be completely wrong here. And maybe these are not the reasons for why it   takes time to get new standards supported in browsers. If you have a different opinion I’d love to hear it.

PS. Although I work for Adobe, this post represents my personal opinion and not my employer’s.

Adobe Translation Center is live

My friends from the community translation team at Adobe have finally released their Adobe Translation Center for the rest of the world today. I am happy for them and I think it is something you will love too, especially if there are Adobe products that are not available in your language.

So why is Adobe Translation Center important to you? Or at least should be? :D

This service allows you to give us feedback for the language used in our products. Let’s say you are a user of Photoshop in French like Monsieur Michael Chaize. And for some reason you find some labels or menu entries that are not the most fortunate French translations. Using Adobe Translation Center you can give us this feedback and together we can fix this issue.

Or maybe you are borg and you would really want to be able to have Adobe Illustrator translated to your language. So what can you do? Simple, just use Adobe Translation Center to start translating the product together with other happy bogs fellows.

In the end this platform is not something like a forum but a front-end to generate localization files for Adobe products powered by the community. Here is the a blog post that talks about this with more details.

Happy translation!

Say hello to WebPlatform.org AKA Web Platform Docs

Without any further ado please say hello to your new best friend when it comes to reading documentation about web: WebPlatform.org. Do you feel a little bit perplexed? Not sure if I am serious or just joking? Ask no more because I am dead serious :)

So here is the deal: Adobe, Apple, Facebook, Google, HP, Microsoft, Mozilla, Nokia, Opera, and the W3C have worked together to create a single point of reference for all sorts of documentation related to the web. The whole project is set as a Wiki because we need everyone to be a part of this: sometimes you only search for some API and sometimes you’ve spent a great deal of time figuring out how to use a new API and you are ready to share this with the world.

Here is a video that briefly introduces this project:

Remember: a single place for all web resources a web developer/designer needs and a resource that you can edit and enhance.

For more information check this post or the W3C press release, and make sure you go to WebPlatform.org.

We need more than better tools

This is a post about something that I’ve been thinking about a lot lately: What do we need as web professionals in order to become more efficient and, hopefully, happier when coding web sites or web apps?

The first thing you may hear as an answer to this question is “better tools”. While this answer can be backed up with lots of data I don’t think that this is the right answer. I started doing web sites in the late 90′ and back then Homesite from Allaire was one of the best HTML editors and my favorite tool. Soon after heavier tools have emerged. Almost fifteen years later we have pretty much the same tools: light-weight tools (vi, Sublime, and so forth) and complete IDEs (like Eclipse) with some others in between.

So you have to have lots of imagination to invent a new tool that doesn’t fit in the existing categories. If the answer is not a better tool than what is?

Well, let’s step back for a second and look at what the current web development process looks like. And to simplify a bit let’s consider these two types of developers (it is a stretch  but stay with me):

  1. Newbies. People who just started modern web development. Contrary to what you may think these people are not necessary newbies in programming in general – they can be Java enterprise developers for example. What they have in common is that they have to find their way through a “million things” (tools, best practices, frameworks, libraries, browser inconsistencies, different JavaScript versions, different CSS versions, and so forth) all in the name of building a “simple” modern web site.
    It is amazing that the complexity involved in building a web page that runs across devices and browsers can beat the complexity required for building the back end for a website or an iOS app.
  2. Veterans. These people know the best practices, they know the “cool” frameworks, they’ve found “the best tools”. And yet they are not necessarily without worries. Updating the JavaScript libraries and the dependencies is not that trivial for a live product, nor is making sure that each time you change something you properly test it (unit testing, function testing). At the end of the day, they spend too many cycles on things that are not “fun”.

As you can see the challenges one faces when doing web development are not only in the realm that a tool typically covers. I’ve seen at least two examples that showed me that the solution is not that far fetched and there is life after all :).

The first one is, hold your breath :D, PhoneGap Build. Trust me, I am not mentioning this because I work for Adobe. Everyone who does mobile developing using the native tools/frameworks for multiple platforms knows that is not a walk in a park. You need a Mac for iOS development/packaging, a Windows machine for Windows Phone, and different IDEs and so forth. PhoneGap Build handles this complexity and let’s you focus on coding the app using open web technologies. The packaging is done in the cloud.

The second one is even more interesting. This comes from Paul Irish’s presentation at Google I/O 2012. If you haven’t seen it, please do yourself a good deed and do it. Now. Pay attention to project “Yeoman” (this is presented in the second part of the presentation). The main idea behind this is that you should go from idea to prototype in less than 10 minutes. Under the hood it uses a bunch of tools/libraries (Compass, RequireJS, Jasminte, PhantomJS, etc) and tries to minimize the friction that you typically experience when using them by making the installation in a new site seamless and so on.

In conclusion I don’t think that it is about a better tool. It is about a better process and workflow that may integrate a number of tools, services, and scripts. And this “thing” should take care of as many things as possible automatically. The bright side is that there are signs that this is possible. It is just a matter of time as more and more bright people change their focus from building libraries and frameworks for doing X or Y to building better working environment for general web development.

Making my blog mobile friendly

Yesterday night I finally managed to finish something I’ve been planning to do for a while: change my WordrPress based blog theme to one that adheres to the “responsive design” philosophy.

After doing this I figured that it would be (potentially) helpful to write a post and urge others to make their blogs mobile friendly. Especially if you are running a WordPress based blog, it is not that difficult.

Why in the name of all HTML tags would you want to make your blog mobile friendly?

Well the answer is quite simple: because more and more people end up doing serious reading on their mobile devices. If you’ve been attending mobile conferences lately, you know that the days when we thought people tended not to use their mobile devices for anything serious are gone. People not only do complex task on their phones but they read too. And when the mobile phone is the only device at hand and you are stuck in some place without a computer you want to and you do spend time with your phone.

Now, a couple of years ago a colleague told me that I should take good care of my mobile users and add support for a mobile theme. This made me instantly anxious as (for no particular reason) I pretty much hated the mobile.somesite.com version of all sites. It always felt alien, remote, and a little bit fake.

Nevertheless I swallowed it and I added a mobile pack theme to my blog. Then I erased this from my mind. Last year, while reading a blog post on my phone I noticed that the blog looked almost the same as the desktop version and it was a WordPress blog. So, you can understand why I felt like yelling “Eureka!” as loud as possible.

DIY is something I like a lot but not when it comes to building software. I’ve done my share of libraries, frameworks, and code generators so I don’t feel that every now and then that I should re-invent the wheel just to prove that I exist.

This is why I was so happy to have a bunch of themes to choose from. Twenty Eleven, Responsive, and Blaskan made it on my short list. In the end I decided to go with Twenty Eleven.

Are we there yet? Not yet my son!

Once I was happy with my choice (the theme to go with) I started to tweak my blog a little bit more. Some of the changes were design related, others content related.

From a design point of view I wanted to change the font size. I felt that the default size, even on a desktop was a bit too small. As someone who has to wear glasses and uses  Cmd + “+” quite frequently to bump up the font size in the browser or mail client I thought that it would be something nice to have. So in the stylesheet I changed the font size from 100% to 105%. Why 105%? Well I tested various values on a bunch of devices and desktops and 105% worked the best.

Bumping up the text size for paragraphs and friends left me with the text size of the headers a bit to small. This was a bit strange because I was expecting to find another percentage based value. Instead it was hardcoded to 26 pixels. After some trial and error I ended up with 170% as the best value.

The final touch was to change to the maximum width of the site. The default option was 1000 pixels which I think is too small for today’s computers. I changed this to 1120 pixels and I was done.

That was the design. What about the content? From a content point of view I’ve done two things. First, I added some more widgets on the sidebar. By default the theme has two widgets: archives and site login. I wanted to have categories, blog roll, upcoming events, and about me.

The second thing I wanted to change was to take out some of the content in order to speed up loading and rendering. My eyes were firmly set on the social sharing features. I had a bunch of plugins for sharing the posts on Twitter, Facebook, and Google Plus. These plugins load a bunch of resources (images, CSS, scripts), which adds time to both loading and rendering. Especially on slower mobile connections this was painfully slow.

Now, making your blog content easier to share is a good thing isn’t it? It looks like online marketing 101. Well, I don’t think that this is always true. If your blog is a technical one and you write good content then you should trust that your users are perfectly capable of copying and pasting the blog post URL into a Twitter message window or Facebook page.


In conclusion, don’t be as lazy as I was in regard to making your blog mobile friendly in a responsive design way. Especially if you use the WordPress platform, things are not that complicated.

And while doing this take a look at your current content and decide if you really need all those little plugins that are adding weight and rendering time to your page.