Programmer for Hire

I recently quoted $250 in response to a client with a particular feature request.  The reply I got was asking if I could add this feature for $125, citing perfectly good and valid reasons of it not seeming like that much and a desire to keep costs done.

Here is my exact reply:

Nah,

Whenever I let a client name the price that I turn into a poor businessman indeed, and it puts me on a slippery slope of devalued self worth trying to please clients who will nickel-and-dime me and don’t really value my time.  Most damaging is that it tends to prevent me from doing the great and interesting things with my talents that I’m committed to doing in this lifetime.

Poetic waxing aside, I have a LOT of real world data that the price I charge for the value I provide is above-average fair and, relative to other vendors, sometimes ridiculously cheap.

Now then on this particular price, I’m not hosing you to make a couple extra bucks as though I were a shoe-in for the work: between transitioning mentally from other projects, sorting out your request, pre-pondering the best solution, doing the coding (which I reckon is what you figure should cost $125, and reasonably so), testing it, launching it, testing it it live, being generous with any tweaks/enhancements you might request (has it been your experience that I’m fairly generous with these?  It is my aim that it has, and please let me know if I’ve fallen short!), and the sliver of added complexity that it entails for future maintenance/trouble shooting, I stand by my estimate of 2 hours.

(A common alternative to this is quick, get-er-done style work where one change breaks something else, perhaps familiar to you! :)

That said, you might have noticed that a lot of items in the list of things above represent the overhead of doing a non-trivial amount of work of ANY size, and you would be right to think that that sort of overhead is roughly constant no matter how much substantial work is to be done.  I do my best to have evolving and tweaking a system be as fast, easy and painless as possible (and I understand I do pretty darn good at it relative to my industry), but the general rule still always holds: that we’ll both always get a better value for a our time and money the more you can batch feature and change requests together (a full day’s work in my experience is generally the tipping point).

Whatever you think for this one is totally cool by me.  If the day ever comes that you want to transition from me for any reason, be it price or whatever (or in the event that I need to move on myself) I am completely reliable to be 100% cool and helpful in facilitating that transition.  I’ll even train the next guy on the code and be available for quick questions (in the past for clients I really liked I’ve even done this training for free).  I’m committed that you NEVER have the experience that you’re stuck with me when you could do better.

Whew, that’s lot!  I didn’t mean to talk your ear off with the above, and know that I don’t mind your request at all.  Hopefully you’ve gotten some nuggets on how to get the best bang for your buck out of me.

Cheers!
John

Looking back there are a lot of things about this communication that I like.  It is a candid look at how I work with and honor my client relationships that I am happy to share publicly: it gives some insight as to how to get the best value of out me, reveals that a lock-in is NOT part of my business model, and gives the freedom to choose.  Negotiation-wise there are a lot of points made and I want to add a few more to round out the exposé of my thoughts on the matter.

My stance on not negotiating price serves both me and my clients because it keeps me honest and true to my standards.  Coupled with my willingness to facilitate anyone in transitioning to another developer, it holds me to a standard of being the best and giving the grade-A experience of working with me. If I don’t perform at the level I say I do and thereby someone can get a better value with someone else, I will lose that business and I should.  Short cut jobs with me are simply not on the table, though the option to get one somewhere else is.

Psychological factors play into it as well.  When I know I’ll be earning what I feel I’m worth for a piece of work, it’s easy and a joy to put the shine on it and go the extra mile, and my clients regularly reap the benefit of this.  By contrast, in the past when I’ve allowed myself to get beat up on price I had to fight against the devil on my shoulder telling me that just meeting the spec-doc minimums was acceptable.  I always won, but those then were the clients I eventually fired.

If nothing else, not negotiating on price forces me to work with the right clients.  For a mom-and-pop business looking to get a website online, I’m expensive.  For a million-dollar company for which custom software is an integral part, I’m cheap.  In some cases ridiculously cheap.  So if I’m getting push back on my price, it’s a sign that we’re not a good fit, and acknowledging that sooner than later is useful for both of us.

And in case you were wondering, my rate of $250 was accepted via email reply 14 minutes later.

Here’s an actual email dialog with one of my favoritest clients, identifying bits changed to honor confidentiality:

We have an idea for a SuchAndSuch iPhone app. Can you recommend a great developer?

Yep.

Mother fuckin’ me.

John

That’s what I like to hear. We’ll chat soon.

There’s something great about knowing you are completely qualified to take care of someone’s need, and communicating as much in no uncertain terms.

Classic ASP.  Microsoft’s lofty first vehicle to try and corner the market web application development tools and technologies.  It plateaued in November 2000 with it’s final release version, 3.0, and was superseded by ASP.net in January 2002.

