How to Work With a Contract Web Developer: Picking A Platform

Ask a software developer why they use the language and framework they do, and more often than not you'll get a passionate, solidly-formed opinion. But it probably won't be helpful to you when trying to decide what platform you want to pick for your new project.

Developers love technical details, and sometimes forget the business context behind those technical choices. This post is my attempt to shed a little light on the subject.

First, the basics. What is a language, and how is it different than a framework or a platform? For the purposes of this article I'll define them:

Language: This is the programming language that the application code is written in. The most popular languages for web development these days are Ruby, C# (c -sharp), Java, PHP, and Python. I would advise sticking to one of those unless you have a really good, concrete reason. ("It's new and cool" is not a really good, concrete reason.)

Framework: Web applications tend to have a lot of infrastructure in common - the very basics of what makes an app work. This is the framework. Frameworks exist to give developers a common place from which to begin their projects. Examples of useful frameworks are Ruby on Rails, Django, Microsoft's .NET MVC, CakePHP, and others. Frameworks, in general, are married to a specific language. Ruby on Rails, for example, requires that Ruby be the programming language.

Platform: This is more my definition than a standard, but what I mean by platform is the combination of technologies and programing libraries that you will use to create your application. Some people might refer to this as a "stack". For example, I tend to gravitate to the following basic technologies for a new web project:

Language: Ruby
Framework: Ruby on Rails
Database: MySQL
Server OS: Ubuntu Linux
Web Server: Nginx with Passenger
Javascript Library:  J Query or Prototype

These are some pretty standard options as of this writing for a Ruby on Rails application. Different situations may call for changes, but that's the basics of it.

Now that we have definitions out of the way, lets get to how you choose one. A brand of conventional wisdom existis that says "Let your developer pick." Sometimes that may work, but for the reasons I outlined above, the developer working on the project may be a little biased.

So what are the differences and why do they matter?

I will go out on a limb and say that, technically speaking, there is precious little difference between using the .NET stack and Ruby on Rails. Java, Python - they all get the job done. Technology is not what you need to be worried about.

What you should instead think about are the people behind the technologies. Each platform has a certain culture that tends to attract different sorts of personalities. I'll risk being overly general and categorize platforms as either "startupy" or "enterprisy".

In the startupy category I'd put PHP, Ruby, and Python. These languages tend to be favored by independent developers and startups. They are quick to work with and flexible. These open source languages are supported by volunteers and rely heavily on devoted enthusiasts to maintain and improve them. As a result, some features are more mature than others. Ruby is the newest of these dynamic languages, and anecdotally, I would say it's growing at the fastest rate with the startup crowd. This is almost entirely due to the popularity of Ruby on Rails, a framework that preaches convention over configuration and a practical approach to development.

I'd put Java and the .NET MVC framework in the enterprisy category. These are well supported languages/frameworks that are backed my major corporations for use by other major corporations. As a result, you'll find lots of support through official channels. A significant note: Microsoft's products are not free. Pretty much everything else is.

Often, you'll hear developers who prefer the startupy languages complain about the bloat of the enterprisy ones. The other side of story is that you'll hear proponents of the enterprisy languages complain about the relative lack of discipline and scaling challenges inherent in the dynamic languages. Again, none of this matters.

You will find it much easier in today's market to find a Rails developer willing to work as a freelancer or at a startup. The Java and Microsoft developers tend to gravitate towards large, established companies. Good developers are in demand, so you don't want to make it hard on yourself by selecting a platform that makes it even tougher to hire.

As I said, at Ninth Yard, we use a plain vanilla version of the Rails stack. It may be the best thing for your project, or it may not be. Just remember - pick people, not a platform.

How to Work With a Contract Web Developer: Agile Scoping

So I've just discussed the importance of engaging a web developer in an Agile process. Everything should be fine now, just iterate quickly and actively and it will all work out. Right?

Well, I left out one important piece of information. Reality has a way of getting stuck in the gears from time to time. It's the thing that Agile proponents don't much like to talk about: billing and contract scope.

