Programmer for Hire

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 improvise a fix 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.

There are some services for which I think the model of charging based on an hourly rate is appropriate.  Software development is not one of them.

Consider: some services fit the hourly model to a T.  These are jobs where the hours spent are directly proportional to the value realized by the hirer.  It makes sense that getting the hour long massage costs roughly double what the 30 minute session does.  Or manning a reception desk.  When somebody needs to be there, every hour that a body is there that creates value and fulfills a need of the hirer.

But software development runs counter to this notion.  We programmers are pretty much always hired to solve a real problem stemming from a real need, not to provide hours of coverage hunched over a keyboard, and certainly not to provide extended enjoyment for the client by virtue of working longer hours (the massage therapist might hear the phrase “hey, that’s nice, why don’t you do that a little longer?”, I don’t think a programmer ever has).

No, in software development it’s virtually always the opposite: the longer a project drones on, the more painful it is.  Just ask any stressed-out looking project manager who keeps getting excuses and pushed back deadlines from her development team.

But doesn’t more hours mean more quality?

Maybe, but that correlation is sketchy at best.  To realize a given set of features, a pro can often do it both better & faster: the number of hours spent becomes an argument against quality, not for.  (I’m much more apt to trust that a WordPress install got done right by someone else if it took them 15 minutes rather than 3 hours.)

Programmers can (and should) be hired on the overall demonstrable quality of their work, and a review of their portfolio plus a mutual understanding of the level of thoroughness/quality that is called for (throw-away prototype or enterprise level masterpiece?) keeps the fixed price model honest.  (Because yes, without that mutual understanding a developer could hack the fixed-price model by racing through a project and cutting corners, to say nothing of whether or not he’ll be hired again).

Alignment of Priorities

If we can assume that a contractor is guaranteeing satisfaction (and we probably should, right?), then a faster execution of a fixed-price project is in the best interests of both parties.  The client gets what they need sooner, and the effective hourly rate of the contractor is higher.  When an accurate sense of the quality to be expected and a correlate price tag are established, the fixed price model creates this nice alignment of priorities between contractor and client.

By contrast, hourly creates a misalignment of priorities of client and contractor: the contractor gets rewarded for dragging their feet and making problems out to be more complex.  Not a huge amount of course, because in the logical extreme they’d get dumped sooner or later.  But it’s just too easy to milk the clock and divert energy from actually solving the problem, to instead convincing ones self and others that it’s more difficult than not.

Effective software development is all about fewer smart hours as opposed to longer hard hours.  Pricing for it should probably then reflect that, and by the  same token programmers should probably strive to avoid the curse of the hourly wage.

It may be either a sign of laziness or of wisdom, but I’ve had a few conversations of late where I’m deliberately selling my clients on fewer and/or less complicated features.

On the surface this is bad salesmanship: I bill by the project, and of course the price tag for a given project grows with my estimate of the complexity of what I’m building (and hopefully the value gained by the client, as well).  The more features a client is certain they want, the more features I get to build and charge accordingly for that work.

So what’s up with my recent kick of advising fewer features?  Turns out it’s mostly situational with a dose of outside wisdom.  The projects I’m thinking of are both of an “expand in a new direction” variety: one is a pilot program to prove a new concept in their e-commerce, the other is to make a hub for a community to interact online in a way they haven’t before.

The dose of outside wisdom is the 37 Signals bit on the Race to Running Software which states simply “get something real up and get it up quickly”.  Both of my clients found it refreshing to hear things like “Tell you what, it’s just the pilot: we can leave the customer address book feature out for now, and add it in later if it turns out to be important.” and “Let’s see what your users do with just the ghetto-fab system of posting comments.  Then we’ll know what they’re bumping up against, if anything.  If it suffices, we’ll have saved ourselves a lot of extra work.”

Planning to build non-critical stuff up front involves a lot of guesswork and creates a bigger gap between speculation and real world feedback.

Would I like to be hired to build the customer address book feature?  Sure, it’s a tidy little feature that would be really slick and is clean to implement.  But let’s wait to see the first 5 repeat customers who place orders shipped to more than one address before we build it.  That will save time and money while we focus first on getting the system ready to launch at all.

