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.

Later I learned about Mr. Ford and his innovation (assembly line) and nodded wisely – I knew first-hand what it was all about.

During my software engineering time I learned another lesson about productivity: if you use the right tools (IDEs, programming languages, libraries, or frameworks) the same person can achieve more with the same input (at least once she or he understands the new tool). Simple example: suppose you have to plot data in some nice looking charts. There are two ways: write the code from scratch or use one of the countless libraries available for your programming language.

So far so good and probably nothing to argue against. So where issues start to creep out? On short: when you try to implement a process at the company level (or even team’s level) process that you hope to yields better results then what you already get (more creativity, faster time to market, better software).

I’ve seen teams doing great using some kind of waterfall approach and then switching to Scrum and doing also great (hard to tell if it was better or not). And the opposite: teams struggling in waterfall setups weren’t necessary better when switching to agile.

Trying to implement agile methods (like Lean Startup) at big companies is a painful process to observe and probably even more painful if you are part of the teams. 

So why’s that? I think the main problem has to do with the homogeneity (or lack of) at big companies or big teams. In theory you take the new process and lay down on the company the same way you’d lay a blanket on bed: it will fit neatly and cover everything evenly. 


The reality is that the blanket has to cover not a flat surface but a rough terrain that has lots of mountains, valleys, hills, and plains. Executives and senior management are the mountains, while the engineering teams are the hills or plains. And the valleys are the disconnect between the executive management and the engineering teams. Each party will take only what it makes sense and discard the rest of it. The end result hardly can be the one you hoped for.


Many of these cool processes were designed by startups. At startups the homogeneity is almost perfect – founders/executives are core part of the engineering team. All people pull in the same direction and have the same picture of the environment.

So why try in the first place? I think the assembly line from manufacturing industry and the developer tools are part of the problem – we think that surely it can be as easily to change the dynamic of a company or teams using the process X or Y.

In my humble opinion it is less about the process and probably 90% about having the right people with the right attitude in your team or company. Starting with the executives and finishing with the engineering teams. And because it is always harder to recruit and keep the right people we go out and hunt for the hottest methodology and try to make it fit at our company.

If you think I am wrong then explain me why a company like Samsung can’t beat a company like Apple when it comes to mobile devices? Do you really think that it is the process they are using or the people who work at these two companies?

Credits: “Bolt-with-nut” by Pavel Krok – Own work. Licensed under CC BY-SA 2.5 via Wikimedia Commons – http://commons.wikimedia.org/wiki/File:Bolt-with-nut.jpg#/media/File:Bolt-with-nut.jpg

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.

As an evangelist I got into a position where I had to understand not only the technical bits but also customers, marketing, sales and business, social media, public speaking, and politics to name just the obvious. I got to meet and learn from colleagues and bosses, customers, and fellow speakers. I got to travel around the world and make new friends. Some lessons were about technology and doing your job, some were more about being a better person and understanding the world we are all sharing.

For all of this I am incredibly thankful.

Red Pill

But every great chapter has an end and all we can hope is that the next chapter will be as good or maybe even better. For the past year I’ve been thinking what’s next for me after the evangelism. Out of all the things I could have tried, the product management was looking the most challenging and rewarding at the same time. Working and spending time with some great product managers (Andrew, Jacob, Adam, Thibault, Ryan) helped me to shake off any second thoughts.

Once again I was fortunate enough to have a choice: PM with Adobe or with Bitdefender . Bitdefender just felt right, the team, the products, the challenges ahead. I knew some of the people over there and had great respect for them. So I took the red pill. One month later I can already say that I have the time of my life.

We think a lot about products, technologies, and companies. But at the end of the day it is always about you. What does it make you tick and makes you to keep pushing forward, keep walking? Do you want to take the blue pill or red pill?

PS. I will continue to blog here. It will be less on technology and more on product management.

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.

About Frameworks

I wanted to steam out of my system for a while. So here I go. As I’ve been talking to people about web development I noticed that lots of people are relying on frameworks to do their work. While there is nothing bad (nor good for that matter) in using a framework I think that it is important to know and understand the trade offs. Because there are.

Now, every popular technology has lots of frameworks that make programmer’s life easier. If you look at web development, the client-side part of the business, you know there are literally hundreds of frameworks. From the mighty jQuery to all the other small or big UI frameworks, highly specialized frameworks (like those for data visualization), and so forth. There are “frameworks” who help you overcome some of the pitfalls and verbosity of JavaScript (see CoffeeScript).

And this is a really good thing. As, at the most basic level a framework helps you to be more productive by not reinventing the wheel.

However, every time you pick up a particular framework (or most likely a combination of frameworks when talking about front-end development for web) you limit yourself. And this is exactly where the things start to fall apart.

Why am I saying this? As you grow used to some particular frameworks when you start a new project or maybe you add something to an existing one you tend to make the problem you want to solve fit the frameworks you chose. This means that you started with a problem you have to solve and (in theory) an infinite number of methods to tackle that problem. Because you insert the frameworks in these equation, you tend to limit your self a priori to a limited number of solutions (those provided by the framework). And this is how you tend to change the initial problem you wanted to solve, in order to be able to fit the framework. And this is bad, obviously.

In a perfect world you’d know all the frameworks and  CSS/JavaScript/HTML so you can make the best choice for the task you have to complete. In the real world you end up using more and more the frameworks you know and to rely less and less on “pure” CSS/JS/HTML solutions. And this can bite you pretty hard especially when you move from web desktop projects to mobile web projects. Due to the lack of performance on these mobile devices, the browsers tend to be much slower. Thus the frameworks can perform poorly or even not to work at all (see SVG based data visualization tools and Android devices).

So what am I saying here? In a nutshell I advocate to spend at least the same time for polishing your HTML/JS/CSS skills as the one you spend learning and using frameworks. Because, remember, any framework introduces a new abstracting layer between you and the platform you are writing code for.

In practice, at least what I’ve seen is that most senior developers know how to find the balance between relying heavy on frameworks or writing their own libraries/frameworks perfectly suited for the project at hand. Junior developers tend to go all the way either for reinventing the wheel or using the same framework for everything.