As a client, you want a web site. You'll pay a fair price for it, and you want to know what that price will be up front. That, to me, sounds like a very reasonable proposition. The alternative is hourly rates, which have some problems:

• Incentives are misaligned.  More work equals more pay for the developer, but not necessarily more product for the client. There is more than one way to skin a cat, and some of those ways take more time.
• Expectations are not agreed to. How long is this going to take, anyhow? If you don't nail down some specifics, you will have a project that will end when the money's gone, finished or not.

I'm a believer in defining the scope of a project before starting and putting a fixed price tag on it. This keeps the project to manageable, finishable scope and encourages the developers to work smartly.

The astute reader will realize that this advice is in direct conflict with my last post on keeping things Agile. And you're right.

More to the point, this is an area that requires some finesse. In exchange for some tangible benefits (a solid scope and a better alignment of the client and the developer), we generally have to sacrifice some Agility. We can nail down the obvious big issues, but still remain Agile about which of the smaller issues get our attention and when they get it.

Here's the process I use.

Client Homework. You, as a client, need to do your homework before I get involved. You need to have thoroughly thought through the problems you are trying to solve. Put more concretely, you need to have created some wireframes of what you think the site will end up looking like (functionally, not aesthetically). I like to use Balsamiq Mockups, but Powerpoint, Visio, Omnigraffle, or just pen and paper are fine too. These mockups should be complete. All of the important views need to be drawn with all the buttons in the right places. Text and copy can be rough, but there should be something there. 

Walk through the wireframes, imagining that you are using the software. Click here. What happens next? Run through all the most common scenarios you can come up with and adjust your wireframe to suit what you've learned from your thought experiment. If you need help, check out Don't Make Me Think: A Common Sense Approach to Web Usability
or the voluminous information at Jakob Nielsen's site. Another good rule of thumb for user interface (UI) design is to look at how Apple or Amazon handle similar issues. There's a good chance they've come up with a very good solution.

And now, the important part - the part that requires a mental shift. Understand that you will not be getting this product. The purpose of this exercise is to understand the problem at a detailed level before you get started, not to spec out a web application. You will find some concepts that are critical to the product, some that might be useful, and some that really don't need to be there at all. But you must understand and embrace this point: 

 This is not a requirements document. It is your vision, written down.

This education process, which you should share with your contract developer, will allow both of you to gain the insight into what the scope of the project will turn out to be.

Developer Homework. Next, you need to thoroughly communicate your findings to the web developer, and come to an agreement about pricing and timeline. You will have put enough thought into the product so that you will be able to come up with some rough time and price estimates, even though you know the product will evolve in development. At this point you must both commit and name a price, a deadline, and an outline of the critical features. The deadline is especially important and must be a hard date to launch the product.

Get to Work. Now that you have a price and a timeframe, it's time to get to sign a contract and get to work. Expect to meet with your developer at least once a week, sometimes twice. Expect to work almost as much as the developer does. You will need to redraw interfaces that don't work like you thought they would. You'll test and retest the live application (there will be something live to test within a few days, and every few days after that). Your experiences will cause some of your features to shift in priority and in form. That's not only ok, it's expected and good. It's all part of the process.

Over time, the product will mature and the deadline will creep up on you. Pay attention to it. The knowledge that your developer time is running out will be a great motivator to build what is important, use the simplest solutions, and ignore the fluff. This is a critical piece of the Agile puzzle. You cannot be Agile without constraints. Even you're not under any particular time pressure, pick a hard deadline and stick to it. I cannot stress this enough:

DO NOT MISS YOUR DEADLINE

Launch. If all has gone well, you'll have a product that is minimally sufficient come launch day. Launch it. Tell your friends to try it.

Post Launch Work. You will also probably have a few "must have" features that are missing that the developer committed to. That's ok and normal. Just add them after launch. You and your developer should have budgeted some time for post launch activities. This is when you fit in the stuff that took a little longer than you might have thought. It's also when you start listening to your initial users. You will undoubtedly learn something right away that will make you want to change something. Do it now.