And the world was largely happy to be done with it.

Today, 9 years later, it is by all reasonable accounts a washed up technology.  Any mention you hear of it these days in blogs or tweets is most likely from some poor soul lamenting being saddled with doing maintenance work on a legacy system.

Yet here I am, in 2011, and I find myself oddly capable of doing substantial projects in in still, and it DOESN’T feel like pulling teeth.  Between that and my profound distaste for the new-fangled ASP.net which technically I should love by now, I stopped to wonder why.

It’s true that VBScript, the language that predominantly powers ASP, is a not a great language.  And ASP, with it’s very loose and tumble style of negligible structure and convention, makes possible ridiculously sloppy form.  Its simplicity means a low barrier to entry, so there’s a lot of terrible code out there banged out by highly mediocre programmers.  So ASP as a relatively immature environment got a bad rap for some good reasons.

But that’s all part of why I love it.  Rather than a lot of rules, conventions, strict object oriented paradigms, and so forth that prevent poor programmers from doing terrible things, the wild, wild west nature of little structure makes possible defining your own.  And when you know what you’re doing with that kind of freedom you can mold the language into something that suits your style and the way you think.  While the prevailing wisdom/complaint about Classic ASP is that it takes 9 lines of code to fetch a value from the database, like so:

Dim oConn, rsUsers
Set oConn = Server.CreateObject("ADODB.Connection")
oConn.Open "DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" & Server.MapPath("DB.mdb")
Set rsUsers = Server.CreateObject("ADODB.Recordset")
rsUsers.Open "SELECT firstName FROM tblUsers WHERE ID=4", oConn,1,3
Dim firstName : firstName = rsUsers("firstName")
Set rsUsers = nothingoConn.Close()
Set oConn = nothing

I find programming remarkably tolerable with some well crafted, low level extensions to the language, which makes my work look more like this:

Dim firstName : firstName = GetDatabaseField("tblUsers", "firstName", 4)

So-called “bottom up” programming is nothing new, but I seldom see it done well in the ASP code of others.  The intersection between people using such an obscure and primitive language and people able enough to lend real ingenuity to a programming environment appears to be pretty sparse.

But that’s just it.

That’s one of the things that I credit my current overall ability of web programming to: I cut my teeth on classic ASP when it was relevant and did some substantial projects in it, and needing to “roll my own” in a sparse programming environment as opposed to waiting for some .NET package to solve a problem for me has made me intimately familiar with the low level workings of browsers, databases and so on.  Its like training at altitude: make something work in unfavorable conditions, and you can really excel everywhere else.

So here’s to you, classic ASP.  I am a better programmer for your out-of-the-box crudeness, and accordingly you haven’t been that bad to work with anyway.

It is conventional wisdom that software development is complicated.

Triply so if you stick the word “enterprise” in front of it.

By complicated (and complicated x 3 for so-called “enterprise software”) I’m referring to the whole pomp and circumstance that surrounds the actual process of banging out code to solve a problem.  Needs analyzing, requirements gathering, stakeholder interviewing, spec formalizing, story boarding, resource planning, milestone setting, time line estimating¹, wire frame designing, and prototype building are all usually part of the dance, and that’s just the front end.  On the back end you have testing, quality assuring, requirements verifying and acceptance reviewing.  (Here to forth the sum of these activities will be referred to as “the formalities”.)

With so many disparate verbs involved, conventional wisdom accordingly asserts that it takes a team of at least half a dozen highly trained and specialized professionals to pull it off.  This itself gives rise to boatloads of meetings, coordination, consensus gaining, gaps in understanding, and other communication overhead.  The formalities effectively constitute a gatekeeper from a new piece of software getting out into the real world, lest it do something that’s embarrassing, incorrect or otherwise terrible.  So you’re paying the price of all this work before a new software solution actually gets to do you any good in real world use.  (This, incidentally, is how million dollar software gets built that actual users hate.)

Does this model have a place?  Absolutely.  Some projects are sufficiently complex/important/sensitive to justify that kind of slow, methodical approach.  But many aren’t.

One of my roles during my tenure at MonsterCommerce was being in charge of development on the MonsterMarketplace, a shopping portal that aggregated product listings from several thousand of our e-commerce clients.  The building of the MMP was originally outsourced to an international resources development firm, and the [accepted] proposal for the project contained line items of many (costly) hours for the formalities.  It was a sizable system distributed over two web servers, one database server, and tied to its own [then newfangled] Google Search Appliance.  It was a great site and they did a good job.  But l don’t know that we got our money’s worth for all that supposed testing and quality assurance.

