Cykod Web Development and Consulting Blog

I wrote a quick n' dirty script for fun last night to see how we were doing on test coverage and who was responsible for the most untested code in the git repo. The idea behind the script is to take the output of RCov and line it up with the output of `git blame` and then track who's responsible for each line. It's ugly code, but it's was fun to pull together a couple of different pieces. Here's a sample modified coverage/ file (with the commit and person responsible for the code add on the left):

Gist below.

I unfortunately discovered I was the goat.

   

Mid-morning.

 

Here's why: many people (myself included) don't get through their emails each day. When the number of emails someone receives each day exceeds their ability to respond to them those emails start to back up and can go unanswered for days. Now, most mail clients show the newest emails first, so new emails actually have a higher visual priority than old emails and will tend to get handled sooner as the recipient races to try to keep up with the inflow of contact requests.

If you get your emails into someone's inbox after they have handled all the overnight notifications, marketing and spam messages, it'll sit as close to the top of their inbox for the greatest period of time and has the best chance of actually getting handled before falling into the bottom-of-the-inbox-hell. Given the variation in times in when people arrive at the office, mornings also tend to be less "busy" (with calls, meetings and the like) and so I'd guess people tend to spend more of their time responding to emails in the AM than the PM. 

When's the worst time to email someone? Anytime in the late afternoon into the evening. Those email will get stacked up with all the overnight emails and may be ignored. Even worse, If they are viewed on a smartphone or the like but can't be responded to immediately because the reader is not at the office, they email client will still mark them as "read" and they will effectively disappear into the clutter of the inbox.

(Note, this is all from my own personal experience as both the sender and recipient, so I'm sure there's lots of other opinions on the matter)

We've been thinking about the price points for Webiva for a while now, and gotten different advice from different people. Pricing software is a funny thing. The marginal cost of software is negligible compared to the upfront costs.

The perennial free market go to - the invisible hand of supply and demand - makes little sense. Downloadable or SaaS software effectively has an unlimited supply. We must instead fall back onto solely a Price vs. Demand graph, which shows a smooth curve of increasing demand as price decreases.

That idea is, of course, also complete nonsense. As discussion with other entrepreneurs and the excellent book Predictably Irrational demonstrated - the price of a good isn't always correlated negatively with it's demand. Higher cost and perceived value have often have a positive correlation. The first pages of the seminal book Influence: The Psychology of Persuasion tell a story of a assistant who misread their boss's scrawled note to halve the price of some jewelry that wasn't selling and had instead doubled the price. When the boss got back from vacation, she was surprised to see that jewelry that wasn't selling had sold just fine at 2x the price. A higher cost can actually result in a higher demand for your product,  resulting in a feedback loop in the middle of your pricing strategy.

So What's a SaaS provider to do? If you've got competitors, they've most likely already set the "perceived value" price point in your customers mind. You'll most likely need to price it in line with what they are charging. If you're the 'Cadillac' of the space - you'll need to up the price so that people know you're better. If you can make the argument that you're leaner than your competitor, i.e. solve a smaller problem but solve it better, then you can charge less without looking like the dime-store equivalent (See Basecamp). Underpricing your competitor, while it sounds like a good strategy, often begs the question as to why your product costs less (and go ahead and try to explain "0 marginal cost" to people). This is one piece of feedback we've gotten time and time again in discussion with potential customers and other entrepreneurs (This doesn't apply if the space your startup is in has been commoditized - then price is the go to decision maker)

However, of all the pieces of advice I've gotten, there's only been one that's been the most consistent: don't fret too much, you can always change it.

Interestingly enough, I think that's the one piece of advice that I believe is categorically not true. Or only marginally true but with a big asterisk.

True, you have some leeway with pricing, but not as much as you think. The Chargify flareup from Monday made that pretty clear.

Many people (Webiva included) are pretty put off with the changes Chargify made to their pricing announcement (effectively moving us from paying them $0 to $1200 a year) We're put off enough that we're going to extend our open-source Shop module with recurring billing instead of sticking with a recurring provider. We learned our lesson building an important piece of our revenue infrastructure on someone else's beta API. Regardless of what they do next, the cat's out of the bag, they've done it once after all and they can do it again (They did respond quickly in the aftermath, and have added a bootstrapping plan, but for us the decision's been made)

Here's the thing: I personally don't think there's anything wrong with a company changing their pricing. We were put off, but that doesn't mean I blame them. They, better than anyone else, know what they need to do to survive and thrive as a startup. Most likely their previous model just wasn't generating revenue in a sustainable form. The sudden change, however, and lack of grandfathering in existing users, makes it strikingly clear what's theirs and what's yours.

