Welcome to Cykod. We are a fully-integrated, self-funded web-development startup located in Boston, MA.

Cykod Web Development and Consulting Blog

Are all small web consultants doomed? (Details at 11)

As with any small business where every individual ends up performing many different tasks, finding time to do the actual work your company does is sometimes more difficult than it should be.

This has led me (and I imagine many other small business owners) to become somewhat obsessed with personal efficiency - figuring out how to extract the most out of each day, while keeping ourselves mostly sane, fit and fed.

Developing a complicated piece of software make the issue even more severe as I've found that my level of productivity is directly related to the amount of mental inertia I have on the current project:

Hour 2 working on a complicated project is considerably more efficient than hour 1. Day 2 of straight interrupted work on a complicated project is a significant multiple more efficient. Day 3 approaches that magical level of efficiency that I've heard described as "the zone" - that period where everything else melts away and your hands magically emit gorgeous code haiku's - perfectly sized, efficiently abstracted pieces of DRY goodness.

Now the time it takes to get in the zone (3 days in the example above), can vary widely depending on the level of mental focus, familiarity with the development environment and the size and scope of the project. Small projects that are easier to fit your head around are likewise easier on your mental processes.

What does this have to do with small web consultants?

If your experience is anything like our own, then the graph below is probably in line with your experience:

The longer you do this, the more complicated the projects you will be taking on will be. This isn't necessarily a bad thing, as the more complicated projects are also generally more interesting both intellectually and financially.

However, unless your are an abject failure at your work and none or your previous clients ever call, the graph below will also be relevant:

Taken together, what do those two graphs mean? Firstly, that as your new work gets continually more complicated, you'll have less and less time without new interruptions. Meaning less and less time in the zone, meaning that complicated web app your could have built in 1 month of solid 'zoned-in' work will end up taking you half a year due to the constant interruptions and bug fixes for your previous work. The client won't be happy with the adjusted timeline and neither will your pocketbook.

Taken together, what do those two graphs mean? Firstly, that as your new work gets continually more complicated, you'll have less and less time without new interruptions.

This isn't meant to be a "Magic Bullet" blog post - I'm not sure what the ideal solution for this problem is - we've done a number of different things to try to mitigate this problem.

First - For significant-sized projects standardize on one platform you are happy with for the majority of your client work as early on as you can [ We picked Rails, and then Webiva ]. By building off of a standard platform your minimize the cost of the zone-destroying context switches as you move from PHP to .NET to Ruby to Java. Keep the experimentation with different languages and frameworks to smaller projects and your personal time.

Secondly - the best code you can use is the one you didn't have to write. There are lots of open source options out there for both libraries and higher-level functionality. Make sure the license fits with what your doing (and the client's expectations), otherwise be prepared to release your code to your client under a compatible license (or in the case of the AGPL - be prepared to release your code to everyone under a similar license) If it fits your needs and looks like someone else is going to be actively maintaining it - it's a great alternative to writing a bunch of code yourself.

Thirdly - adjust your schedule to maximize the hours where you can work without interruption. We've taken to getting about around 5:00 AM and not responding to client emails until 9:30. With the right morning schedule I can get a number of focused hours in before the first crisis arises.

Lastly - as soon as you are to the point where you have a little bit of cash in savings and don't have to worry about making rent and putting food on the table, get as picky as you can about the projects you take on. Make sure the client seems compatible with your style of work and that the project itself interests you. If it doesn't, your going to have a hard reigning in the mental focus to keep yourself from scouring reddit and slashdot every 5 minutes.

The above four strategies kept us going and growing to the point where now we're headed into the start up world and are focusing primarily on internal projects. We still do consulting projects, but they are primarily with our existing clients, which keeps the surprises to a minimum.  I don't know if there's a better solution other than growing the size of your staff and/or accepting a drop-off in quality or quality of life, if anyone has any ideas I've love to hear them.

Posted Friday, Aug 28 2009 05:34 AM by Pascal | Development