It’s simply having an eye on the prize.  And I’m talking business win, not a juicier contract.

A few weeks ago I was on a conference call with a client talking about a new, expanded direction they were mapping out for their e-commerce.  The scope of the project was well within my reach to execute quickly and thoroughly, but there were good & valid concerns expressed over me being the keeper of the system as a one-man show.  After all, it would not work if a problem arose that only I was trained to address at a time when I was, say, gallivanting about in Panama: it would be irresponsible to structure a major part of their business to be vulnerable to failures that arise with poor timing.

As I’ve mentioned before on this blog, I’m a big fan of the benefits made possible by being a team of one.  I also really like the agility and flexibility afforded by being a solo act in the business aspect of my trade.  So when it was asked if I would hire and train up others to make possible a 24/7 manning and support of the project, I saw it fit to propose a re-framing of the situation.

This particular client is big.  The company has their own dedicated IT department complete with plenty of smart folks who are able to build, run and maintain complex systems.  They are also savvy about outsourcing: they know how to keep their own internal team smoothly handling internal operations by calling in outside talent to help with big initiatives when they come down the pike (which is why were having the conversation at all).

Rather than operate as a separate team on this project, I reasoned, why not have my contribution to the project be an augmentation of their existing resources?  Given they already have an in-house team that works on other things which integrate tightly with their e-commerce, I could do the heavy lifting for the project (that is to say: design and build it to everyone’s delight, and see it through to a successful launch), and then take necessary steps to leave their internal team empowered to own and maintain it with minimal effort.

It’s like building a building.  The work of the architect and the construction crew are distinct from that of the maintenance team and cleaners.  The better job that the former does enables an easier ongoing job for the latter.  In our case of software development I’ll refer to these two parties succinctly as builder and maintainer.

Characterizing a Successful Arrangement

So what are the characteristics that should probably be in place for such a collaborative hand off work to everyone’s delight?  There are a few things I can think of (this list is no doubt exhaustive, if you can name one I missed please leave it in a comment):

• The system handed over by the builder should as clean and intuitive as possible. Clean software architecture rules the day here, and any lingering patch-job hacks represent a great disservice of future burdens to the maintainer.
• The builder should train the maintainer. Without a doubt, the curse of knowledge can easily give the builder a comforting illusion that it should be easy for the maintainer to spot and fix problems the arise.  Rather, a maintainer should be left confident that they know how to navigate the structure of the code.  When they have reached that level it should be their call to make, not for the builder to assume.
• The builder should be accessible to the maintainer over time. Not 24/7 for hot fixes (that would defeat the purpose of handing off to a maintainer), but as an adviser for deeper, more long term issues including building further on the system.
• The maintainer should be technically qualified for the role. They needn’t be as skilled with the code as the builder (after all, it’s easier to maintain a well built system than to build it well in the first place), but they should be able to track down and fix minor bugs in addition to more regular maintenance.
• There should be general camaraderie and a shared commitment as a team between builder and maintainer. While hardest to quantify this is perhaps the most important: it’s a problem waiting to happen if a builder hands off the project with any air of “it’s your problem now”.  When the builder is oriented as a long term partner, his or her priorities are well-aligned with the project as  a whole: “I will do it right because I am ultimately accountable for its performance”.  The desire to avoid saddling the maintainer with a problem is a powerful motivation to set them up well.

These characteristics represent a chunk of overhead of the Augmenting a Team route, relative to using a separate one.  When handing off a project to a separate team, that team is free to manage long-term maintainability internally, however they deem appropriate.

What’s interesting about is that is how, in the scramble to get it launched, notions of longer term maintainability can (and do) fall by the wayside.  When a builder steps in to augment a team on a project, the above characteristics form a nice recipe for clean execution of a project; one that is mindful of both the initial work and long term maintainability.  It’s like having people over for dinner: you’re more likely to clean up your place out of courtesy to your guests.  A builder who knows that a maintenance team will be looking at and learning their code soon will do more to be proud of such a close inspection.

