The Behance Network uses a number of nifty little binary files to create some of the useful services that our platform offers. Two of them in particular are wkhtmltoimage and wkhtmltopdf ( both 64-bit static binary files ). These two files convert HTML to either a PDF or a thumbnail image of a full webpage and dumps the output. These tools work flawlessly on both our sandbox environments ( Ubuntu 11.04 ) and our production image servers ( CentOS 5.5 ). When we try to execute these files on one of our new Imageservice cloud servers ( CentOS 5.4 ), we receive the dreaded:

A segmentation fault (often shortened to segfault) or bus error is generally an attempt to access memory that the CPU cannot physically address. It occurs when the hardware notifies a Unix-like operating system about a memory access violation. The OS kernel then sends a signal to the process which caused the exception. By default, the process receiving the signal dumps core and terminates.

One of the biggest differences between folks on the business side and the engineering side is the way they view certain problems. While having tons of data is seen as a serious issue that requires tons of management by developers, business folks tend to see it as a boon, as a way to build a business. Since problems like this only show up after bit of success, these can easily be dubbed luxury problems. A lot of the time, these luxury problems manifest themselves as scaling issues, mostly in the database layer.

As the Behance Network has grown and traffic increased, more and more challenges appeared. We’ve taken these problems as a sign that things are growing. Our MySQL databases are a great example. No matter how poorly the database was designed, when it was brand new and empty, it performed great. Especially in the incubation stage, when the Behance Network saw very few visitors, and only had a little bit of data to contend with.

Once we put some stress on the server, things fell apart quickly. Looking back, this was a great problem to have, considering the alternative was to never have problems because no one ever puts data into your app. It was also an opportunity for our team to take a look at what happens under load, and find ways to fix it. As we’ve found out, this isn’t just a simple opportunity, but a never ending cycle of struggling to keep up with demand. I hear this is what some business folks call a “viable business model.”

Without problems stemming from growth, there are few opportunities for a team to learn the best way to solve tough problems. These moments should be looked forward to, not dreaded. Notes, knowledge, processes and data the comes from resolving tough problems should be regarded as the most valuable property a company has.

It’s been said a million times that programmers and designers just don’t get along. Just do a Google search and you’ll find plenty of articles attacking the subject from different angles. My favorite reasoning in one article I read was that we can’t get along because one group is right-brained and the other is left-brained. This all seems silly to me, and I don’t think designers and programmers need to clash nearly as often as they do.

There was a SXSW conversation a couple years back about this topic, and our Chief Designer, Matias Corea, said it felt like a therapy session in there. It shouldn’t have to be that way. I believe developers and designers can and must get along to make the best product.