Cykod Blog

If you asked me whether I prefer to shop at a small, locally-owned and operated store or a large chain/box store - I would tell you that I prefer the small store, but the truth of the matter is that I shop at a number of chain stores all the time, places like: Home Depot, Costco, Stop & Shop, Dunkin Donuts, Target, Macy's.

Some of what's sold at those larger stores don't have alternatives in small locally run stores. Some do but are much pricier in smaller stores or don't have the same selection.

The interesting thing is that in my own experience sometimes we are willing to accept a limited selection or higher prices and sometimes we aren't.

Take food for example - by the end of the day we need to have put a certain number of calories into our body to make it to the next one. For any given meal, there's a lot of options for how we do that - All the way from McDonald's and Subway to Locke-Ober and Grill 23 & Bar - where we go depends a lot on what we're looking for. If we just want to put some food in our belly, we don't really care where we end up, we just want something decent, quick and cheap. If we're not just looking for food but for an "experience" the sky's the limit for how far we'll go for a bite for how much we're willing to pay. Are we really that much better off in a physical sense at the end of the day paying 20x as much for a couple thousand calories? Of course not, but there's obviously more to eating than just satisfying a physical need.

The same can be said for just about any other product or service. If all we're looking for is the end result - let's take a specific model of Refrigerator in this example - then what we will do is scour around for the best price and delivery options and use those as the guidelines for where to make our purchase. However, if we're looking for more than just a specific fridge - if instead you're looking for someone to help you decide which fridge to buy - suddenly where you go to buy your product matters because of the specific knowledge of the person you end up talking to. In our case when we went to Best Buy to ask a couple of questions about appliances we quickly realized that the person trying to help us (after we waited 10 minutes to successfully flag someone down) knew less than we did.

The contrast couldn't have been more visible when we later went to Yale Appliance and had someone help us decide what to buy. Yes - what we ended up buying was a commodity - but the process to get there highlighted how a company can add value in their approach to the business which people are willing to pay for.

Great businesses have the ability to turn commodities into experiences with the way they treat their customers. These great businesses aren't always small locally run businesses - sometimes there are franchises that people love to go to because of the people that work there - but many times it seems that the type of people that are engaged and motivated in what they are doing end up at smaller businesses because of the more positive culture that seems to permeate the good ones. There's a company in the book Small Giants that is in the Records Storing business - CitiStorage Inc - that manages to do just that for a business sector that's almost the definition of a commodity service industry. Yes, they do have to compete somewhat on price, but what makes them great has more to do with their business atmosphere and methodology than the price tag that they offer.

All those larger stores that I go to: Target, Home Depot, Costco, etc sell commodities and nothing else. If I can find the same product somewhere else for less - they've lost me as customer. So their only options are to compete on price and try to lower their cost of doing business. This usually results in removing perks and employees that cost too much (usually the good ones) - further pushing the store into commodity-land.

The alternative is to embrace the things that make your operation less of a commodity - the differences in how you run your company and the employees that are great at their job (and who probably cost you a little more) - and suddenly you don't have to compete just on price. You're customers will come back to you because of the value that you add - the particular things that make your company unique.

If you're a Web Developer and all you're doing is trying to compete on price, there's a whole bunch of people overseas who are going to beat you at that game. However, if you are can differentiate yourself - be it by you reputation, service, responsiveness or skill set you'll be able to charge a lot more for what you do and be a lot better at it.

