Sometimes revolutions happen quietly. Ideas percolate for a year or so, turning into concepts and then some kind of magic happens which propels the idea into a full-blown way of working which changes a process for ever. After all, the only way to end up with a predetermined future is to try and invent it yourself.

This is what, Giacomo ‘Peldi’ (as in “Pel di carota”, Italian for “Carrot Top”) Guilizzoni decided to do when he moved to the US from his native Italy in 2001.

He had a 5-year plan: learn as much as he could about how to make software from corporate America, then move back to Italy to start and build a business.

After six years at Macromedia and then Adobe, a number of factors, including a nagging quest to develop simple wireframing software because he was unable to find anything he liked, stimulated his sense of adventure to begin a start-up in California.

Peldi knew he was onto a winner when during the development he showed a few people what would become Balsamiq Mockups. Their chorus of ‘I need this’ made him confident enough to go into business as a sole trader.

‘I wanted to do it all on my own,’ he has said, ‘to see all that it took to go from idea to software company to product – programming, pricing, marketing, legal, support, all that good stuff. That’s why I chose a small enough tool that I could build myself, funded with my savings.’

When it launched in 2008, Balsamiq experienced an impressive early growth. In 2011, in its first three years of business, the company made over $9,000,000 in total sales and is still gathering rave reviews.

RM:

Peldi, before we talk about Balsamiq’s operating platform, I’d like to ask you about the business. How did the idea behind the company evolve? You were self-funding at the start and refused to take outside investment. Was that a clear strategy to starting the business, that you would have 100 per cent ownership from day one?

PG:

First of all I’d like to thank you for interviewing me. I must admit I’m a little intimidated, I’m not sure I’m worthy of being on Simple Talk as Geek of the Week!

I would say I’m a bit of an accidental entrepreneur. Owning my own company or “being my own boss” was not something that I dreamed of as a child or anything like that. I was very happy climbing the corporate ladder at Macromedia / Adobe for 6 years, surrounded by brilliant people and free to learn and take risks in a very sheltered environment.

The decision to leave to start my own company came for a number of reasons, some professional and some personal. I had reached a point in my career where I was teaching more than I was learning, which is always an uncomfortable feeling for me since I always try to be the dumbest in the room. My wife and I were also waiting for a good excuse to move our family to Italy, where I’m originally from. As for the idea behind Mockups, it was something I needed and something I’m very passionate about, so I decided to give it a shot.

Regarding not taking outside investment; it seemed like the most natural option for me. I’ve never had any debt, and a small wireframing tool seemed to be small enough for me to self-¬âfund with my savings. Not having outside investors also meant being able to set my own schedule, which was important to me as I didn’t know how long I was going to need in order to learn everything I needed to know to successfully build, launch, sell and support a piece of software.

RM:

Have you had investors knocking at your door, offering you money? What about companies wanting to buy you? Have you had any approaches?

PG:

Yes. I get calls from VCs at least once a week, and politely turn them down. We get plenty of funding from our customers.

As for acquisition offers, we’ve had a few, some more serious than others. It’s flattering and makes my head spin, but we’re not interested. We are happy to be independent and build a longâlasting business on our own.

RM:

Balsamiq made over made over $4.5 million in the first thirty months of business. When did it seem to you that you were onto something huge?

PG:

I knew I was doing something right pretty early on, where I noticed that Mockups had become my favorite way to create wireframes. I used Mockups to wireframe Mockups itself from very early on. Also during my friends-and-family beta I saw that people I respected became hooked on the tool, and all predicted it was going to be successful. I sold my first license four days before my official launch: someone had found my website via Google, even before I had announced it to the world.

Basically I’ve been blessed with a crazy successful ride from day one: for the first 3 years it felt like I was on a rocket, trying to hang on with my nails and trying to steer it by kicking it on one side or the other. It’s been a wild ride for sure.

RM:

Are there things that if someone had sat you down at the beginning of the business and told you ‘you need to know X, Y and Z,’ that your life would have been much easier?

PG:

Things have gone really well since the beginning. The way I explain it to myself is that I had put in my time before deciding to make the jump. I have been programming since I was 12 years old, I have been making commercial software since high-school, I have read dozens of business and software books, and I have tried to soak up as much knowledge as possible from people smarter than me for many years. With Balsamiq, it sort of all came together.