Like most sufficiently complicated systems there were bugs, hiccups, gotchas, and performance issues.  Not necessarily glaring ones, but critical none the less.  When new campaigns were launched to drive more traffic the system had to be carefully monitored due to memory leaks and other inefficiencies that would routinely crash a server.  As traffic soared beyond 100,000+ visitors a day such reactive maintenance became the norm.

When I took over maintenance of the system these problems remained for me to solve, and there was also a fresh new look to be implemented.  My calculated path of least resistance was to rewrite the entire front end myself, which was tantamount to breaking many rules of the development cycle and best practices as laid out by the outsource firm.

But it worked.

In 4 weeks I had made the new front end, polished by about a week of collaboration with the sharp-eyed spot checking of my boss.  We launched and watched the CPU usage loads under traffic, which instead of dancing between 20 and 100% utilization like before were scarcely seen above 4%.

How did that happen?  The first version of the MMP was built by a team of people, and subjected to (presumably) all kinds of formal testing and quality assurance. The version I cooked up was written just by me with only the benefit of my boss who loved to click around and see to it that all was well with his brain child.  Granted, I had the benefit of an already laid out foundation for the system, but my aim was much more to rip out and replace that foundation than to bootstrap off of it.

This was a matter of raw ability trumping best practices, both technically and management-wise.  I knew a few things about the lower levels of computer architecture that best practices were apparently oblivious to, so I could get rid of what were (to me) glaring performance problems ².  I was close enough to the vision and intended outcome of the project that I could be trusted to remain true to it.  The objective win of this was the quicker end to hemorrhaging revenues due to sporadic downtime.  The subjective win was the satisfaction my boss felt getting a major release out without all the painful fuss of formalities that plagued the first time around.  (And the win for me was the satisfaction of delivering on what was viewed as a tall and unlikely promise, plus a $7000 raise given to me the day after launch.)

What I’m curious about is how many projects are beholden to the more complex level of rigor out of a false sense that they should be (or need to be) in order to turn out.  In my experience the procedures and complexity of methodical collaboration ultimately become self-justifying: all the brain farts, delays, back-and-forth interactions, and so on make it harder for a quality developer to get actual work done.  It’s then no wonder if he/she can’t be trusted to create a solid end product without micro-management and support.  It’s worth considering that the end quality level is a wash at best, only you spent a lot more time and high salaries to cobble it all together.

Programming at the Speed of Trust

To do away with all the formalities, I assert, is the programming equivalent of Covey’s maxim “The Speed of Trust” ³.  If you have a nimble, self-directed team of developers (even a team of one) that is intimately familiar enough with the aims and needs of a project to do it right, there exists the opportunity to sidestep all of it in favor of trusting them to responsibly do their job.  The reason is that a lot of best practices are above all designed to prevent screw ups rather than promote excellence (having massive amounts of meticulous documentation and following someone elses’ protocols to the letter counts in many ways as a big C.Y.A. and little else).

Cultivating and using this approach to software development needs to be done with care.  No doubt many of our modern practices were born of reactions to past disasters, which leads me to think there’s a largely unrecognized dichotomy in approaches to software: one approach is formality as preemptive damage control, the other is running at the speed of trust.  Nimble start ups by default operate at the latter, and for it have created some of the most amazing software on shoestring budgets and in record time.  Established software development houses and large companies with full blown IT department are almost inextricably married to the former, probably because cultivating the latter doesn’t seem like a viable option with any reliability.

What, then, does it take to cultivate the latter reliably?  I think whomever cracks that code is going to have a major leg up in any business that calls for custom software.  I do know of a couple conditions that help:

• The ability to release early and release often. This is the era of cloud computing and the mobile app, so this isn’t as tall an order as it used to be⁴.  Being able to fix flaws immediately when discovered makes them much less harmful and much more palatable.
• Give developers at least a semi-regular taste of doing the job that the software is supposed to help with. This is important before, during and after development.  Before because it lets them experience exactly what they’re solving for.  During to keep true to what’s important as things progress.  After because a good developer can almost always improve software they’ve made if they’re saddled with using it.
• Break the project into individually useful chunks, and put each chunk to good use as it’s ready. Making a complex uber-system is dangerous business only if you have to finish it up to the very end before getting to experience if it sucks or not.  Structure a project so that the fruits of it are apparent sooner than later, and that the wins of the last release spur on the next one.
• Have a developer experience that it’s their baby. Whether intentional or not, nothing prompts a sense of “get ‘er done and move on to the next one” as when that is precisely how the job is set up.  This makes cutting corners much more likely.  If a developer knows he or she is on board to grow and evolve the system over time, a sense of pride and long term responsibility kicks in that can’t be beat for ensuring quality now.
• Give a developer some form of vested interest in the project’s success. This is similar to the last one, but not quite.  It’s vested interest that strongly evokes above-and-beyond effort and innovation.