Software is a craft (except when it's not)

The first time I saw in detail the way a fully automatic weapon worked - using the power generated by the energy of the last round to expel the spent cartridge, re-cock the hammer and fire off another round - I was absolutely enthralled. It seemed like such an amazing combination of engineering and ingenuity that the idea that someone could "invent" something like that was incredible bordering on magical.

The truth of course is that no one person did invent everything that went into creating an automatic weapon. Mankind's need to kill things as efficiently as possible worked over time as incredibly strong market force pushing invention and innovation forward in the field. The reason that a fully automatic weapon seemed so amazing to me is that it most likely incorporated a couple dozen or more "Aha!" moments by the greatest thinkers in the field, combined with a significant amount of engineering and trial and error to get everything to work just so (and most likely more than a couple of exploded barrels). But the fact of the matter is that no amount of rote engineering would get you there. You need individuals with the right amount of knowledge and experience applying themselves to difficult problems to get innovate solutions that advance the field.

Something designed by the world's greatest "Software Architect" , providing UML diagrams that look like works of art, can still quite easily end up being a dud when it's implemented.

Because of the term "Software Engineering" - many people often assume that software development is simply the application of a set of principles and code patterns to a problem to come up with a working solution, like doing the calculations to build a road. In a nutshell, a common belief is that the smart, higher paid software architects generate some UML diagrams and then pass those off to the code monkeys to bash their fingers against the keyboard and output the necessary code. Throw in some unit and integration testing at the end and there you have it - freshly engineered software.

I'd love to say that belief and method of operating is a lie, but it's not. It's definitely possible to develop software this way and lots of company's do it. Lots of them also fail horribly   There is a reason that despite the proliferation of code generation tools and the buzz about off-shoring there is a still a very strong market for us code monkeys.

As it turns out - implementation matters, and it can matter a lot. In cases where software is going to grow, change hands and live a life of it's own after the first deployment there are significant benefits to having well written code: it's easier to understand what's happening, it's easier to change, it's easier not to completely bork some other system down the line. Something designed by the world's greatest "Software Architect" , providing UML diagrams that look like works of art, can still quite easily end up being a dud when it's implemented.

Two carpenters each building a cabinet based on the same design can end up with products of widely varying quality. While at the most basic level (sure, they both hold dishes), it's quite possible one cabinet might feel like a rock-solid heirloom piece of furniture and one that seems like it might be ready to fly apart from a cross-breeze.

Anyone who's been in the software industry for a couple years has most likely seen the same thing. One piece of custom software in the company is rock solid, it's easy to add bits to and take parts away from without worrying about the whole thing falling to pieces. Other custom software is less stable, however, and programmers try to whisper magical incantations over it in the hope that the two line change they just made won't end up frying the mainframe.

To cast a sad aspersion against the software industry - I'd bet that in down times good programmers are more likely to get laid off than bad ones simply because the bad ones have such left such a destructive wake of spaghetti code behind them that no one but them knows what to do with it. Think about that - the worse you are the better your job security. What other industry has that depressing feature?

Software developers, at least those who live, eat and breathe software development are the same - by some accounts more than an order of magnitude better than their less engaged peers.

To go back to the cabinets from a few of paragraphs previous - the reason we call finish carpentry a craft and carpenters craftsmen is because the good ones, those that have the knowledge, experience and commitment to do good work do it a heck of a lot better than those who don't. Software developers, at least those who live, eat and breathe software development are the same - by some accounts well over an order of magnitude better than their less skillful and engaged peers.

Of course on the flip side, you don't always need a craftsman - if you run a cheap chair factory the last thing you want is someone who cares too much about what's coming off of the assembly line.

The software your company is developing might be the same thing, and it might just not be worth spending the money to do it right. A couple of off-shore programmers fed with a few pages of UML diagrams might do just the trick, and that's fine. Just like IKEA is making buckets of money selling cabinets that aren't heirlooms, your company can probably do the same with some barely passable software and save a few bucks. A word of warning though - when that project is months behind schedule and looks like it might not get done because things that worked last week are no longer working, that savings might not look quite as good.

The temptation from the MBA set is to believe that all it takes is itheir great idea and a quick-and-dirty implementation by the lowest bidder and the $$$ will start rolling in. The reality is that no one gets it right the first time, and if, when it's time to implement all those small tweaks that take the great idea and turn it into a great product, your codebase is falling apart - the value of having paid for or not having paid for a solid implementation will be pretty clear.

Posted Wednesday, Aug 26 2009 08:36 AM by Pascal | Consulting, Development

Software Hazing

Having experienced both sides of the occasional hazing ritual in my lifetime, I can safely say it's not something that I enjoy terribly much.

(however, for full disclosure, my mother tells me that she and my father were once called to school and I was threatened with suspension for engaging in hazing. I believe was 6 years old and In the second grade. I don't actually remember what I did but apparently it constituted hazing)

Now the liberal-elite, gotcha mainstream media are quick discount hazing as nothing but a boys (or girls)-will-be-boys ritual directed at humiliating individuals simply for the sake of feeding the ego of perpetrators. While it can certainly sometimes fall to the level, as Dr. Cialdini discusses in his book Influence, hazing's raison d'etre is much deeper than simple cruelty. In the chapter "commitment is the key", he explains:

The Thonga tribesman with tears in his eyes, watching his 10-year-old son tremble though a night on the cold ground of the "yard of mysteries" ... these are not acts of sadism. They are acts of group survival. They function, oddly enough, to spur future society members to find the group more attractive and worthwhile. As long as it is the case that people like and believe in what they have struggled to get, these groups will continue to arrange effortful and troublesome initiation rites. The loyalty and dedication of those who emerge will increase to a great degree the chances of group cohesiveness and survival (Influence, Robert B. Cialdini, 78)

One of the quirks of human nature is that we value things based on our level of commitement. The more effort and energy we expend to achieve something,  the more we will value the result. The same goes for membership into organizations - groups that are difficult to become a member of will invariably be valued by their members more than groups that allow anyone in, even if they provide the same or similar services.

One of the quirks of human nature is that we value things based on our level of commitement. The more effort and energy we expend to achieve something,  the more we will value the result.

There is a corresponding desire, having fought tooth and nail to gain entrance into a group or community to play "gatekeeper" and ensure that anyone seeking admittance to the group has to go through the same trials that you did, otherwise your own sacrifice will have been worthless.

Software developers, I believe, can sometimes put barriers around their software for those two reasons. The question is whether we doing it for "good reasons" (because it generates a stronger commitment and devotion) or "bad reasons" (because if we had to go through it, you darn well do too), or a combination of both?

For an example of the former, take the VI editor - there is a lot that could be done to make the editor more user friendly - but something would definitely be lost regarding the exuberance of it's zealous fan base if it could be mastered in a day of puttering around (For those of you so inclined, take the word VI and replace it with Emacs and you get the same result ). I don't think that sort of exclusiveness is necessarily a bad thing as by creating a more excited user base, everyone benefits. A motivated user base that actually pushes the product and adoption of the product forward is a great thing.

For the second example, any time you ask a developer a question they know the answer to and they respond with "look at the code" - or pulling from previous personal experience - walk over to your desk with a 500 page ISO specification document and tell you to look it up - I don't think anyone is benefiting. As individuals a little bit of a helping hand getting started goes a long way towards making progress on just about any task.

A couple of years ago, having used a small open source utility I sent a note to the author asking if they needed help fixing a bug I had discovered. Their response - "sure, just send us a patch" - while perfectly valid, seemed to have some of the gatekeeper mentality. "Prove yourself, and then we'll talk." Having no knowledge of the codebase and no one to help me get started, I got discouraged after a couple of hours of debugging and used something else. No one ended up benefiting. A two line response of - "Sure, check fizzbuzz() in foobar.c" would probably have been enough.

So, one of the goals we have with launching Webiva is to try to make it a friendly piece of software to get into - whether you're a seasoned programming veteran or just a user who wants help. I'm not saying it's going to be easy as there is some significant complication innate to the software, but we'll be there to offer a helping hand for anyone interested into getting into it. And, we promise, no livestock.

Posted Monday, Aug 24 2009 07:50 AM by Pascal | Development

The Feature Conundrum

What do goverments and software development have in common? It's a hell of a lot easier to bloat than it is streamline - there's a lot less resistance adding something in than taking it away.

In the case of government, any tax or program, once instituted will only die after the deafening scream of special interests and heart wrenching testimonial articles from the local newspaper explaining how their removal is destroying some community, family, or small orphan child. [ 1, 2, 3, 4, 5 ]

In the case of Software, trying to remove a little-used feature from a later version of a piece of software is a sure invitation that there's a least one user out there for whom that feature is absolutely indispensable.

I'm a big believer in the "the best code is no code" mantra. The code that you don't write is code that you don't have to worry about maintaining

I'm a big believer in the "the best code is no code" mantra. The code that you don't write is code that you don't have to worry about maintaining, and maintenance costs - as has been beaten into developers in every programming class ever taught - will end up far exceeding the cost of writing the code initially.

Despite the danger of playing the feature game, almost every piece of commercial software does it. If this doesn't ring true to you, I cite as an example every piece of Anti-virus software I've used in the past 15 years.

The Anti-virus industry is very much a 'feature comparison' business - any feature that appeared in one of piece of software would quickly need to be copied by it's competitors so that a vendors software would hold up in the feature-by-feature comparison charts on the back of every box. Real-time scanning, check. Email scanner, check. Poorly implemented firewall, check. Auto-updater that triggers whenever you're in the middle of delivering a presentation, check.

In each case after being happy with one vendor's software I eventually ended up switching as each vendor (first McAfee, then Norton, then AVG) bloated it's product to the point where they brought my windows machine to a crawl - I often ended up just turning anti-virus protection off when trying to actually get any work done.

Software bloat is a major issue and it's one of the major reasons that there are still opportunities for lightly-featured players to come into crowded software niches (See: Basecamp ) and steal significant market share. If you can fulfill the needs of 95% of your market base by being better at a core set of features, leave that overly demanding 5% to your bloated legacy competitor.

users these days are doing less back-of-the-box shopping and instead relying on word-of-internet to tell them what to buy
Quality not quantity - users these days are doing less back-of-the-box shopping and instead relying on word-of-internet to tell them what to buy. Us software developers need to follow suit, and focus on creating better experiences for the 95%. Now, what to do about government spending and the Boston Globe's expansive human-interest-story department I have no idea.
Posted Friday, Aug 21 2009 11:23 AM by Pascal | Development

How far does a name get you?

Pretty far, but only far enough to get people's feet through the door. A new sandwich shop opened up around the corner from us called "Nick Varano's Famous Deli." Now there are a dozens of places to grab lunch in Boston's North End - most of which we haven't even tried yet after 3 years living here, but I ended up trying a sandwich at Nick Varano's yesterday, why? Because of his name.

Nick is a star of one of the most overplayed and thus slightly obnoxious local commercials that come on during or after Red Sox games. You know - the ones where the production values suddenly take a nose dive and some guy is screaming at you about his car business. Nick's commercial goes a little something like this:

Hi, I'm Nick Varano, the owner of Strega, which some people say is the best Italian Food in the City [Cut to a bunch of pictures of food which don't make me hungry and probably don't do the place justice]

That commercial has never actually made me want to go Strega, but after hearing this guy's name 50 times over the last couple months, I will say I was intrigued enough when I saw a shiny new eating establishment with his name on it to stop in for a $10 sandwich. And while this isn't meant to be a food review, I do have to say, that was a friggin' good sandwich.

Bottom line - if it weren't for the name Nick Varano, I probably would never have made it in the door. But the actual sandwich is what will most likely keep me coming back. If the sandwich was a overpriced piece of sawdust, no amount of advertising would have gotten me to go again.

I think a lot of industries forget this - the value of advertising dollars can be multiplied exponentially if what you are advertising is worth coming back to. If instead you spend millions of dollars advertising something like a bank that's about to fail (case in point WaMu's obnoxious Whoohoo! commercials) you're just throwing money down the drain.

That's why I've never understood the cell phone industry - and also why I hate the cell phone industry - they spend billions on advertising, and yet they are content to have a churn rate of 33% industrywide (2008 article)
If any of those dollars were sunk into creating a better user experience, whether from a customer service or just a service experience (let users know when they are over their minutes for example, or when there monthly bill is over double the usual, or get a call center in the US) I'm sure they could bring those numbers down substantially.

So, bottom line - advertising is enough to get people to try your service, but there better be something worthwhile otherwise people are going to shrug their shoulder's, say 'Ehh..' and move on.

Advertising is enough to get people to try your service, but there better be something worthwhile otherwise people are going to shrug their shoulder's, say 'Ehh..' and move on.The poster child for how to do it right is the site StackOverflow.com . Both Joel Spolsky and Jeff Atwood turned their name recognition into one of the newest greatest resources on the web (Die experts exchange! Die!). After building up a huge readership over years of blogging, Joel and Jeff combined forces to create a hugely popular programmer q&a (and spawned multiple other sites ).

StackOverflow was able to become a almost overnight success only because it had a user base right from the get-go. Would you bother to post or respond to questions of you were the only person there? It's creators name recognition is what got people there in the first place, but it was easy-to-use user interface that got people to register and kept people coming back.

Could you have written it in a weekend? Probably not, but let's say for the sake of argument that you could - does it matter? Do you have an audience of a couple million that you can direct to your new project so that your site's content will actually have any value? Nope.

As developers a lot of time we discount the marketing and seem to think "it we build it they will come" - but the truth of the matter is that you need to be able to both bring in an audience and keep that audience to be successful. Keeping a non-existent audience isn't enough - there are hundreds of millions of websites and hundreds of thousands of pieces of software out there - so it takes some work to get yourself noticed. On the flip side, spending your entire budget on marketing and then dropping a cow patty of a product onto the marketplace isn't taking you that far either - you need to do both. Now, I do still have indigestion from yesterday's heart-attack-on-a-plate Cubano, but now that I've tasted the goods - Nick Varano or no Nick Varano - chances are I'll be back.

 

 

 

Posted Wednesday, Aug 19 2009 05:08 AM by Pascal | Marketing

Code Rage

Waiting until you are so frustrated with a problem that you're already ready to explode is a surefire way to make you sound like a complete jerk when asking someone for help.

Take this gem from the backgroundrb mailing list back in 2008 (I removed the names but if you are really dying to find out who this guy is I'm sure google has a way):

From: **************
To: backgroundrb-devel@rubyforge.org
Subject: Re: [Backgroundrb-devel] How to obtain task progress for long-running methods


It'd be nice if you had a comprehensive tutorial covering the latest
"up to date" way to handle these things.

I'm pulling my fucking hair out trying to figure out how to upgrade
from 0.2.1 and the doc site isn't doing much but confusing me more.

....Snip...

Someone please point me in the right direction. My emails to the list
and questions on the irc channel have gone unanswered for the last
couple of days.

From: Mailing List Manager
To: ****************
Cc: backgroundrb-devel@rubyforge.org
Subject: Re: [Backgroundrb-devel] How to obtain task progress for long-running methods

You need memcache, if you want to use result storing and retrieval to
work, when worker is processing a task.

...Snip...

At last, Do not swear on mailing lists. You can do that on your blog,
irc (some channels allow, others don't). But NEVER on mailing list, i
hate that.

From: ****************
To: Mailing List Manager
Cc: backgroundrb-devel@rubyforge.org
Subject: Re: [Backgroundrb-devel] How to obtain task progress for long-running methods

Give me a fucking break. What are you the internet language police?

No wonder everyone I know is switching to workling / starling. Not
only does the BDRB documentation suck, the support on the mailing list
sucks even worse.

I'll go with Ezra's recommendation and move along. Thanks for the
non-help, dickhead.

There are plenty of ways to diminish your job prospects by posting stupid stuff to web ... but just losing it and going off in an expletive laiden email for no reason really isn't helping anyone. Now, you could say, with the Internet comes a certain feeling of anonymity - it was a gmail address - but this guy has any entire three-url signature touting his blog, his commercial project and his open source project.

Is this guy a complete jerk in general? I have no idea - we might have just caught a glimpse into his mental state on a bad day - but it sure looks like it from this exchange. He really doesn't seem like the sort of person you want to have anything to do with - on principle I'd stay far far away from any project, open source or commercial, that he's related to, he looks like he's a couple bad situations away from a spasodic meltdown.

I don't know if that's fair - he might have just gotten frustrated that no one was solving his problems for him and snapped - but regardless that exchange is now embedded in the collective memory of the internet.

Doing the same thing to a co-worker probably won't get you blogged about, but it'll definitely stick around in that person's head and chances are it'll get around the office. 


There are plenty of ways to diminish your job prospects by posting stupid stuff to web - most of those have at least some upside (Well the party was fun..., or That's the way I really feel!) but just losing it and going off in an expletive laiden email for no reason really isn't helping anyone.

Next time a project or a 3rd party library is frustrating the hell out of you, take a step back, take a deep breath, and sit on your hands for a couple of minutes before your send that incisively worded email to a whole bunch of people who are helping you out of altruism and aren't making a penny taking the time to respond to your questions.

 

Posted Monday, Aug 17 2009 03:39 AM by Pascal | Development

Know Your IP Basics

There was a recent blowup between ProgrammingPraxis.com and TheDailyWTF.com that made it near the top on reddit, and while I don't really want to get into the details, some of the comments highlight a general confusion that runs rampant in the software industry over different types of intellectual property :

Brain said
August 13, 2009 at 1:42 PM
Mhhh, I would say its a bit your own fault dude, I mean, I like your blog and I like your praxis. Calling it theft is ridiculous, and we both know that, using two non-copyrighted generic terms as a heading does not qualify as theft. If they would have willingly stolen your content after your collaboration plans collapsed it would be something different. You got the intellectual rights on your work, but not on a generic name!
My 2 cents...
Miksu said
August 13, 2009 at 10:18 AM
You want some cheese with that?

Seriously, the programming praxis is not (AFAIK) a registered trademark and you’re just going to have to suck it up. Maybe I’ll start a programmingpraxis.net domain…

What's wrong with those comments? Well they highlight the how completely off-base developers (I'm assuming the commenters are programmers given the subject matter of the two sites) can be over issues of intellectual property.

And lest you think otherwise - this is a big issue. As developers, Ideally 100% of our time is spent manipulating pieces of IP

And lest you think otherwise - this is a big issue. As developers, Ideally 100% of our time is spent manipulating pieces of IP - let's not get into whether "Property" is the right term or not - and if we're not doing it right we most likely are going to run into problems when our code comes into contact with others, be it in binary or source form.

Going back to the comments, you can't copyright a "generic term", you, in fact, can't copyright terms in general. Copyright is for creative works - and short phrases or terms generally don't apply - although there is a fair amount of debate on what amounts to a creative work. Getting exclusive use of short terms - that is what trademarks are for.

For the second comment - while Miksu is right, it's not a Registered trademark. Trademarks don't need to be registered in order to begin to take effect:

"Like copyrights, trademark property rights arise naturally, with no need for formalities. When you create an expressive work, the copyright immediately applies; when you start to use a distinctive mark, trademark rights automatically apply" (Intellectual Property and Open Source, Van Lindberg p.112)

The claim to the contrary - that all trademarks need to be registered - was made by a number of other commenters. As "Programming Praxis" is a pretty specific term  - As of this writing Google only had 6220 results, most of which mention ProgrammingPraxis.com or TheDailyWTF.com so chances are they could have a pretty solid trademark claim.

As developers we have an obligation to ourselves and our employe(rs/ees) to understand at least the basics of Intellectual property as there are a ton of significant questions that we need to know the answer to if we are going to use other peoples' IP or let others use our IP.

Some issues that come up frequently:

  1. Who owns the work that employees do in their off-hours and are those over the top we-own-everything clauses enforceable?
  2. Who owns the work that contractors do for your company (contract work is not automatically work for hire )
  3. What open-source software can you legally incorporate into your closed-source distributed software?
  4. What open-source software can you legally incorporate into your hosted closed-source software-as-a-service software? (Not the same as #3)
  5. What open-source software can you legally incorporate into your open-source software released under a different license?
  6. What pieces of media and text can you legally incorporate from the web? (Some industries don't give this a second thought )

For larger companies the lawyers handle this stuff. But some of the smaller companies I've dealt with haven't even given it a second thought. If you are just flying by the seat of your pants regarding your IP chances are there are one or more things that you aren't doing legally. That doesn't necessarily mean it's going to blow up in your face, but it certainly could and is the sort of thing that can explode at the wrong time.

There's a great (albeit somewhat dry) book out there called - Intellectual Property and Open Source: A Practical Guide to Protecting Code  that is worth taking a look at if you don't feel like you have a basic footing in IP (It covers the basics of Trademark, Copyright and Patents as well as just Open Source IP). It obviously won't make you a lawyer but at least it'll make you sound knowledgeable enough so some jerk doesn't pick your comment out and write a blog post about it.

Posted Friday, Aug 14 2009 03:22 AM by Pascal | Consulting, Development

The Problem with Weddings and Funerals

I've always thought that two of the toughest industries to work in would be the wedding or the funeral business - not, however for the reason that most people complain about - which is dealing with people under vast amounts of stress. There are lots of industries that deal with people under stress (I'd say IT has it pretty bad as well, ever tried restoring two years of someone's work from a crashed hard drive?)

No - the problem facing people in the wedding and funeral industries is that their day-to-day task is dealing with people on some of the most important days of their life. Even the slightest slip-up on a couple's wedding day will sit as a stain in their memory for the rest of their lives. Similarly, any sort of mistake during a funeral will feel like it tarnishes the memory of a loved one whom everyone attending wished to honor.

the problem facing people in the wedding and funeral industries is that their day-to-day task is dealing with people on some of the most important days of their life.

This puts a lot of stress on workers in those industries as they need to be on their game 100% of the time, every day, or things can turn in an instant. Consistently going 4 for 5 would make you a god as a baseball player but will get you fired pretty quickly as a wedding planner.

What does this have to do with Web Development? Nothing really, and no, despite what some clients seem to believe I don't think a little downtime is the same as setting the cake cart on fire. What got me thinking about this issue was an interview I saw with Google's CEO on PBS and how any implementation of cloud computing should probably be tempered with a fallback.

If Google* only loses 10 people's data because of a failure of two of their redundant systems at the same time, out of their total of 10 million users that's a pretty good rate. Except for those ten people. They are going to be pissed and there probably won't be much they can do.

your data is a good deal more important to you than it is to anyone else

Just like your wedding, your data is a good deal more important to you than it is to anyone else. So while an engineer probably won't get fired because he spilled his coffee on the SAN that was storing your info ( "it only took 2 accounts out, we have 20 million here, it's not that big of a deal right?" ) you are going to be in for a headache.

Now the reason this is different than Bill in the next cubicle accidentally watering your PC along with his desk cactus is that as the name sort of implies - you have very little recourse or ability to try to fix any problems hovering around in the cloud. For google, the amount of lost revenue will be minimal and their EULA's and their stable of lawyers are going to protect them against any bigger issues, but for you, good luck getting that data back. If it was really important, your company would probably be willing to spend a few grand to get the data back from a data forensics team, but Google will most likely not be bothered to try to recover the data - it's just going to be gone and they aren't going to give you the hard drive to try to fix.

Now, even if you have the ultimate faith that Google will never screw up, imagine that a hacker guesses a password your admin used to access a service and replaces all your data with Uv_bn_haXored.txt - good luck getting Google to fish out a backup and restore your data. A couple of backup tapes at the CTO's house would have solved that problem.

So what to do, ignore the cloud? Of course not - the overall benefits far outweigh the downsides - just remember that you need to treat your valuable data with the same amount of care whether it's on the cloud or in your server room. Don't assume that it'll be taken care of.

As with anything where the outcome is orders of magnitude more important to you than to those providing a service for you - tread carefully and choose wisely. There's a reason no one goes with "AAA Wedding Planners" even if they are listed first in the phone book and offer the second wedding free.

Update 9/21:  Just saw this story and thought it illustrated the issues with going to a commodity service on the cloud quite well:  Whoops! Students 'Going Google' Get to Read Each Other's Emails - a 3-days response time while people can read each other's emails is lauded as as  "prompt response." Would that sort of thing be acceptable in the business world? 


* And by Google I mean any large company providing commodity level cloud services for cheap ( Amazon, Sun/Oracle, Microsoft, Yahoo, etc)

Posted Wednesday, Aug 12 2009 03:27 AM by Pascal | IT

Sometimes It Does Matter

There's a tendency these days to be so completely jaded by the marketing and advertising that assails us daily that we tend to discount the ability of new things to actually, significantly improve our life. We all know the new economy sedan you buy isn't going have people in the street stopping and staring - you really think anyone cares about your new econobox? (you would think people stand slackjawed in the street from almost any car commercial), just as we all know that wearing some over-hyped scent isn't going cause you to be attacked by a hoard of attractive women, and so the tendency is to view any promised improvement with such a degree of skepticism that even when someone has something that will really improve our lives we generally ignore it as just another over-promoted piece of junk.

Then, every once in a while, we are completely flabbergasted when something actually is better. And not just slightly better, but noticeably and dramatically better.

Then, every once in a while, we are completely flabbergasted when something actually is better. And not just slightly better, but noticeably and dramatically better.

Two examples of this happened to me recently, one of which is slightly gross, so feel free to ignore the rest of this paragraph if you have a mental aversion to matted together clumps of fur. We have two very furry cats, both of which have, in the past, had a major problem with hairballs. We've fed the IAMs cat food for the entirety of the 5+ years of their adult lives. In the past couple of years, we had a noticeable increase in the number of ridiculously disgusting hairballs that we would inevitably step into first thing in the morning. A discussion with our vet led us to try a whole bunch of different options, including feeding them a tuna flavored petroleum paste (Yum!), switching to Science Diet, and brushing them more often. Nothing worked, nothing had any effect. Then one time we were going out for the evening and had run out of cat food. The dog boutique around the corner from us sold a couple of different types of higher-end cat food and because we were running late I ran over and bought a bag intending to use it only as a temporary subsitute (I'm completly aware that changing cat's food all of a sudden is not recommended, it's not something we ever do, just this one time - I promise). Over the next week, subsisting solely on a diet of the new Serengeti food, we had a total of 0 hairballs deposited on our floors. Over the next fours months, that number has stayed at zero. It's quite possibly one of the most amazing differences I have ever experienced in switching only the brand of something.*

Why did I just post an utterly pointless anecdote about our cats? Because I had another completly transformative and utterly unexpected experience recently in the realm of software development. When it comes to source control, we've used Subversion for the past year and 1/2 and I generally used CVS for the decade or so before that. The switch from CVS to SVN didn't really bring any major benefits - in fact it was such a pain to get up an running correctly under apache that I borked the repository a couple times before getting everything up and running and stable.

Git - a relative newcomer to the SCM scene is different. It's worth talking about. 

Source control in general is about as exciting as talking about your house's foundation. It's really important that it's there, but you don't bring it up at dinner - most of the time you just don't want it to fail. Git - a relative newcomer to the SCM scene although fairly entrenched ruby-wise - is different. It's worth talking about.

It's a complete game changer in terms of how I do my development and the mentality with which I attack some programming problems. Need to prototype a feature? In two seconds you have a branch in your current working copy that you can muck around with to your hearts content before reverting just as quickly. At the airport and need to create a branch or check out a previous version? Not a problem. And that's just the start.

I would just say this - if you haven't checked out one of the newer Distributed Version Control systems (DVCS), such as GIT, Mercurial or Bitkeeper, and have always looked at source control as nothing but a safety net to keep the intern from destroying the company, it's definitely worth checking out, in fact it restored my faith in humanity.

* As an unhappy aside, in the 6 months between starting this blog post and actually finishing it and posting it, Serengeti changed their formula and our cats refuse to eat it now. Requests for information from the company have been unanswered. We're back in hairball city. Inquiries to the company have gone unanswered, oh well, I'm sure there's a lesson there too...

Posted Monday, Aug 10 2009 01:12 PM by Pascal | Development

Launch Day

Launching a new site is always a serious endeavor, but it takes on some added significance when it's your own site and you are wholly responsible for the content (and typos).  

This is version 3.0 of the Cykod site - Version 1.0 was a quickly thrown together site just to get something up after Martha and I made the commitment to focus 100% on this endeavor together.  Version 2.0 came a few months later and overall we were pretty happy with it. The site was a flipbook style site that took you step by step through the details about our company and how we could help you build your website.

With our transition away from site building, however, that version had to go.  Our new site is focused less on what we can do for clients and more on our company and our views - the site's focus is now on being a pulpit from which we can start to generate a company voice and provide the community with code and resources (after a couple years we felt it was time to try to give something back to the hive mind)    
Posted Monday, Aug 10 2009 10:29 AM by Pascal | News
1 2   > >