RM:

Why did you choose Adobe AIR as a platform with which to develop Balsamiq mockups?

PG:

Programming in Adobe Flex (which exports both to the Flash Player and Air) is what I knew best, it was my primary job when working at Macromedia / Adobe.

I don’t regret that decision at all, Air is a great platform for creating rich experiences such as a drawing tool like Mockups, and the cross-¬âplatform compatibility between web and Windows, Mac and Linux meant that my market was as big as it could have been from day one, with near-zero effort.

It’s fashionable to criticize Flash and Air these days, but the reality is that for certain kinds of rich, graphic-intensive, cross-platform applications, it’s still the only serious option.

RM:

Are there some aspects to Adobe AIR which you just don’t enjoy using? Will you continue to use it and have any of the alternative platforms provided any interesting surprises?

PG:

Overall, we’re very happy with Air. Ninety-nine percent of our customers like it as well, and the fact that we’re not a native application hasn’t hurt our bottom-line at all.

That said, we are perfectionists, and we agree that Air applications have that “uncanny valley” feeling of not being a native application. The way the cursor doesn’t blink properly, or how scrollbars don’t feel native.

We don’t have any current plans to switch to a different platform. A full rewrite is suicide for a startup, and like I said, our customers don’t care right now. Plus, I don’t really see an alternative right now either, HTML5 doesn’t even have full-screen support yet, let alone a good desktop installation experience or serious IDEs for JS development.

We are using HTML5/jQuery extensively on myBalsamiq, our web app, and we’re developing a native iOS version of Mockups. We’re doing this for two reasons: these technologies provide the best user experience for our customers for the contexts we’re using them for, and to dip our toes in other emerging technologies, in case we need to switch one day.

RM:

Do you want to extend Balsamiq to do more generalised drawing work?

PG:

No. I hate bloatware. Mockups is designed to do one thing and one thing only.

RM:

How do you design software? Do you write mocks in the test-sense first so you can test it as you go?

PG:

We describe our process in our Manifesto.

We split the work in chunks as small as we can possibly make them, then we wireframe the key screens. We post those wireframes on our forums to get the extremely valuable feedback from our community, and we incorporate the feedback into the wireframes.

Then we write a list of stories that defines the feature, and write the unit tests and the code for those stories as fast as possible, just enough to be able to play with it.

We use the feature in context for a few days, we post it on our pre-release page for others to play with as well, and then we take all that feedback and incorporate it in a new round of wireframes. Then we code those, write more unit and integration tests, and release it all.

Often what we release is not the whole feature, but a v.1 subset that’s already useful on its own but not quite up to the initial vision yet. So we continue working on the feature and release it, a little useful chunk at the time.

I don’t know if this is considered agile or scrum or what-have-you, we don’t like labels so much. It’s what works for us.

RM:

That sounds pretty much like a UNIX philosophy – a program should do what it’s supposed to do and nothing else. Has there been anything that you’ve found difficult to work into the Mockups model?

PG:

Some features didn’t come out so well, they reflect how little I wanted to add them to the product. To share assets between projects in Mockups for Desktop, for instance, you have to edit this impossible-to-find configuration file using a hard-to-grok XML syntax. Basically the feature screams: “are you sure you want to do this?” We’ll clean it all up in the future, but if something doesn’t really fit with my original vision, it shows.

RM:

Do you pair-program, where you sit down at a computer and produce code with another member of the team?

PG:

We do it sometimes, but not regularly. We do it for training and for those times when one of us gets stuck on a tough problem.

RM:

So do you write the documentation before, or at least while the code is being written. Is that how you usually do it? Or does it depend on the difficulty of the problem?

PG:

Our internal documentation consists of the wireframes of the feature and the list of Pivotal Tracker stories about the feature. We refer to those as we develop the feature and the tests for it.

As for the user-facing documentation, we post that online as soon as we have something ready for testing, with a disclaimer that says “this is only available in pre-release right now”. This way we get feedback on the documentation as well as the feature itself before we officially ship it.

RM:

