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