(A Prequel-ish post to Specs: The Consultant's MacGuffin )

One of the largest challenges you'll face as a consultant is in generating quotes for potential projects. Prospective clients will come to you and ask - How much will it cost to make X? And you will be expected to respond with a hard and fast number that you are willing stick to as the project progresses.

In my experience, coming up with that perfect hard-and-fast number is a impossible proposition for you and a irrational expectation on the part of the client for the majority of projects - pretty much anything without perfect specifications that's not a carbon copy of a previous project that you've done. As most clients don't know exactly what they want until much later in the process, asking for a fixed quote is akin to asking a car dealer to commit to a price before you've decided on a sedan vs. a SUV.

As Venkat and Andy write about their book Practices of an Agile Developer in the section "Fixed Prices Are Broken Promises":

A software project is subject to all the simple mistakes [as building construction] plus fundamental changes to the requirements (no, not a shed, I want a skyscraper!), huge variability in individual and team performance (20X or more, depending on which studies you believe), and of course, the constant inrush of new technology (from now on, the nails are circular) (Practices of an Agile Developer, p.75) .

They suggest an alternative - Ask the client to pay for one iteration of an agile development cycle. start with a small set of features and a shorter development cycle to create a deliverable with most of those features that is useful in some way to the client. The client can then choose to go forward or not with the project but at most they are only out the cost of an initial iteration.

This is a great idea and probably a win for everyone involved - but in my experience it's a tough sell to a client unfamiliar to agile processes. If you need the project, sometimes your are going to have to come in at a fixed cost or the client will go with someone who does.

Your (potential) client is not a software developer. They don't understand the intricacies of what's involved nor do they understand that there are vastly varying levels of project quality depending on the developer (See: Software is a Craft ). I'm not saying that they should understand those things - it's not their business - but the bottom line is that your client will need to make a decision on who to use and will generally use some very simple metrics to choose who to go with. I've found they generally go by:

1. Were you recommended by someone they trust
2. What does your existing body of work look like
3. What is your price.

There's also a 4:

4. What are the details of your proposal

But that, I've found, is less important than they other three. This is why - when your company is just starting out and #1 and #2 are not working in your favor you need to compete on price. You will probably need to save the creative proposal Venkat and Andy describe for a little while down the road when you have a little more clout behind your endeavor.

So - back to that impossible quote. Before we get into the details, I think it's important to keep a definition of what a quote is in mind and here's mine:

Quote (n) - the amount of money you are willing to do a project for.

That's all it is. It's not a perfect calculation of the number of man-hours involved with precisely added-in expenses for overhead and coffee. You can pretend it is - but in reality, it's just the baseline number for which you are willing and able to complete the project - obviously including any fixed hardware, software, contractor costs added in.

Now, you do probably have an hourly rate that you've set either explicitly or implicitly - and you should work off of that rate when generating your quote because that's the only way to get a number that's in the correct ballpark. Going back to that definition above, however, you need to acknowledge to yourself that some projects are going to be more essential to your business than others and you need to have a little bit of flexibility in your numbers to give yourself a better chance at projects that you actually need and want. If you need the project to make ends meet and put food on the table, than it's perfectly reasonable to push your final number down a little bit to get a better shot at landing the project. Alternatively, if a project is only tangentially interesting and you're already booked pretty solid with work, put a bigger multiplier on your final number.

You are not beholden to your self-set hourly rate and the RFP process is a pure a form of the free market so there's no need to feel guilty adjusting your number up or down to whatever works for you. That being said, I do feel that once you are working with an existing client or on extending existing projects, there is a level of trust built up so that your client can count on some consistency in their costs.

Now however you do it, you will most likely fail miserably the first few times at connecting your estimated hours to reality, at least that's been my experience, and there's only 1 important thing to remember: once you get a project, track your time versus the numbers you came up with. If you do that consistently over a few projects you'll be able to develop some insight and start to converge your quotes with reality.

Now for how to come up with that imaginary number that is supposed to represent the Total Hours X Hourly rate. One solution is to scan over the request quickly, think about it for a couple of seconds, and then just pull a number out of thin air based on your gut feeling. I'd recommend against that, but it'll probably take a couple of times making that mistake as a new consultant before you are willing to commit yourself to some sort of process.

Here's what we do (and I'm sure the MBA-types will shake their head's disapprovingly at the lack of ISO-9000 certification on our processes ):

Write the quote out in a bullet point, line item form generating only as much detail as you need to figure out how long a piece will take to complete. (See: Spec's the Consultants MacGuffin for a little more on specs )

Now put a time number (either in hours or days depending on the size of the project) on each of those bullet points and add those up to get a base number . That's your: If I had all the details I needed and could develop in a sense-deprivation-chamber number. It's only bearing on reality is as a starting off point. You now need to take into consideration:

• Time spend talking about the project
• On-site meetings and travel
• Small preference changes (green v. red, radio button vs. select list)
• Features the client will assume are in there even if they didn't make them explicit
• Bug Fixes, both during development and after
• Larger included functionality changes
• Training
• Documentation (outside of the code itself)
• Dealing with corporate hierarchy (waiting for approvals up and down the chain)
• Anything else that will make you spend time working on that project

If you forget to take these into consideration you'll be unable to come up with a realistic quote and will instead just focus on development time - and if you're anything like me you'll view it as a challenge to your prowess (I've unfortunately said: "That's not that complicated - I could bang that code out in a couple hours" more than a couple of times and always regretted it.)

You also need to decide on a couple of important features that your project agreement will need to determine explicitly - will this project be done work for hire? i.e. who own the copyright on the developed code - you or the client - if you own the code it might be worth doing the project for less as you can reuse that code in the future, if not - then make sure you take that into consideration. Also, make clear how long are you responsible for bug fixes. If you don't make this explicit most clients will assume "forever" - and provided your prepared for that, that's OK. Make sure you and the client are clear on both of those issues - don't try to gloss over either ( and please don't take the previous paragraph as any sort of legal advice, talk to a lawyer and get yourself a legit development contract - See: Know your IP Basics for a little more on the above.)

