Programmer for Hire

It’s worth acknowledging that anyone who hires a professional to build a web application (me, for example) is taking a sizable risk: for a sizable amount of time and money, they will get an end product that doesn’t yet exist, the description of which itself is subject to ambiguities, misunderstandings, and mistranslations, and the implementation of which is often fraught with surprises and complications.

To mitigate this risk, a professional can (and in my opinion should) take a risk themselves: to deliver the system as specified for exactly the agreed upon price.

How could that be considered a risk?

Most web applications are inherently complex, and a large portion new applications consist of one or more novel problems to solve.  Both complexity and novel problems contribute to the likelihood of unforeseen gotchas, surprises, and challenges, and guesswork is accordingly injected into estimating the time and money involved.

Therefore when a professional gives a price, it’s an assessment of how much work a project will take that is made without the luxury of hindsight.   Saying something like “you know that thing I said would cost $800?  Yeah, turns out it’s harder than I thought and so it’s going to be $400 more.” to a client is an admission of a failure in making this assessment.

“Fixed Price or Bust” is the model I subscribe to handle this risk: I learn what I need to about the project, estimate the complexity of each segment, assign appropriate prices for each, and then for each segment, one of three outcomes will result:

1. Nailed it. All went according to plan: I complete the segment within the time that I’d estimated, and all is well.
2. Stumbled. It was harder than I thought: I got it done and on time, but not without sacrificing extra hours dealing with curve balls I failed to foresee.  I lost some time but gained some learning, and it looks just like the first case to my client.
3. Bust. It was much harder than I thought: so much so that I need to let my client in on the problem(s) that have arisen and given them options.  This step constitutes reorienting to reality in light of new information and experience, because the estimate in this case has proved be wildly inaccurate/optimistic, and I take as much responsibility as I reasonably can: either we renegotiate the time line and/or cost, revise the approach somehow, or we drop the segment outright and I eat my time already spent.

Bust represents an occasion where a client is saddled with the uncertain complexities of software development, something we web professionals are hired to abstract away as much as possible.  Accordingly it should happen as rarely as possible.  In my 4 years of freelance web development there was only one time that I busted.

Fixed Price or Bust creates a responsibility on the side of the professional that I think goes a long way to support clients and foster trust in the process.  It puts the onus on a professional to accurately assess the complexity of a project.  They have strong incentive to get it right, and a strong disincentive to get it wrong.  If a segment of work turns out to be harder than anticipated, Fixed Price or Bust nearly ensures that the situation remains their problem, and not the problem of the client.  Working faster for a fixed price both increases the profitability of a professional as well as gets a client a completed project sooner.  It’s a great alignment of priorities.

If web developers were elected, that’s one of the platforms I would run on.

All other things being equal, we’re all pretty much hard-wired to prefer pretty: the people we’re with, the spaces we live and work in, the scenery around us.

What we have to stare at on our computers is no different.

Making software that is pleasing to look at is a good way to honor your users.  It’s a way of saying “I know know you may be staring at this for a considerable amount of time, so I want you to enjoy it.”  Apple has done this remarkably well: I’ve been a Windows guy since my first computer, but I still have moments of being drawn to my gal’s mac… it’s just so… so shiny and looks so good.

Where Design Gets Neglected

In the realm of companies who need custom software built for strictly internal use, I’ve noticed a certain acceptability of ugly software.  After all, it’s not like the the users of it need to be sold on the design.  Once it’s built, that’s pretty much what they need to use to get their job done.  Adoption is mandatory and there’s only one option.

So the desire or tendency for companies to skimp on design, or for developers to phone it in (favoring instead to focus on making it work), is understandable, if not outright pardonable.

But the web, as a medium for creating applications, changes things a bit.

Design for, say, Windows desktop applications (a longtime dominant platform for corporate custom applications) has been largely tethered to the native look and feel.  When you build something to run on Windows, it’s presumably a path of least resistance.  You know the look:

The web, on the other hand, is aesthetically powered by its delightfully simple and powerful CSS technology.

That’s good news, because if you’re building a project that will run in a web browser and your developer is CSS savvy, the cost of realizing any given look-and-feel throughout the system is drastically reduced.  You can set up a developer with a PSD that reveals the aesthetics of the common widgets to be employed throughout the system (buttons, text inputs, tabbed regions, etc.), and he or she can remix and re-purpose those widgets to build the entire application to match.   If it’s built right, it’s just a matter of swapping out one or more images and/or tweaking one or more CSS rules to achieve system-wide design changes, from minor tweaks to thorough overhauls.