I think the formalities are wholly valid, and exist for a lot of good reasons.  However like most things that are seldom questioned it is useful to question their necessity for a given project, simply because the reward is the opportunity to program at the speed of trust.

Notes:

Michael Gerber, in his treatise on entrepreneurship The E-Myth [1], makes a firm point of the dangers of working in your business when you yourself are the entrepreneur trying to run and grow it (i.e. working on your business).  He makes a compelling case that the activities of one and the other are not only completely distinct, but that they are also virtually mutually exclusive.

I completely agree.

It was a watershed moment for me when I acknowledged for myself that am far more interested in being a consultant than building and running a consultancy, even though the the latter carries with it much more prestige.  I love the kind of consulting and application development that I do, and at the same time I have no interest in building a team of me-clones to do contract consulting work.   So when it comes to me as a free agent consultant, I am much more about working in my business than on my business, and Michael Gerber is right to say that I haven’t created a business so much as a job.

The reason this is interesting at all is because of the fun twist on the in-the-business/on-the-business dichotomy that I love to play with: for an application developer who is not afraid to get his/her hands dirty with the daily roles and work of a given business, there is opportunity to make massive improvements to how that work is done.  An example will make this clear.

During my one straight job out of school at MonsterCommerce I held a number of roles and one of them was manager of the custom programming department.  We were an e-commerce company selling an already spiffy, feature-loaded shopping cart software package, but that didn’t stop loads of our customers from wanting it to do more new and novel things.  So we had a custom programming department that would take feature requests, offer quotes for the work, and execute the jobs when opted for.  About 2-4 requests would come in per day.

The system I inherited for managing these leads and projects was a drawer of a few hanging folders, my predecessor’s email in-box, and a notebook or two of notes.  The notebook system, it turns out, scaled maybe for two weeks’ worth of leads before becoming cumbersome and impossible to manage without jobs and tasks slipping through the cracks.  By this firsthand experience of working in the business I knew things could be better, and with programming skills, a desire to learn web programming (new to me then), and a dash of confidence (arrogance? ) I set out to create the solution I knew I wanted.

It was fueled by a simple vision: whenever so-and-so called, I wanted to type their name in, see their job on my screen with the complete lowdown (what they wanted, the status of the job, and even when we last talked and what was said), and be able to talk intelligibly about their project within 10 seconds as if getting it done was the only thing on my mind.  (I think a lot of visions are fueled by frustration of doing something a few times when you know it could be so much better.)

Taking inspiration (and the design aesthetic) from our own shopping cart software, I learned how to program web applications[2] and design databases, and built my dream system one weekend at a time.  It sat there, hosted humbly on the floor within the computer in my bedroom, during a time when each subsequent week a little more of my job was managed or automated by it.

After six weekends of development (and the interim six weeks of real-world use, testing, and tweaking), I was ready to show off my baby to the rest of the company.  It was well received by all the parties it touched upon: billing, sales, management, and my team of programmers, and getting adoption was quick and painless.  (The greatest honor was when the Design and SEO department heads both requested a similar system: I quickly forked off versions to suit both.  The second greatest honor was hearing that it wasn’t until 2009 until these systems were retired, fully 3 years after I left the company.)

Building something that good was made easy (almost trivial, it felt) because I was making it for me to solve my own day-to-day problems.  When my day-to-day usage revealed something that sucked I would simply fix it that night at home, and have a better system the next day.  I had bridged the creator/user gap.

Not only were the systems nice and made a manager’s job easier, it made the departments better.  Communication, coordination, follow through, professionalism and the bottom line all benefited.  It was the stuff of systematizing things that Micheal Gerber would classify as working on the business, and doing so happened because I was steeped a little while working in the business.

This is completely unconventional.  Software development talent seldom experiences the day-to-day work of the people for whom they create software for, yet what if that experience is a shortcut to making a really great system?  Though unorthodox, time spent by a developer actually doing a job for which he/she is to make a software system for may pay out overall in time saved trying to otherwise imagine, describe and communicate the software needs.   Any additional unimagined solutions/shortcuts/innovations devised by the developer-turned-worker are a pleasant bonus.  Furthermore it makes nice protection from rough or ugly spots in an application: if a developer is saddled with using his/her own creation (even if for a little while), they will be apt to smooth over and tidy up such unflattering features.

It may be a loophole to the notion that if you’re working in the business you can’t possibly working on it: insofar as software systems are concerned, at least, a person working the job who is able to design systems to make it easier is leveraging the former to help the latter.

Notes:

