Fast, Cheap or Good; Pick Two.
A failure to pick only two from this list is a common trend in web development, whether in external shops or internal teams, and is almost always a recipe for disaster. It’s also entirely human.
(Very) Long version:
I’m starting this new series with arguably the most self-evident topic. The underlying message of the mantra: ‘Fast, cheap or good; pick two’* is not likely news to anyone in web development, but it is one, in my experience, that is often subjugated — or, more accurately, the attempt is made to subjugate it — to the demands of a particular client or project.
First, an explanation of how I understand the various breakdowns of this ‘pick two’ mantra:
- Fast + Good = More Expensive
- Generally speaking, this is the way projects are desired. A client wants an awesome new project and he or she wants it done yesterday. This is possible to achieve, but only if the development team or shop is capable of effectively scaling up its work force while breaking down its deliverables. While the latter ability is the sign of a good team, the former is not a common attribute of current web shops, because of the financial overhead and flexibility it would require, and it is particularly not likely with internal teams, who are often explicitly restricted from on-demand hiring**.
- Fast + Cheap = Lower Quality
- This, unfortunately, is where most projects end up, despite all the best intentions to squeeze ‘Good’ into the first half of the equation. In some cases, the lack of ‘Good’ is only visible in hindsight (bug-fixes, ongoing maintenance, etc.), but it is still very much present and takes a significant toll (financial, reputational, morale) on the client, the shop/team and the individual developers. In most cases, however, the greatest impact is on the individual members and often leads to burnout, poor morale, lower quality and high turn-over.
- NOTE: Cheap does not mean ‘rock bottom’, but rather a reasonable — rather than aggressively competitive — price for the good or service. In this case, ‘Cheap’ is in contrast to the expense of getting top quality work at this higher rate of speed.
- Good + Cheap = Slower Result
- It’s clearly my position that this is where most projects should be. Of course, it is a very rare combination, and it has its own drawbacks. I prefer it because it often means the client is aware of the scope of the request and has adequately planned for it internally. It also gives the development leadership adequate time to assess the project and identify possible weaknesses and roadblocks, as well as innovations and enhancements. Finally, it allows the individual developers the luxury*** of finding the best way to code and design the solution.
- The main drawback is the most serious of all: Cheap. External web shops need income to survive and internal web teams need to show a return on investment against their budgets. Remember, though, that ‘Cheap’ is relative here and does not mean working for peanuts.
These descriptions are a bit over-simplified and there are always exceptions, but the essentials are valid, in my experience.
Previously, I had been abuzz with the excitement of the ‘early’ Internet and the Wild West-style possibilities it promised. Dynamic customization? On-demand video? Anything was possible.
More specifically, we could build it.
And in the buzz of that wondrous excitement, I bought into that view wholeheartedly, going in early because I’d thought about a new way to design or fix something overnight and couldn’t wait to get started on it, and staying late because I could finish off this thing or that one with just a little more time or I’d discovered some cool new code or process that would make everything easier once I figured it all out.
That company was filled with some of the most brilliant, passionate, funny and engaged people I have ever had the luck to work with, and I went from FrontPage fumbling to code junkie and database manager, working on some truly impressive projects for clients that included several major Fortune 100 businesses.
Still, the company did not survive the dot-com bust.
Certainly, there were many factors that led to this and that company was by no means alone in its fate, but over the years (and with repeated confirmation from my employment in institutions of all sizes) I have realized that web development — and the implementation of technology as a whole, in fact — habitually suffers from an inability to ‘pick only two’.
Not surprising, really. The modern world of business has, in fact, pushed the idea that consumers should expect products at the moment they desire them (fast), at the lowest possible price (cheap) that answer their needs (good). This expectation is inherently at odds with a number of things, including quality, longevity, sustainability, the consideration and appreciation that can come with the delay of gratification, and the recognition of the costs and skills necessary to produce the products.
Leaving out the larger social issues above — which have been addressed more effectively (and depressingly) elsewhere — this unrealistic expectation has impacted web development by often creating a dangerously self-cannibalizing environment. In this day and age, clients demand great results at the lowest possible cost with the fastest possible turnaround, pushing web developers (whether internal teams or external shops) to accept these (often impossible) constraints or lose the contract.
It’s easy to point a finger like this at clients and their ‘unrealistic’ expectations, but I would argue that there are two other entities of equal responsibility: the leadership of those web development shops or teams, as well as the web developers themselves.
In my experience (and I will readily admit my own early role in this arena), leadership tends to fail when it does not adequately staff its team. In some cases, this is due to the unavoidable financial constraints of a struggling business or weak market. More dangerous, however, are the cases where the leadership works from a mis-guided or over-zealous (or both) interpretation of the ‘work smarter, not harder’ mentality.
This last perception, however, is not solely a failing of the leadership, but of the individual web developers themselves. Again, I count myself among the worst offenders, here. Whether it’s because of a passion for the work or a fear of being laid off, web developers tend to enable (and sometimes actively encourage) the unrealistic demands placed upon them.
When I grabbed a couple hours of sleep under my desk during a 3-day ‘all hands’ implementation, I didn’t just hurt my personal life****, I all but told my supervisors that I was ready and willing to make that sacrifice as they deemed fit.*****
Aside from the personal cost and the foolishness of setting such a poor work precedent, however, was the fact that the work I did during those stretches was far from my best. Research has shown that such ‘candle-burning’ kinds of effort generally produce significantly worse results in the long term, often requiring more time (and money) spent on QA, bug fixes or developing workarounds for last-minute ‘shortcuts’, than would have been consumed with a more methodical — and slower — approach.
As I mentioned before, this is nothing really new.
So why do we do it?
The easy answer is financial or business realities. It is accepted that in difficult times, one must commit to whatever a client desires, because that client can easily go to another development shop willing to charge less or promise a faster turnaround. If we want the business, we sometimes need to be willing to sacrifice our perfect****** ideals.
This is certainly a reality of doing business in a society like ours, but, in my opinion, this is often only symptomatic of some deeper reasons:
- Poor planning
- Resistance to change
- Heroes Like Us
Most obviously, poor business planning can put us in the position of needing to do whatever it takes in order to survive. I’m a big believer in ‘life happens’, and it happens to businesses too, but proper planning for worst cases can drastically minimize the impact of such situations. For better and for worse, however, we’re human and prone to short-sightedness.
For me, resistance to change is the most frustrating, as it often takes the form of leadership that expects to wring every last drop of productivity from a team. This can be achieved by using a poor economic environment to demand more work (or risk getting laid off), by charismatic incentivizing of unsustainable work expectations, by hot-and-cold manipulation of personal loyalties and guilt, or by various other means, but whatever its form, it generally stems from a refusal to invest in long-term success.
Finally, and perhaps most dangerously, many developers like being heroes. There is something deeply satisfying about proving the impossible to be possible. It’s one of the reasons this field in particular is so exciting. What was impossible yesterday is old news today; what is unknown today will be on tomorrow’s to-do list.******* However, this desire to ‘reach the unreachable star’ directly enables both of the previous items, making developers their own worst enemies.
In the end, though, none of these reasons is good enough. Obviously, businesses that don’t plan ahead or who refuse to invest in their teams are, at best, gambling with their futures, but I also believe that businesses dependent upon individual ‘heroes’ are setting themselves up for failure.
With the benefit of hindsight, I believe the failure to ‘pick only two’ from Fast, Cheap and Good was the core of the demise of that company I worked for early on. Despite an internal awareness of the mantra and its value, the decision was often made to grab all three, primarily because we had such a passionate and committed (read: heroic) team. Certainly, other factors played a role (financial issues, economic downturn, etc.), but I believe this was the core.
‘Going the extra mile’ is certainly not inherently bad and pushing ourselves to achieve new heights is a fundamental human trait and can yield striking discoveries. If it becomes habitual practice (and even expectation) instead of occasional exception, however, it undermines itself. Not only is it unsustainable, it results in a thinly-veiled race to the bottom, which serves no-one.
So, Bill, after all this babbling, your great insight is for us to tell clients that their projects will take much longer than they expect and that they should pay the same price for them?
Well . . . yes.
No wonder you’re looking for work.
Fair enough, though I would argue that that doesn’t necessarily mean it’s a bad idea.
Have we mentioned that you’re still looking for work?
I didn’t say it was a popular idea.
In my experience, though, the best (and perhaps only) way to fix this, is to become genuine partners with our clients, rather than just the executors of external demands. This is an enormous hurdle, particularly for internal teams, but it is no less than critical to the long-term viability, productivity and creativity of all involved.
Which, unfortunately, will have to wait for another post, because I still have some story writing to do and this took far more time than I intended. Still, if this didn’t bore you silly, drop by next week.
* In a future post, I will discuss an alternate (and potentially more dangerous) version of this: Fast, Cheap and Easy.
** The pros and cons of out-sourcing IT are a topic for another day.
*** I think it’s telling that I have to use the word ‘luxury’ to describe this situation.
**** Amazingly, she stuck with me and even married me!
***** Perhaps you are asking why I chose this field if I’m just going to complain about the way things are. I would ask why you think this should be ‘the way things are’.
****** I’ll take a look at the benefits and pitfalls in pursuing perfection in another post (aren’t you excited?)
******* Again, I must admit to succumbing to this appealing fallacy more than a few times. To this day, there’s nothing more encouraging to me than to be told a thing is impossible.