Why This is a Win

It’s true, ugly software that doesn’t need to be peddled to a finicky public won’t suffer from fewer sales, nor will it reveal to a wider audience any embarrassingly bad sense of taste.  The benefits of working daily on software that looks good are less tangible but still probably important: morale and productivity.  “I love what I do” is a good way to cause a highly effective team, just look at Zappos.  If you have a single program that must be worked on an hour or more a day by your team,  better to have that program say “I want your experience to be pleasant” than “this is ugly and we know it and we don’t care.”

The web era makes pretty software design much easier to implement, so with that lessened barrier it’s become an even better investment.  After all, the forces of aesthetic preferences are always at work in the consumer market for software.  The same human element is present for people who must work with corporate software, it’s just that, given the lack of choice, the effect plays out in different ways.

In my experience, some of the formality of programming for hire seems to precipitate an unfortunate reliance on email for communication in lieu of picking up the phone, and this goes both ways: client to programmer, and programmer to client.  There are a number of reasons for this that I can see:

• The stereotype that programmers are anti-social and/or need to concentrate (a client might think “maybe I shouldn’t call them and interrupt their programming mojo”).
• The reality that programmers are anti-social and/or need to concentrate (a programmer might think “if I call them we’ll get wrapped up in all kinds of winding dialog about out-of-scope feature requests and what-ifs”).
• An unclear working arrangement for that kind of time spent (does phoning up the programmer hotline rack up billable hours?).
• A perceived notion that an email, being less intrusive, is a better way to respect the other party’s time.

These are all valid reasons, but the downside of being stuck with them is the [largely hidden] downside that lurks in relying on email communication for such a thing as software development.

Software development is complex.

It’s not necessarily hard, but it’s complex: there are many small parts that come together to make up the finished product.  The process of creating it is therefore is ripe for ambiguities, misunderstandings, and varied interpretations of the same stated intentions.

The antidote?  Clear and fluid communication.  Communication that does not require formalities like a scheduled meeting with 2 weeks lead time.  My ideal is being able to pick up the phone, get my client up to speed on what’s going on, and answer whatever questions are on the table.  Five minutes is par for the process, and when it really works we end the call feeling like genuine collaborators building something great, clear that our visions are aligned and we’re on track.

By email that kind of satisfaction just isn’t possible.  If I have a question, there’s a decent chance that what I’m asking won’t be fully addressed by the email answer I get back, and an even better chance that I’ll have a follow up question precipitated by that answer.  The minutes both me and the client have spent typing up our correspondence quickly passes the five minute mark, and the back and forth doesn’t do nearly as much to bolster a sense of team, or confidence that all is progressing smoothly.

That’s why I like to encourage that kind of accessibility: I want my clients to call me up when they’ve got something on their mind pertinent to the project, and I request of them license to do the same.  I have yet to have a client abuse the privilege or even come close to doing anything that could be called wasting my time.  When I come across a design decision I hadn’t considered and don’t know enough to pick what will be best for the business, I love calling my client and getting them in on the scenario.  It gets them interested and involved in new opportunities, and lets them be more at the helm of getting exactly the end product they want.

This pertains to more-or-less corporate development projects, where projects are invariably rooted in a real bottom line intention.

If your developers aren’t hip to the surrounding business lingo, or don’t have time (or inclination) to learn the bigger picture  (like which kind of customers are going to be using it, the anticipated ROI, or what the customer support team really needs, etc.), make sure you’ve got a translator to bridge the gap.

On one side, a good translator will ensure that the business brains devising the project aren’t overlooking some great opportunities that tech could offer to solve the problem, and that they aren’t asking for what turns out to be a technical nightmare for only a minor gain.

On the tech side a translator will make sure the programmers don’t get carried away with the “cool factor” (tech for the sake of tech), and that instead what they’re churning out is a real fit for what’s intended.

The net result on both sides is that a good translator will keep a project on track, true to it’s original need, and ensure that the technology being employed is a good fit for the problem at hand.