[1] It’s been 4 years since I read it, so please pardon any haziness in my recollection of it.

[2] This is the root of my [still persistent] fondness for Classic ASP, an arguably terrible and woefully outdated server side web language.  There’s always something special about your first.

As a programmer doing reasonably smart stuff on the web, I’m made a bit uneasy by software patents, namely because the possibility exists that I be sued for infringing upon them.

It’s not that I do anything nasty like meticulously reverse engineering the complex works of another for my own benefit, it’s that I build websites and web applications at all.  I haven’t done the boatloads of research to know precisely how much I’m infringing, but, for example, most projects I do contain some sort of menu, and this technically violates Microsoft’s patent on ‘system and method for providing and displaying a Web page having an embedded menu’, which they have already demonstrated willingness to sue another company for.  I do stuff that’s WAY more complicated than a bunch of navigation links of at the top of the screen, so I can only imagine how many other toes I’m stepping on when building systems that feature both ubiquitous and niche features.

So this characterizes the implication of patent law upon me personally.  Now then, if you scale that up to a community of hundreds of thousands of programmers similarly impacted, and throw in the rising prominence of large companies suing one another over intellectual property[1], you will then have a sense of what the fuss over software patents covers.  These are broad strokes, but they convey the gist.

Accordingly, protest has risen and lengthy debates have raged on about how to fix the “software patent problem”.  Some of it goes on and on about legal precedent, objective tests for what’s patentable, the so-called “transformation test”, and other things that apt to make the eyes of a more casual reader glaze over (mine included).

What I want to explore is if it makes sense and is defensible to take a completely different tack: the pragmatic view of the average, motivated nerd.

Let us eschew, for a while, all the legal mumbo jumbo of definitions, specificity, precedent and so forth as they are usually applied to the debate of “is X patentable?”, and see if we can’t go closer to the root concepts in an effort to sidestep the whole tangled mess.  I want to look through the lens of the reasons and motivations of why have a patent system at all.

The Essence of the Patent System

I’m not saying anything new or profound here, just summarizing to set the stage.  The patent system is a societal construct: we all, as a society, agree to abide by certain constraints (namely not infringe upon anothers patented ideas for a fixed period of time), we willingly do this in order to reap benefits as a society, and there are consequences for an individual who breaks this agreement.  (The whole thing is not unlike how we all, as a society, agree not to kill one another: we all more or less enjoy the overall benefit and are willing to give up that particular freedom, and there are consequences for an individual who breaks that agreement).

There are two really great benefits we reap as a society for having and honoring the patent system.

The first is that it encourages people to come up with new great things.  The  protection offered by patents effectively says “Hey, nice job coming up with that great new thing!  Listen, we know you put a lot of hard work and investment into doing so, and for being the one who did all that we’ll give you a window of time in which you can be the only one who gets to reap the reward of that effort, without having some copy cat come along and bootstrap off of your blood and sweat.”  An innovator, knowing that benefit lies on the other side is encouraged to invest time/effort/money up front.  The rest of society gets to enjoy the fruits of that work, and for it pays the price of allowing a temporary monopoly.

The second benefit is that it encourages disclosure of really smart work.  In this sense, the patent system effectively says “Wow, that’s something really smart that you did!  Listen, we’re thinking long term for the expansion of the fabric of human knowledge, and so we’d love to know how you did that rather than see you take those secrets to the grave, or have your heirs forever keep it under lock and key.  If you teach us how that works, we’ll get to expand as a civilization and in return we’ll make sure you have a window of time in which to benefit from your novel creation. Thanks for bettering the rest of us for the long haul.”  Again, a nice benefit to society: it speeds up the proliferation of ingenuity and all the fruits that come with it, gained at the cost of allowing a temporary monopoly.

Evaluating Patents as a Cost/Benefit Proposition

From a clear understanding of the trade-off made when a patent is given, one can view it as a transaction willingly entered into by two parties.  A patent application can be viewed as a business proposal that a society might freely choose to enter into (or politely decline) according to its interests and values, much like any business deal between two free-willed entities.

I propose that the debate no longer center around IF a given idea is patentable, but instead whether or not we WANT to grant a patent for a given idea: in other words, transform the debate to a value judgment as to whether we as a society care to pay the price of issuing a patent for the expected benefit, or would rather pass on the opportunity altogether.  When it comes to software, I believe the best choice, as a culture, is to say “thanks but no thanks” to the opportunity of issuing patents, and it takes a look into the nature of software and the nerd culture that surrounds it to see clearly why.

Nerd Culture and Innovation