My recent involvement in spot checking someone else’s proposal really brought home for me an interesting dichotomy in approaches and schools of thought when it comes to spec’ing out a project.  (By “spec’ing”, I refer to the process of assessing and describing the specific needs of a project, and then assigning a price tag and time line to that assessment.)

My training (or, perhaps more accurately, my invented approach from when I started doing this back in the MonsterCommerce days) has taught me to do a rigorous analysis of all facets of the project up front.  I don’t submit a proposal until I can firmly describe what features will be included (to at least the level of detail of which entities the system will model and manage), and am able to assign a price tag to each one of those features.   There are a few pros to this approach that I can think of:

• A pretty accurate price tag for the whole project falls out just by adding up the module costs, plus perhaps some overhead of communication, project management, and/or padding for middle- and end of-project tweaks and revisions.
• I’m clear what I’m committing to so I know I can deliver on time (and not bust).
• My client sees exactly what they’re getting: it’s an opportunity to verify that our understandings align, and they can spot if there is anything missing.
• A sort of a la carte pricing becomes possible when clients can see how various features contribute to the cost: it enables them to tailor things to fit their budget or decide to hold off on certain features if necessary.

The major con of this approach is the time and effort it takes on my part to cook up such a rigorous sketch of the project before I see the first dollar.  The ability to do it quickly thanks to copious practice does well to mitigate this con, however.

The other approach then is of the quick, more glossed over variety.  This is where a price is given based on satisfying the high-level needs of a project, and that price will be set to cover a fair chunk of reasonable expectations to that end.  (In other words it’s like the contractor saying “We don’t need to go into details, I’ll price it so that no matter what specifically you’re thinking I’ll be happy to deliver.”)  I’ve seen it done often enough to know that it’s not uncommon, and there’s good reason for its popularity.  From the perspective of the one preparing the proposal, it’s quick, it’s easy, and though it may be accepted less often, it’s more profitable when it is.

Now with this dichotomy laid out it bears mention that the two approaches I describe are actually two points on a spectrum, one that extends out to greater extremes in both directions than what I describe above.

There is no objective best place on this spectrum to be for both clients or contractors, every point has certain drawbacks and merits.  (I may seem biased towards the detailed end, but rest assured I know the dangers of being too detailed: clients eyes glaze over, and/or they’ll feel locked in by too much contractual rigidity).  Still, if you’re hiring someone to do a project, it’s probably useful to recognize where your contractor is with their proposal: if you get a proposal where the feature scope is fuzzy AND it names a price, you’re probably paying for a big cushion of guesswork.

Last week the members of an organization I’m friendly with looked to me to what you might call “spot check” a project proposal that they had received.  It was a sizable project, so there was to look things over to ensure that it, as scoped out, would predictably leave them happy with the result when the work was all done and the fee was all paid.  I looked for answers to the following concerns:

• Are there any disconnects between the expectations of the organization and the contractor’s understanding of those expectations?
• Is there anything missing?
• Is the scope of the project sufficient to complete what the organization wants?
• Are there any gotchas, or foreseeable add-ons that will be needed later?
• Is the time line accurate and realistic?
• Is the price commensurate with the work, and reasonable against industry norms?

Doing this was a great opportunity: I got to exercise one of my more unique abilities to help out some friends, and I got a rare chance to compare how I roll with others in my trade.

What ideas, lessons, or insights did I take away from that comparison?  Plenty, but for now I’m going to focus on the one that strikes me the most:

I’m super inexpensive and work uncommonly fast.

(A corollary to that, I suppose, is that my sales process is rubbish: if I could pitch on a lot more projects a year I could perhaps get away with selling fewer but far less sweet-of-a-deal jobs for my clients.)

After fully grokking the project as laid out and enjoying a follow up conversation with members of the organization, I was clear I would be delighted to do it for literally half the price and could deliver it several weeks sooner, which made me feel pretty darn effective.  My deepest compliment however was what came back to me from the contractor: the presumption that in order to realize such cheap speed I would be using off-shore resources.

Nope, it’s just little ol’ me and my friends at Playground Creative. :)