There are difficulties changing your pricing at any end of the spectrum:

• Increase your pricing suddenly and you infuriate your existing users.
• Decrease it suddenly and your existing users will feel like chumps for having paid more.
• Start it low, keep it low for existing users and hike it for new users, and your new users may be aware of the previous price point and ask themselves, "is this really worth that much more than it used to be?"
• Change it either way, and existing customers will automatically be forced re-evaluate your company's value proposition and may decide they no longer need you for that price.

Once your price is set, you've set a jumping off point in your users' minds. This is something that can act as a benefit - Apple, for example, plays the price point game very intentionally and quite perfectly  - but if you don't take this into consideration when pricing your startup's product you're going end up annoying a lot of people and angering your early adopter base, whom you most need to be Earlyvangelist's about your product. Ballpark your pricing strategy correctly, otherwise you might end up with metaphorical Internet torches and pitchforks running up the hill.

Jeff Atwood, in the fantastic development blog Coding Horror posted a question a while back:

Let's say, hypothetically speaking, you met someone who told you they had two children, and one of them is a girl. What are the odds that person has a boy and a girl?

 In Jeff's mind - as he goes over the next day - the question has a lot to do with probability, and if you factor in the conditional probability that someone has both a boy and a girl given that one of the children is a girl, the answer is 2/3. Or, as one of the commenters from the first post brought up - the answer could be 1.0. After all, who would tell someone 'I have two kids and one is a girl' and not mean that they other one is a boy?

The solution, of course, depends on who's asking the question and what kind of question are they asking. If this was a riddle and not a probability question then the answer would have been different. In this case (while he doesn't explicitly write "this is not a trick question") Most people correctly got the idea that he was looking for a mathematically reasoned response.

The same ambiguity can occur in client-driven development - oftentimes a client comes looking for a specific answer, but there might be two different ways to solve the problem depending on some additional criteria they aren't telling you about. Make sure you are solving the problem the client wants solved and not the one you want to solve.

Oftentimes clients think they are looking for certain features, but the truth of the matter is that they are actually looking for certain results - for example, allowing people to see upcoming events, but they've clouded the results that they are looking for with features that they've seen somewhere else. User Stories need to drive development, not a list of client-written specifications with features.

This is one of the reasons that I like custom development so much then using stock solutions - maybe the best solution to the problem isn't necessarily the one that's out there that the client has already seen. While the functionality or end result might be the same, other factors may dictate a different solution.

Let's take a simple list of events on a website - how should that list be displayed? A standard table format might work if there are only a couple of events, or a fixed size calendar if there's maximum one event per day, but how about maximizing screen real-estate when there are a number of events interspersed throughout the day? A fluid calendar would probably be the way to go but does make the page less structured any makes it more difficult to analyze schedule openings.

The best solution might depend crucially on the size and distribution of data set your client is going to have as well as the amount of processing power you have at your disposal - giving your users the ability to view a set of data from any angle is fine as long as that data set stays small, but once it grows beyond a certain size your database is going to slow to a crawl on any non-indexed search or sorts.

The long and the short of it is - make sure you are answering the question the client is asking, sometimes you need to ask a couple extra questions to get at the appropriate solution, otherwise you'll end up with a absolutely striking, beautifully coded 10,000+ line event system for you client's once-a-year open conference (Which is what we almost ended up building for someone before we asked some additional questions.)

Note: this post takes the iterative nature of software development for granted. As a consultant on dozens upon dozens of Web projects, I take it for granted. If you have had great experiences in complicated projects that go from specification to completion without change, I've never met you but I would love to as you sound like a mythically perfect client.

So you've got to get a project done that needs outside help. Whether it's for a corporate site or your next change-the-world idea, the normal sequence of events from this step is probably:

1. Write up a Specification
2. Put out a Request for Proposal
3. Look over the responses
4. Of the responses from reputable looking companies, pick the cheapest

Number four might get more complicated if you are working with companies you already have a relationship with, but the bottom line usually comes down to finding the right balance of price and security. How much are you willing to wager on your project's success to get a cheaper price.

Now let's take a look at this from the perspective of the consultant. I assume most consultants work off a standard hourly rate, estimate the number of hours and other costs (software, hardware, etc) and come up with a quote.