You’ve got some competition in the marketplace but no company has managed to replicate how Mockups works. Why do you think that is given you’ve taken a good chunk of their market away from them?

PG:

I don’t think we took a chunk of the market from our direct competitors, but rather from tools that cost more and do more things, but that people were only using to do wireframes.

As for direct competition, I decided from day one that I wanted to compete on usability and customer service. In other words, if someone builds a tool that’s easier and more fun to use and they support their customers better than we do, they deserve to win.

Neither of these things is easy to replicate: you need the right team and it needs to be distributed globally.

RM:

Will Balsamiq be offering real-time collaboration or are you sticking with change detection?

PG:

We’re definitely going to include real-time collaboration, starting from the myBalsamiq editor. Marco’s working on it right now! As with everything else we do, we’ll do it gradually.

RM:

You say on your website that life is too short for bad software. I interviewed Niklaus Wirth recently and he said that programming languages can not only be used to design beautiful programs with much less effort but also to hide incompetence underneath an impressive coating of glamour and frills. Has the modern trend of marketing software which is full of bugs to get a quick return become counterproductive, has quality suffered?

PG:

I’m not sure that this is a new phenomenon. There’s always been good software and bad software. The difference maybe is that via the different app stores, bad software is easier to distribute to wider audiences.

It’s also true that modern frameworks make it easier for inexperienced people to knock something out and call it an app. The good news is that people aren’t shy with their reviews, so the bad stuff doesn’t last near the top for too long…

RM:

Are there certain algorithms that strike you as beautiful in a Haiku type way? What is it that makes a program beautiful?

PG:

I’m smiling right now because I hadn’t heard the word “algorithms” in years. Our software is extremely simple. The hardest parts of it are a few recursive calls here and there. I am constantly amazed at how little of the theoretical part of our computer science education we end up using, even as a commercial software vendor.

I’m glad I learned it all and I’m sure it influences our decisions, but in general, what you need is a lot of experience under your belt, not some fancy algorithm.

What makes a program beautiful to me? The fact that it works. It does its job and performs well, with as little code as possible.

RM:

Picking up on computer science for a moment. Academic computer science is very mathematical. How important do you think it is for working programmers to be able to understand, for example, the math in Knuth? Rather than something along the lines of ‘I need to sort things; I’m going to flip through Knuth and skip to where he says, ‘This is the best Algorithm and implement that?’

PG:

I do think it’s important to go through the exercise of really understanding the thought processes behind those algorithms. You might not need to use that same exact process again (just call your built-¬âin sort function instead), but it will teach you how to attack new problems when you run into them.

RM:

At the other end of the spectrum from code beauty, software is full of painful sores that we can’t get rid off. Is there a way to avoid these problems? Or is it just the nature of evolutionary design?

PG:

Writing good, scalable code takes a lot of practice. I rewrote the core classes of Mockups from scratch 3 times when I first started. You need to build code that has room to grow, a scaffolding of sorts. You have some pillars, and you add to them over time. Once in a while you have to add a new pillar, but that’s a good sign, it means your users are using the software and forcing you to make it better.

There will always be areas of the code that are uglier than others, but if you pay attention not to create them and invest the time in refactoring them regularly (having a solid set of automated tests really helps here), they don’t have to be a suffocating burden.

RM:

Are there particular skills that you feel made you a good programmer? Did you have any important mentors?

PG:

In 2003, I had been a programmer at Macromedia for 2 years. When it came time for my yearly performance review, my boss at the time – Jon Gay, inventor of Flash – told me that I was doing everything right, but that I just needed to do a lot more of it, I needed to get more releases under my belt. I remember feeling a bit disappointed by that feedback: how could I possibly act on it on that day?

Looking back, I know he was right. It wasn’t until 4 years later that I felt like I was finally good at programming, a full 20 years after I first started. Putting in the famous 10,000 hours is a hugely important part of getting good at it. Of course having a passion and a predisposition for it didn’t hurt.

Other than that, one thing that really helps me is to try and surround myself with people who are better than me as much as possible. It was my bosses and colleagues at Macromedia and Adobe, and now it’s my employees.

Peldi photo copyright Matt Snow.