All of these together need to be added into your quote in some way or another - either as explicit line items, or as a multiplier.

If you use a multiplier then the magic number is: 2.65. If you multiply your initial quote by 2.65 you'll come up with the perfect number to represent exactly how much time you will take on the project....that's complete BS of course, the multiplier is highly dependent on the initial estimator, the developers and the client and is by no means a magical, fixed number.

The multiplier will vary project to project depending on how much work the client has done to figure out what they want ahead of time and how involved in every small decision they need to be. It'll vary on how engaged you are in the project; how much the client will be involved in testing and a hundred other things. You'll have to figure out your own multiplier, but don't feel guilty using one (and by no means is "2" high - but, again, your mileage will vary)

I've generating quotes now for around 7 years and I still fail miserably at it from time to time. It's heartening to read something like "Fixed Prices are Broken Promises" to know that I'm not the only one. I try whenever possible to stay away from fixed quotes for larger projects, but fixed quotes are still the norm for the industry and until that changes we will have to keep pulling numbers out of the air to keep the work coming.

With a lot of businesses, there are, depending on your type of business a number of ancillary aspects of your business that you need to get right otherwise people won't take you seriously.

That thought was made clear to me recently when I received a duplicate bill from our accountant recently. It came 4 months after we had already paid the first one and was for a different amount. This, coming from the people we are entrusting not to screw up our accounting, doesn't inspire a lot of confidence.

On the web, it's easy to put up a professional front even if you're nothing more than someone working out of a basement. Put up a nice website, get some nice-looking business cards and you're in business.

The converse, however, is also true - you can easily destroy your credibility by doing thing that a legit web shop shouldn't be doing.

Your website shouldn't say 'under construction' when a generic picture of a bulldozer. It should be a nice solid example of your work and not require that everyone view it 800x600 on IE6 (No one will think oh wow they've been in business for a while, instead they will just say, wow they look dated).

You also shouldn't use superwebdesign@gmail.com* as your contact email.

If you can't do elements of your core business correctly for yourself, how can your clients count on your being able to do them correctly for them?

Bottom line - even if you're swamped with work, make sure you put your our house in order and do the things that make it look like you actually know what you're doing

-----------

*I'm not picking on anyone in particular, that's not a real email as far as I know.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Miksu said
August 13, 2009 at 10:18 AM
You want some cheese with that?

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

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

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

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

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

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

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

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

Some issues that come up frequently:

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

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

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

For years, high end applications (like Drafting, 3D and Business-specific) included little parallel, serial or USB dongles that plugged into the back of your computer and contained some extra information or code that let the expensive program you just bought know it was ok to run. The idea behind it was that while software is easy to copy from computer to the computer, the little piece of hardware was not. They were an early form of Digital Rights Management (before the current round of DRM using firmware coded asymmetric keys) that was enforced through a piece of hardware. So if you needed to run the program on more than one computer you would be forced to buy another license and get another dongle as opposed to semi-illegally using the software on multiple computers at the same time.

I say semi-illegally because the only behavior that this actually stopped was companies that obtained the software legally to begin with. For software pirates there was usually a crack that obviated the need for the dongle in the first place and they wouldn't end up paying for the software at all.