I love creating cool and interesting stuff with technology, and there are 100,000 others like me.  There is no shortage of things out there in software that could be (or are) patented that a smart nerd with a little bit of gumption could look at and recreate without trouble.  And by “look at” I mean simply get the view as an end user, not trolling through source code or employing sophisticated tools of reverse engineering.

Consider, for example, Amazon’s patent on one click ordering.  When a customer is logged in, and has items in their cart, with one click they can place a completed order for those items.  Kinda nifty, but anyone who’s done e-commerce programming can immediately work out how to implement such a feature using a customer’s information on file.  I say society got a raw deal for issuing this patent: Amazon shared nothing of value with the rest of the world, and effectively earned the right squat on a generally useful idea because they ponied up some cash for lawyers and got some paperwork in first.

I would categorize ideas like that as “inevitable disclosure”: an idea that, by its very existence in user-facing software, reveals everything needed to reproduce it.  The benefit of having information about how a such an idea was implemented in software disclosed is moot: one look and (or even sometimes hearing of the idea) is all a smart nerd needs to work out the rest.  Apple’s patented “slide to unlock” widget is another example of an inevitable disclosure idea.  So are rollover images:

We smart nerds are always thinking of and building new stuff to razzle-dazzle, be it for the pure fun of it, personal pride and reputation, or a great portfolio piece by which to impress the next prospective client for a contracting gig.  And nerd culture, with its drive to innovate and share runs much deeper than small projects.  Volunteer, collaborative open source projects have created top notch, large scale innovation in all realms of software, such as full-fledged operating systems, open web standards, content management platforms, e-commerce packages, audio and video compression schemes, office productivity suites, and more.

I point this all out to demonstrate a simple observation: innovation [in software] isn’t going to dry up if the incentive of patent protections were to disappear tomorrow.  More than most (all?) industries, software grants much more space for hobbyists and enthusiasts to get involved.  The overhead to major achievement is much smaller. We are numerous, we are smart, and we are hungry to create brilliant things for both personal and altruistic reasons.

Secrets in Software

The world of software won’t turn into the wild west of pillaging and stealing ideas in the absence of software patents, because things that are genuinely hard to do and which represent painstaking work and novel innovation can be kept a secret[2].

Come to think of it, the desire to file a patent to protect a software innovation may be a sign of admittance on the part of the applicant that the idea itself will be easy to replicate by a community of smart people (or even maybe your average nerd), which is a sure good reason to be disinterested in issuing a patent at all.  “Thanks but no thanks”, I would rather we collectively say as a society: “keep it to yourself because the larger world will figure out how to execute and enjoy this idea sooner or later, and get there sooner without paying the price.”

Notes:

[1] Which breaks my heart, because as a casual observer it appears as though legal strong-arming is becoming a passable substitute for actual marketplace competitiveness.

[2] Google’s proprietary index and ranking algorithms that power their web search are presumably breathtakingly brilliant.  They constitute a large portion of the secret sauce which gives Google its competitive edge, and they reap the rewards of that not because they came first and get to squat on medium-obvious ideas, but because they do it better than your average smart person can figure out on their own.  Contrast this against Apple’s slider thingee.

Yesterday I wrote about how developers owe it to designers to respect the PSD, or in other words to implement their original designs in HTML with pixel-perfect fidelity.  Today I want to turn the tables a little and explore how a design can be particularly good or particularly bad for implementation in HTML.

A designer who knows the gotchas of HTML implementation can make it drastically easier for a developer, and usually with little compromise of their artistic liberties.  Here now is a laundry list of the themes I’ve seen come up over and over.  With a clear understanding of these, a designer can make minor alterations that lets the developer sidestep all kinds of complications and tedious work.

Non-web standard fonts – Most browsers can’t render them and must fall back to a more generic stand in.  Ok, granted this first one does impose on artistic liberties.  Unfortunately support for embedding arbitrary fonts with the super cool @font-face tag is not quite ready yet for prime time.  (That, and to embed downloadable fonts in your site one must be certain all the legal i’s are dotted and t’s are crossed with respect to licensing.)  Bits of text that need to be that special font can be sliced out of the PSD and rendered in HTML as images.  It’s a little more work, the text isn’t searchable, there’s more to download, and can’t be changed as easily, but it can be done.  For some things this is entirely appropriate: a big shiny title for the site, for example.  It’s not great for menu items if you expect lay users to be able to update them (think content management system were non-technical folks can add pages to their heart’s content and their titles are automagically added to the site’s nav menu).

Fits-like-a-glove text – Sometimes text looks so good in a PSD: it fits right in the space it’s given, nestled up as one tidy line in it’s column on the side.  So long as it doesn’t wrap, all will be well.  If the text will never change, it can be sized to fit just right in HTML.  But if the PSD portion is a mock up of,  say, the name of the most recent blog post?  There’s no telling how long a given name might get, so the design there should gracefully accommodate a lines of text of any length.  In general a designer must be aware of which text elements are fixed and which are subject to change, and beware of rigid assumptions about the bounding size when it’s the latter.