Last night I was talking with Tom, friend and former business partner in Playground Creative.  We got to talking about a question that I usually have a hard time answering, the all-to-common-when-meeting-someone, “so what do you do?”

“I’m a programmer.”  “I’m a web developer.”  “I make really kick-butt web applications.”

Most of these kinda fall flat to most people: either it’s too vague, or means very little to those who don’t talk tech geek speak, or even evokes the stereotype image of an antisocial recluse hunched over his keyboard all day.  It doesn’t lend itself well to any follow up conversation about the real juicy parts of the work that I love to share about.

Just as it’s much easier for someone else to tickle you than to tickle yourself, another person who isn’t enmeshed in the world of what you do can observe and describe it much more cleanly.  I think Tom nailed it when he gave me his words of how he’d answer the question if he were me:

“I listen to the vision of what a project is trying to accomplish, come up with a solution that is 100% true to its essence, and get it built fast.  If it’s something that you know is possible, but it hasn’t been done before and you just don’t know how to accomplish it, I’m the guy to work that out and reliably deliver on it.”

Nice one, Tom.  I think I’m gonna rehearse that one a few times for the next time I go out to a networking happy hour.

A lot of people have use for specialized, custom built software, but far fewer are able to create it themselves.  So it is common in my industry that software is created to be used by someone else.  This gives rise to a gap in the perspectives of the creator and user: the creator is often only a user to the extent that they ensure that every piece works as it should, whereas the user needs to use it in a real working environment every day.

What this means is that even a well meaning and highly talented developer can produce something that end users hate, simply for lack of the day-to-day user perspective.  Consider:

Creator: This feature works like a charm.
User: I use this feature 100 times a day but takes 4 clicks to get to when just 1 could do.

Creator: The login system works really nicely and is secure.
User: I get booted out of the system after 20 minutes of idle time, and my usual task away from the computer takes half an hour.

Creator: This downloadable spreadsheet report has all the info about orders placed.
User: I still take 4 hours a week to manually reconcile this report with our CRM system.

Creator: This date picker widget lets you quickly choose your date range for exporting orders.
User: I never need anything but the orders from the last 7 days, but I still have to always pick those dates using this stupid date picker.

This gap is only a problem when there is no communication between developers and users. And it’s not surprising that communication is generally sparse between the two.  Less-than-awesome software is more than common, and so among users there’s a common mindset that that’s just the way it is.  Either it can’t be any better, or perhaps the developer hates them.  (Though the latter is irrational, even I fall for it when I think of the development team behind IE6–I know they were doing their best.)  Both views give rise to a “I’ll deal with it” mentality, perhaps with a “well at least it’s better than the old system” thrown in.  Even if an end user can make requests directly of the developer (seldom allowed to avoid willy nilly wasting of expensive developer resources), the idea seldom occurs as a real possibility.

But what if that communication is strong and the custom development arrangement does allow for tweaking based on such real world feedback?  The above four hypothetical issues are ripe to be fixed with a little bit of tweaking, if only the developer knew about them.

A great solution to this gap is to have the developer become a user in the real working environment after the project has been presented as complete.  That time lays bare a great number of shortcomings that a system might have in actual practice.  It’s fun for everyone involved: the developer gets to be a hero and enjoy the satisfaction of making big win tweaks.  Users have their issues addressed and their needs met: their cool new system just keeps getting better, often within minutes of making a request.  And key stakeholders in the project are delighted by both the improvements and the happiness of the people using it.

A day on site spent beside end users  is something I’ve done now and again, but I haven’t thought to make that a more standard part of my service until now.  It’s that extra mile that provides so much with many kinds of projects.

During the course of my programming career, I have found, without exception, the greatest success (be it measured in efficiency, the end result, or even my personal joy in the process) comes with solo projects.

After such a years-long track record it begs a question: am I just another example of the lone wolf coder who either cannot or will not play nicely with the other kids, or is there really something defensible in the idea of a programming team of one?  Central to The Mythical Man Month is the notion that adding people to the programming team of a late project will only make it later, but what about the other extreme?  Can minimizing the headcount to 1 make a better project, and if so, under what conditions?

Communication

Certainly there are some immediate gains that arise.  There’s no redundancy in learning the initial requirements of the project: one point of contact constitutes a massive streamlining of communications, and there is no opportunity for a game of telephone to distort the message as it disperses from client to team.  The same can be said of the nuances that arise during a project’s lifetime: tweaks can be made to a system’s architecture without the penalty of coordinating with other parties impacted by the change.