Dongles have fallen out of favor for a number of good reasons - they are cumbersome, they take up ports (or don't pass-thru correctly half the time), they get lost and broken easily, and honestly - you can't trust software makers to not screw up hardware (just like you can't trust hardware makers to not screw up software - how's that video editing software that came with your camcorder working?)

The idea behind them, however, is not necessarily awful - give users something extra besides just the magical bits that make up your software to try to keep them honest.

As fast connections to the Internet have become ubiquitous over the past decade companys have frequently tried to use the Internet as a dongle like protection.

Some of the earlier attempts at integrating the Internet as a security measure were to use it simply to phone home upon activation of a piece of software (See Windows XP). The user would enter a serial number and then the software would connect and activate that serial number in an online database, which in theory would prevent you from using it on more than one occassion. However as computer fail and break all the time, there had to be some leniency in the activation process for multiple install other you quickly had the makings of an internet flash mob that could drag your company's name through the mud (See: TurboTax Activation Fiasco )

The Activation fiascos - there have been a number of them, even Windows XP's relatively lenient and painless activation raised some serious ire in it's day - are telling because they essentially tried to transfer literally all the facets of the hardware dongle to Internet. Of course all the problems that made dongles obnoxious to begin with came along for the ride.

The essential problem with any DRM is that you are often only hurting the people who are trying to use your software legally. The people who pirated your software have hacked versions which put a couple of JMP calls that route around the DRM checks.

The power of the web however, is that you can do a lot more than just use it as a dongle. Take a high-end complicated the 3d program. What if instead of using an activation scheme, you created a community of help, tutorials and forums that was accessible only through an account where you had to enter you serial number to register?

What you'd be offering the people who actually buy your product is an added service instead of just another layer between them and using your product. Turn each page of your F1 help into discussion forum where people can post questions and comments and suddenly you've added value to your software that is accessible only to those registered members.

Suddenly you've turned the game upside down - you're making the pirates work harder to get up to date information and tutorials and adding value for your paying users. The web doesn't just have to be a dongle but can be an opportunity to make your software more valuable and better.

 

 

One of the major frustrations of working as a consultant is the love/hate affair with specifications. Far too often, I've come to the realization that specifications often fill the role of the classic Hitchcockian MacGuffin. tagentially, the project appears to revolve around them, but by the time the project is all said and done, it turns out that the specs were essentially ignored. A MacGuffin, as described as wikipedia is:

A MacGuffin (sometimes McGuffin) is a plot device that motivates the characters or advances the story, but the details of which are of little or no importance otherwise.

In order to generate a development quote, a set of specifications are needed and should be submitted along with your quote. Those specs are the guidlines by which the scope of the project and the necessary set of features are defined. In order to generate a set of specifications, however, one or more discussions with the potential client must take place (usually a good deal more than one). By default - because clients don't like to read technical documents - your potential client will actually base their concept of the scope of the project on
those discussions, not what's in the specs.

The dilemma as a consultant is: how much time do you spend on a set of specifications that no one (including you) are going to read? Even worse any quote you submit should be based on a set of features that you believe are in the project, so you should really have a set of at least internal specifications before putting in a quote. Thus they are the consultant's McGuffin - extremely important from an abstract sense but the details aren't all the important - think of the actual falcon statue from the Maltese Falcon or the glowing suitcase from Pulp Fiction.

The question then becomes, how do you make sure the time you're developing detailed specifications is time spent well?

One of my recurring nightmares (this is a literal nightmare, I wake up in a cold sweat whimpering) is coming in at fraction of the cost of competing bids, being chosen, and then either have to complete a project at a fraction of our normal hourly rate or having to go back to the client and say XXX (which is clearly mentioned at the top of on powerpoint slide 82 of their RFC) isn't included in your quoting costs. That's the sort of thing that can doom a project before it even gets off the ground.

A proper set of limber yet detailed specs can get actually help avoid this and a couple of other problems and keep your project moving in the right direction. One thing that keeps the spec process from dragging me down too far is remembering that, when it comes down to it, when done right they can actually be a significant benefit to us and not just a worthless piece of documentation.

The guidelines we try to follow with specifications are fivefold:

1. Write your initial quote in a bullet point, line item form generating only as much detail as you need to figure out how long a piece will take to complete.
2. Once your quote has been approved, expand on the quote from #1, but keep the detailed spec's short and sweet - the entirety of the project doesn't need to be explained in laborious detail, only the parts where you are concerned you and the client might not be on the same page. Everything else gets a bullet point.
3. Make sure that it focuses on the output of the project and actions that users can take. The client most likely doesn't care as much about how things are operating on the back-end on - what they care about is what they see and what they can do. By keeping the focus on interfaces and actions, it'll be easier to say know when the client is asking for something additional as it should be clear whether or not their request is included in the specs.
4. Take the time to go over the specs line by line with the client. Provided you followed #1 and #2 this shouldn't be quite as laborious as it seems. Even for some of our larger projects the specs are only 4-5 pages and a 1/2 hour conference call was enough to go over them in decent detail
5. Send an email to the client after #3 asking if there is anything missing from the specifications and give them a couple of days to respond via email - it's quite possible that you may have missed something, but you also want to have a solid idea of the scope of the project before you get started. This way you have on record that the client is happy with the features in the project as scoped, and any additional requests will be viewed as such by both you and the client - keeping everyone happy.
   
   

There's a #6 as well - but as we're in the process of putting it to the test I don't feel entitled to pretend like it's part of our normal process:

6. Turn the line items from you spec's into acceptance tests using a framework like Ruby's Cucumber, further gaining value from the initial spec work.

We're currently working out the benefits of this, so I'll let you know how it looks when it's all said and done.

 

 

 

When my wife and I are forced to leave our Condo / Office (despite my best efforts, this usually happens a least once every couple weeks), we need to crate our dog Oscar lest we come back to an apartment full of destroyed footwear. Although Oscar willingly spends plenty of time in his crate otherwise, happily sleeping there when our tossing at night kicks him off the bed, the command 'Kennel up', immediately puts Oscar into soulfull, sad eyes mode - letting us know that we are taking all the joy from his life.

At least, that was my anthropomorphic explanation of his behavior. Turns out, by standing completely still, and looking up at us with puppy-dog eyes, Oscar will immediately get himself picked up, apologized to, petted for a little while, and lovingly placed in his cage. 

As it turns out - my wife and I were screwing up the feedback cycle.

Oscar wasn't responding to the command, but instead to our reaction of it. The problem wasn't him, it was us. In order to fix the cycle, we secretly placed a treat into his kennel before commanding him to 'Kennel up', and coax him into his kennel without picking him up. In a short period of time, we managed to correct his behavior by fixing our reactions to it.

What does this have to do with Web Development? Nothing really, but it has everything to do with managing clients (No, I'm not calling clients Dogs). Letting clients get away with over-the-top last minute demands, while it may seem like the right idea,will invariably land you in hot water with them and other clients. There's only so many hours is the day, and pushing off scheduled work to make an ill-considered, ill-advised change to a website or piece of code may placate one client temporarily, but will almost guarantee something else gets left in the destructive wake of that last minute job. It might be QA testing, it might be another client's Milestone (nicely scheduled two weeks previously), or it might be a meeting with a potential client that you are forced to reschedule. In my experience, most often it is actually that client's work that ends up taking the hit because there isn't time to go through the normal design/development, approval, testing and deployment cycle. It might be a little thing, like an incorrect phone number on an ad. Or a big thing, like a crucial website failure over the weekend that gets everyone riled up and pointing fingers. But without anyone stepping back, it's easy to let the cycle repeat itself over and over again (A la Deploy! Deploy! Deploy! ).

By allowing clients to get away with this behavior on a consistent basis you are letting your clients harm their business and your business for no good reason. The client doesn't necessarily benefit either, as errors and bugs will creep into the final product and your client's reputation can suffer. Clients won't necessarily be able to see that big picture, all they see is your quick turnaround time and assume everything is good to go. Unless you can convince them that slowing down is better for everyone, the last minute demands won't stop. 

Sometimes a client's last minute work can't be helped for some reason or another, but as you're throwing together that needs-to-be-done email campaign and corresponding landing page at 3:30 on a friday, ask yourself if it really needs to be this way, or if you haven't created the proper feedback incentive.