Finite background images – Similar to the above, the web, unlike traditional print media, offers up pages or blocks of text of varying and unpredictable length/size/height/width (not to mention a given user’s browser window can be much larger than designed for).  Background images need to be designed with awareness of this kind of variability:

That’s about it for the consistent gotchas that the HTML medium offers over, say, print media: they pretty much stem from how ultimate control of the end product is, in two vital ways, not in the control of the designer.  To wit: while a designer can count on whatever font they use to print successfully by a printer, on the web fonts are limited to whatever an end user’s browser supports.  And while a designer can usually perfectly typeset whatever copy is to go in a brochure, they often must design for variable and often unknown text in a web setting.

This list is shorter than it used to be.  A number of design elements that used to be headaches (or impossible) to realize in HTML have recently become rather simple with the rise of support for CSS3, namely rounded corners, drop shadows, gradient backgrounds, and image-based buttons of variable size.  It’s probably only a matter of time before the use of non-standard web fonts is perfectly acceptable, leaving only the notion of designing for variable or unknown content the only real novel constraint a designer needs to specially accommodate for.

A few months earlier, while describing the characteristics and virtues of a development team of one, I mentioned how partnership between [aesthetic] design and development is a more than worthwhile exception to that model of going solo.  Now I want to explore how this particular collaboration finds its best execution.

The essence of the developer’s job here is to translate the designers’ design (I refer to this simply as “the PSD”, PhotoShop files being de facto standard for this kind of work) into live, working, spider-able HTML.  In this relationship, assuming the designer is worth their salt, the PSD can be related to as the immutable bible, the defining guide to design for the project.

To begin, it behooves a developer greatly to trust in the importance of implementing the PSD with high, pixel-perfect fidelity.  If this is not taken seriously, a good designer will insist that imperfections in a sloppy HTML implementation be corrected, and for the developer there is to get beyond defensive notions such as “no one will notice” or “it’s just a few pixels of white space”, and resist the temptation to write off the designer as an artsy ego-maniac with nothing better to do than whine about trivial matters to create busy work.

The path to appreciating the designer’s desire for high fidelity lies in appreciating the subtle structure present in the PSD itself.  This is where a designer being worth their salt comes into play: a good one typically imbues their design with numerous uniform rules which manifest in various places and provide a certain visual continuity that makes it look good.  A padding of 8 pixels will crop up again and again, or columns of content will line up horizontally with the menu item boundaries above, or the baseline of several disparate pieces of text will line up vertically to the exact pixel.

These sorts of things are almost never accidental: they reduce the visual entropy of the layout and bring order and balance.  The casual observer probably doesn’t look close enough to recognize this effort, but it registers subconsciously as a more pleasing experience.  Likewise when banging out an HTML implementation, it’s easy for a developer to overlook the unifying visual rules and make each portion of a design look right on its own, yet completely fail to achieve the design-wide continuity.

It’s no wonder that a designer would be remiss to see the carefully crafted aspects of their design (which, incidentally, is probably the rendition that the client approved) either ignored or butchered.  Even if an implementation is arguably 95% correct, it’s that last 5% that separates clumsiness from truly professional design.  Web designers are judged more readily by their websites than their PSD files, so it adds insult to injury when a first-rate design gets a second-rate rendition.

CSS to the Rescue

I used to think that HTML was an inherently finicky medium for presentation, and that differences between browsers and platforms would make any attempt at a uniform, pixel-perfect rendition of a design futile.  It turns out that with sufficient mastery of CSS & HTML one can realize most any design (I’ll cover rules and constraints for designers to play by when I turn the tables in the second part of this series, Respecting the HTML).

A quick aside to put this into context:  There was a time before I fully grokked CSS that I thought to realize, say, a precise 16-pixel spacing between two paragraphs you needed to do something funny like <font size="2"><br /></font> and cross your fingers it was right, or <img src="clear.gif" height="16" width="1">.  Painful and cumbersome, and a nice illustration of why learning CSS should be an alluring endeavor for up and coming web developer.

CSS, it turns out, is brilliantly suited for a developer to capture those subtle-yet-uniform rules of layout and spacing created so meticulously by designers.  I used to think woe is me for having to realize their designs in a clunky, unpredictable environment known as the rendering engines of all popular browsers and their versions.  Now it seems like designers have the tougher lot: they need to perfectly position all of those design elements on a PhotoShop canvas, whereas I can make a few measurements of pixel heights, widths, margins, and so on, write a few corresponding CSS rules, and the browser does my meticulous dirty work for me.