On a team of one, everyone is always on the same page when it comes to the state of progress and what’s currently on the client’s mind.  An entire class of meetings, the inter-developmental team meeting, can be nixed entirely.

Division of Labor

While out with a few of the guys of the Denver JQuery meetup group last week I heard a lot of people describe themselves as either “front end” or “back end” developers.  This is a useful separation of labor, for the skills of each are reasonably disconnected (front enders are charged mostly with the user interface and making the system look pretty, while back enders are more concerned with the business logic and data shuffling about).  But for most projects the roles are heavily intertwined.  Changes on one side will often necessitate changes for the other, which will take a cycle of communication/waiting/updating/integrating/testing among 2 or more people each time.   For a team of one who is master of both sides of the system, this communication is instantaneous and it’s just a matter of revising the work.

Come to think of it, it’s not just a matter of saving time.  If the logic and flow of a system are handed down from on high as immutable gospel, both parties can work on their parts separately and bring their work to make a near if not perfect fit.  But this is seldom the case.

What really happens is that original designs are either sketches or best guesses: either benefit by evolving from prototypes and earlier drafts.  Lowering the activation energy for tweaks allows it to evolve better simply because it’s less headache to explore new ideas.  When an idea implicates changes that create more work for others, given the choice you’ll more likely stick to the original spec.  If it’s just you and the code, you’ll be far more inclined to take risks.  When you hit a dead end, there’s no one you need to apologize to.

Worthy Collaboration

One piece of teamwork I’ve consistently found to be a great boon to a project is a clear cut relationship between aesthetic design and coding.  A great design for a project makes working on it a joy (bad design kills morale (or at least drains it) and no one is immune), and when I’m given a rich vocabulary of aesthetic elements I can remix and re-purpose them for whatever needs come about.  Thus design in projects is more of a one-time input rather than a you-work-on-your-part-and-I’ll-work-on-mine-and-we’ll-make-sure-they-fit-together-all-along-the-way.

Clearly a team of one needs to be able to many disparate competencies in order to pull off an entire project.  That might suggest that their talent might necessarily be spread thin, but I’m not so sure.  When I am ultimately accountable for a project, there’s much more a sense of pride and ownership for the end result.  You can’t hide behind a story that someone else dropped the ball if the project is less than great.  For those two reasons the entire process becomes the opportunity to really bring your art and have it shine.  Learning an extra trick and going the extra mile is much more enticing because it is much more noticeable and attributable.  Contrast this against the temptation to phone it in and just meet the spec requirements on a project where your part can’t override the overall momentum of the team.

Certainly the team of one is not much of a duplicate-able model for relying on all projects: the larger a project gets, the harder it is to find someone who can be the sole master of it all (let alone be interested in doing so).  But it may be a worthwhile direction in which to grow talent: rather than gauge merit and encourage development along the lines of having increasing years and experience within narrow X, be interested in growing an expanding base of proficiency in X, Y, Z and so on such that the size of a project that could be taken on by one person increases.  The power of a given group of programmers may be best measured as the size of the biggest project that one member of the group could handle alone.

My name is John Larson, and I’m a web developer.

And I really love doing it.  I love the cool widgets, I love the new tricks and tools, I love the brainy challenges, I love the elegant solutions.

I love building stuff that others are just plain happy about.

This business heartily feeds my nerdy appetite for mental stimulation.  And my mind has had plenty of time to think about–and become fascinated by–the whole process of software development.  The tack that I took was to expand my own kung fu (literally: “human achievement”) on the matter and be the best, most well rounded and proficient web application guy that my brains and determination would allow.

I cut my teeth doing customizations on the MonsterCommerce e-Commerce platform and building my own web-based system for managing that custom programming department.  Fielding no fewer than 800 leads during my tenure and overseeing (and eventually joining) my programmer crew during over 100 projects gave me all kinds of ideas and perspectives on both what worked great and what was an absolute mess.  Years of freelancing and other projects have further honed my views.

Contained in this blog you’ll find a series of essays and explorations reaching into the world of custom software development, direct from my brain to your eyeballs, thanks to the miracle of the internet.  Partake and enjoy.