Contract End. At this point,  you'll have a working, but imperfect application that you can use to start testing your market. If you take a look at your original wireframes, you'll probably find that some parts your new product look just like you drew them, and other parts are a bit different. There will probably be some features that didn't get built, and some that were built that aren't on your wireframe.

In practice this a typical contract might be scheduled for four weeks of pre launch work, followed by one week of post launch work, and consist of a fixed price tag and a high-level, but specific list of "must have" functionality.

There are some risks inherent in this method. It requires a degree of trust. It won't work, for example, if you, the client, are intent on squeezing out as much work as humanly possible from this one contract. It also won't work if the developer is intent on doing as little work as humanly possible on this one contract. It requires a professional partnership-style attitude on both sides of the deal to work. By the end of the contract, you should both want to work with each other again - so keep that in mind during the contract. Choose the people you work with very carefully. If they can't or won't understand a part of this process, don't even get started.

Is this Agile Utpoia, where products freely evolve until they achieve greatness? No. But it's about as close to it as you'll get without an open-ended, hourly contract. (Which, by the way, can work. It's just that it requires even more professionalism, interpersonal understanding, communication, and trust than the process I've laid out. It's more suitable for a second contract with a proven partner.)

Up Next: Picking A Platform

How to Work With a Contract Web Developer: Agile is the New Average

You may have heard the phase "Agile Development" and wondered what it means. You need to know before you hire a contract web developer.

Once again, I'll go back to my days as an aerospace engineer working on space shuttle launches for some background. Planning and engineering a space shuttle launch is a long, tedious endeavor that takes lots of people time, and money. Everything is mapped out in as much detail as possible at the earliest time possible. The reason for this is obvious - you can't afford to wing it when something as simple as machining an aluminum mounting plate takes 10's of thousands of dollars and several weeks. How long to you think it takes to build a camera that can look back 10 billion years?

And the requirements... so many, many requirements. There is a spec for everything because everything matters. Is the honeycomb panel strong enough to withstand a wayward kick from an astronaut? Will the handrail be too hot for him to touch? Where is the sun anyhow? What about those bolts? What happens if the astronaut can't loosen them? What happens if he can loosen one, but not another, and the first one floats away into space?

Lots and lots of requirements. Lots of planing, and then the work begins. It is a slog. It's slow, expensive, and still doesn't prevent the unexpected. But given the constraints, it's not a bad way to launch a space shuttle.

Back in the "old" days, they made software this way too. Everything was spec'd out in advance. User interface, data structures, performance - everything. Once a project is all planned out, it gets broken up into well defined pieces for developers to work on. Sounds great, right?

In practice, it's not so great. Software is so flexible and so conducive to innovation that you almost never know exactly what you want to build before you get started. You'll have a vision - a vague idea of what the software should do, not a well defined set of specifications. I'll even go as far as to say that if you think you know exactly what you want to build, you are wrong. There is something you think you want that you don't or something you forgot that you really do need. It's just the way it tends to happen.

Aggressive and thorough pre-planning for software development is exactly equivalent to waste.

So what do you do? You use Agile methodologies. What it means in a nutshell:

1. Plan and build the smallest chunck of software that actually works, even if it falls way short of what is eventually needed. This entire iteration can be as short as a day or two. The iterations tend to get longer as more developers are added and the software gets more complex, but if they're more than 3-4 weeks, something is wrong.
2. Try it out. You, the client (acting on behalf of your customers), need to try the newly functioning software, minimal as it may be. The process of actually clicking and typing in your application will clarify your thinking and help prioritize what needs to be built next. You cannot skip this step - be prepared for a lot of work.
3. Repeat until your app solves the problem you set out to solve.

This process eliminates waste because very little effort is spent working on bad ideas before they are exposed and discarded.

As soon as the application is good enough to put in front of customers (more on what this means in a future post), launch it. Even if it's not perfect. If it's perfect, you waited way too long. Perfect is the enemy of progress.

The truth of the matter is that the application you launch won't be quite right. Your insights, no matter how much domain experience you have or how much thought you put into the product, will not be enough to create a great product right out of the chute. Even a paying customer won't help much - customers are terrible at providing specific guidance.

But how can you launch something that's wrong? Isn't that business suicide? No. Not when you're iterating quickly. Your beta application won't be totally wrong - just kind of wrong. As soon as it launches, your users will become your allies in the "Try it out" phase of the cycle. Listen to them, interpret their specific needs, and make a decision on how to improve things. Nothing is that big of a deal because the next release is just a few days away. If your product gains traction, this pattern will never stop - you keep improving and testing and listening. Over and over and over again. Software development is a journey, not a destination.

This is the face of modern software development. Embrace it. It works.

Coming next: Agile Scoping

How to Work With a Contract Web Developer: The Better-Cheaper-Faster Myth

Once upon a time I was a young aerospace engineer working on NASA's Hubble Space Telescope project. A typical shuttle mission, if there is such a thing, took about three years to plan. Hundreds of companies, thousands of people, and billions of dollars were stirred up with a healthy dose of governmental help. All for a total of five or six work days during which over-qualified astronauts fixed the aging telescope.

A common truism repeated by engineers was "Good, Fast, Cheap - Pick Two." Of course, that common refrain was at odds with the official NASA slogan of "Better, Faster, Cheaper". As is often (but not always!) the case, the engineers were right. Attempts to reign in costs always failed as the consequences of cutbacks began to show themselves. Demands for quality were continuous and proper - we're talking about huge amounts of money, not to mention human life and national pride. Giving up "Good" was not an option. That left Fast or Cheap on the chopping block. What usually happened was some things got done fast and other tasks were done cheaply (by government standards, at least).

They were right about human space flight, not web applications. The NASA engineers neglected a fourth variable - scope. A space shuttle mission's scope is rigid. You must launch the payload and the astronauts must be able to fix the telescope. End of story.

That is not true for a web application. If a project costs too much, you can almost always drop a feature. If that makes the feature set insufficient, you can reduce the quality. If the quality is too low, increase the time. If it takes to long, you can pay for more developers.  So what should give? How do you address this balancing act?

In practice, some of these variables are easier to change than others. It is difficult to speed up development by adding money, for example. Software development just doesn't work that way. Real life budgets are usually constrained, as well.

Similarly, there is a minimum acceptable scope. It's been popular recently to call this the Minimum Viable Product, but that's pretty much buzz-word-speak for "the simplest product that will solve the problem it's aiming to solve."

Building a minimal product is not the same as building a low-quality product. If quality dips too low, maintenance costs more, future coding is slower and more expensive, and the overall user experience suffers from outages and other weirdness.

So we typically have a minimum scope, minimum time, maximum budget, and minimum quality level.

No project should ever be started unless all of those constraints are acceptable to both the principal and the contractor. If there isn't a viable sweet spot where everything works, someone is going to be disappointed. This requires discipline, careful thought, and an honest look at reality. Nothing is going to be ideal, so get that out of your head right now. Building software is about balance and tradeoffs. Not even truckloads of money can change that.

Coming Next: Agile is the New Average

How to Work With a Contract Web Developer

I often hear business owners or entrepreneurs lamenting the difficulty of hiring and working with contract web developers. Common complaints are "not enough contact", "they're hiding the coders from me",  "too slow", "too expensive", and "nobody comes to this website I paid a fortune for".

As a whole, we contractors can be doing a lot of things better. But clients have a role in this too. I would argue that the trend towards agile software development has increased the role of the principal. No longer can you just throw a spec sheet into a darkened cubicle, kick back, and wait for your software. Not if you want good software, at least.

There is a lot to the principal-client relationship. It's critically important that both parties hold up their end of the bargain. If either fails, the result is a lousy product that winds up over-budget and late.

I'll be writing a series of blog posts on this topic in the coming weeks. It's a lot of material to cover, but I hope that anyone who wants to hire a web developer will gain some knowledge that just might save some time and headache.

Enough of the intro. On to the goods...

Next Up: The Better-Cheaper-Faster Myth