I used to think developers (myself included) were limited by the medium of HTML and browser rendering engines when it came to how close they could get a live web page to look like its original intended design, and that a large collection of imperfections would have to be pardoned.  Mastery of CSS reveals that, for the most part, there is no good excuse anymore when an HTML implementation deviates from the PSD.  If it seems that there is, chances are there’s a CSS guru out there who could make it right.

That said, there are somethings to be said for designing in a way that is savvy for the web, which I’ll cover next in Respecting the HTML.

Many thanks in this essay go out to Rob Fieldhouse of Playground, the designer with whom I’ve done the most designer/developer collaboration on web projects, and whose eagle eyes and elegantly structured designs guided me to this place of design rigor and appreciation.

Early last week a friend asked me if I knew of any freelance iPhone app developers.  This made now the 4th time this summer I’ve had someone present either a need or interest in my ability to do iPhone apps, so I took it as a sign that I should at least dabble in this new fangled technology and see if the learning curve would be worth tackling.

I’ve been recently delighted to find it was.

After downloading 2.3 gigabytes of installables in the form of XCode and it’s suite of tools and iPhone simulators I was disheartened to find a strong emphasis on GUI-based design of user interface components: even Dashcode, the suite for creating iPhone web apps, seemed intent on generating the HTML, JavaScript and CSS for me if I could only drag and drop things the right way in accordance with their template models.

The breakthrough happened in stumbling upon Jonathan Stark’s most excellent book, Building iPhone Apps with HTML, JavaScript, and CSS.  Thanks to it, instead needing to learn a few new programming languages (Objective C and Cocoa) and a foreign development environment, I learned how to use my existing mastery in the more universal web technologies to make compellingly native looking web apps that run perfectly on an iPhone.

You can see the result here:
http://www.jpl-consulting.com/projects/bumpinta/mobile/

This demo is kind of bland in most browsers, but looks pretty good in Safari, and of course best in an actual iPhone.

Overall my foray into the world of iPhone app development was 4 days very well spent.  The whole shortcut to me being fully competent to make web apps for the iPhone I owe to the really smart work of a few groups who are making tools that bridge the gap between niche devices and open standards technologies, notably David Kaneda and Jonathan Stark of jQTouch, and the geniuses behind Phone Gap.

A while back I interviewed a longtime client on how he viewed working with me: I was looking to get a real, introspective look on what works about my style of service, what’s lacking, why hire me at all, and so on.

I got a number of pearls out of the experience, but one in particular I’d never heard or even considered before: “What’s really nice is that you put up no resistance.”  Eh?  “Say more about that”, I replied.

Paraphrasing, he said that when there’s a problem or a snag I just go with the flow of whatever is deemed important and I’m game to just work any which way towards a solution.  Whenever faced with “hey, this isn’t working”, I’ll quickly improv and alternative and it’s NOT A BIG DEAL.  No resistance.

What a cool distinction.

For sure, it’s common in my field for formality and ceremony to get in the way of a quick, pragmatic solution to a problem (this is, after all, an industry that derives a lot of self-importance out of months long dev cycles, rigid road maps to follow, rigorous testing, and the occasional 370 million dollar error).  So if a programmer assumes the demeanor that doing X or changing Y will be a big deal and is likely to take loads of time or apt to cause tons of complications, their expertise and warning generally needs to be heeded, at least by non-programmers.  (This is not unlike the futility of arguing with your mechanic over the state of your car’s transmission, when you are not a mechanic.)

Being a low resistance programmer requires a combination of both mastery over the domain (necessary to responsibly perform a given task, correctly and without ill side-effects) and the discipline to not indulge in a story of exaggerated burden (which can be gamed for inflated pay and longer time lines).  So when it comes to the relative merits of programmers, low resistance is of course favorable, but only given comparably good end results.  Two programmers might share the “can do, no problem” attitude up front, but if one of them took 3 times longer than anticipated or made a quick mess of things, that’s a matter of being naive, not willing and able.

Every situation is different, of course (some things should be a quick fix, and others genuinely are a big deal), but over time I think it’s possible for a non-programmer to gauge what kind of programmer they are working with.  Say you have a programmer that you rely for keeping critical parts of your business operations running smoothly.  If it’s a pleasure to bring issues to their attention because you typically leave the interaction with a sense of peace and that all is well in the world, you probably have a programmer who makes your issues theirs, and then makes small and tidy work of it.  If you have someone you hate to bring problems too because it makes you feel like life is generally a complicated mess, then you probably have a programmer who’s more invested in telling you how hard their work is than actually tending to what you need them for.