For inexperienced consultants, the number of estimated hours is usually a vast underestimate of the actual time it takes to complete the project. For experienced consultants, it's usually a significant overestimate of the time.

In the former case (and I've been guilty of this) the estimate is based on a best-case-scenario that fails to account for the risks of the project. It's a if-everything-goes-right number. Developers are a cocky bunch and tend to see the world through rose-colored glasses right up until the first bug. In the real world rarely does everything go right, and if the project is done at too low of a number, disaster will ensue.

The consultant will be motivated to triage features on the project because once they have gone over the number of hours estimated, they will essentially be losing money for every additional hour of work time. Since all good software development is iterative, it is a given that there will be new requests from the client based on feedback from prototypes that weren't part of the spec, but are ESSENTIAL to the project being useful when it's all said and done. These will be refused or re-quoted and features that are no longer necessary, but are in the Spec, will be added-in.

Barring a mid-project renegotiation, one of two things will happen: first the project might degrade into an acrimonious battle of wills back and forth as both the developer and client becomes less and less flexible, the former trying to do the minimum as outlined exactly in the spec while the latter holding the developer to features that have no reason to exist except for their presence in the original spec. Alternatively and much more seldom, the developer will eat the costs of the additional time to provide a quality product and a happy client. While this looks like a win from the client's perspective, future projects from the client will either be turned down or vastly overestimated to prevent a repeat. Any changes to the system will need to be done by a new party (and remember, software is iterative so there will be changes), bringing a whole new set of risks into the mix.

Experienced consultants, i.e. ones who have gone through this disaster-cycle a couple of times, will see risks and dangers hiding in every crack of the specification and will base their estimate on Murphy's law, making sure their ass is covered for any eventuality. What consultant, after all, wants to lose money on a project? The risks on the consultant's side: finicky client, non-payment, etc, are just as real on the consultant's side as the clients side.

To sum up, as it stands now, someone who needs a project done has two options:

1. Underpay an inexperienced consultant and count on their goodwill professionalism to complete the project.
2. Overpay an experienced consultant

Neither of those two options should sound particularly good, so what's the solution?

Most projects, from a risk/completion versus time standpoint operate something like this:

The risk is enormous at the start of the project. It falls quickly, however, as any developer worth their salt will try to solve the projects unknowns first and foremost. If you are building real-time stock viewer, you don't build a whole website, membership and payment system before you figure out how to get and the real-time data. Thus a couple weeks into a project, a lot of risk as already fallen by the wayside. Things will either be able to work the way anticipated, or they won't. If you pay a developer hourly for the first couple of weeks, you'll be able to remove a tremendous amount of risk from the process and won't force the developer to quote a number that covers that risk. Since you don't win if the developer underquotes the project (see above), why should you lose if they overquote it?

What if, as an alternative to asking for a quote in response to an RFP, you asked potential consultants for their hourly rate and an estimate on the number of man-hours each of the chunks of the project might take along with a confidence measure of each of those chunks?

While these early estimates will be a little all over the board, you should see some convergence on the number of hours from the reputable shops and you should be able to pick out the outliers on both ends to stay away from.

Now pick a firm on the same criteria you would have originally, but make sure to request a number of smaller milestones with working prototypes. Each of these milestones, coming in at a specific date represents a certain amount of developer time. If the developer is ahead of schedule, they can add features to the milestone, if they are behind schedule then features will need to be removed, but the date for a working prototype is the sticking point.

Provided that you have workable milestones, you, as a client, will have a much better idea of how the project is progressing, and, since you are paying hourly, can iterate on changes as necessary to get the best outcome for the project. If the developer can't deliver the first milestone, it's better to know that immediately and get out of the arrangement as early as possible rather than hang onto that sinking ship all the way down to the bottom of the ocean.

At first glance it might appear that you've shifted the risk of the project from yourself to the developer, but the truth is that the risk was always on you. If the project was under-quoted, you're set up for failure (again, see above), while if it was over-quoted, you'll never see that money back (do you think a consultant who was forced to quote a flat-fee will invoice for less?)

While I've plugged it in other posts, the first few chapters of Head First Software Development from Oreilly gives a great overview of why you should do iterative software development and is very readable by anyone interested in software consulting, not just developers. If you are in charge of hiring or managing software consultants I'd very much recommend you spend a couple hours on it.

So, like I said, you don't want a fixed quote for that project. A fixed quote is heartbreak on a stack of paper. You want a great developer with an estimate, an hourly rate and a number of measurable milestones to take you to that happy place in the ether where software is delivered on budget and on time.

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.