the 'pick two' reality of development
I recently had a client that wanted me to help them make their site "better." After I took a look at the site and code, we sat down and I was very blunt: "Your site is made up of Frankenstein code: it's patched here and there by different developers, there's no documentation, it's a mess. I can fix the problem you're asking me to fix in about 30 hours. But in a few months, more things are going to break and you'll need to hire me or someone else to fix it again. I can rebuild your site from scratch, improve your front-end and backend, deliver a stable and, basically, future-proof product for your current and foreseen needs. It'll take me, say, 150 hours. I know you're worried about cost but I guarantee you it's cheaper in the long run." Guess what they chose.
The problem is that most clients want the perfect trifecta of having something made cheap, fast and good. In other words, the client's head is in the clouds.
So if you, as the client, choose good and fast, then I will postpone every other job, cancel all appointments and stay up 25-hours a day just to get your job done. But, don't expect it to be cheap. Choose good and cheap and I will do a great job for a discounted price, especially on a larger project, but be patient until I have a free moment from paying clients - I've got to eat, after all. Choose fast and cheap and expect an inferior job delivered on time. Unfortunately, you truly get what you pay for, and in my opinion this is the least favorable choice of the three. Not only because I make no money, but because I am forced to deliver a product that I am not proud of. The age old adage, "Time is money," is what my - all! - business boils down to. You are buying my time - and the expertise I've spent time accumulating. And that's what this triangle is based on. Returning to the client I had: while I fixed their problem, I certainly am not going to include them in my portfolio because I don't stand behind the specifically shoddy work I was hired to do. Thing is, everyone is aware of this in some form of another, because it applies to all business - from coding, to building furniture, to cooking, cars, any product based business and a lot of service based businesses too. But nobody likes being confronted with that choice when their money is on the line.
And here's where I think this model is wrong: at no time is a client ever hiring you to do a shoddy job. No matter what they say they are willing to accept as compromise in the project, they want quality. And that's the big problem, for us as developers: we want to get our name out there as people that make quality products, products that we're proud of, and so on, and we have to do that for clients that generally want to opt for fast and cheap jobs. Then, there's this:
People forget how fast you did a job, but they remember how well you did it.
— Howard Newton
So they want you to do the job fast and cheap, but if you don't deliver something good, you've lost a repeat client. Plus the referrals that they would have provided you with. And that's why I was hired to fix that site and not the person that was hired last time. And that's why I chose to be blunt with the team behind the site: because I want them to be aware of what's realistic, deliverable, and what the costs they are really looking at are. And those costs are not just the cold hard cash type - there's time lost in getting the site to work or getting it back online, work lost on the site that has to be redone, lost data, hours of frustration and headaches at errors and malfunctions that can be easily avoided. In the end, quality is the primary goal of every developer, which upends that "Fast / Cheap / Good" triangle into something called the Iron Triangle.
This becomes a more realistic depiction of what a developer is really hired to do on a project because it takes into account the fundamental problem of development: each group involved with the project has a different, often conflicting, set of priorities. Developers, designers - the people that make stuff - want to deliver a high quality product; financial people are generally interested in the overall cost and cost-efficiency; management's got its eyes on a timetable of milestones and deliverables; end users are interested in the product's scope - its features, functionality, usability, etc. Obviously these are roughly drawn stereotypes, but when each issue has a protagonist that won't budge on their position - forcing any reasonable approach to problem solving to go out the window - then the project is set up for failure.
So, as a one man team, you say, "Well, let's cut some features to meet deadlines and make sure I do a great job on the most important features." But clients are fickle and, realistically, you can only do that up to a point, until the final product no longer resembles the functionality the client originally envisioned. But they're not going the be happy unless you meet their expectations. You can cut the frills, but they still want them, or, worse, they will silently, resentfully want them. And whether they are silent or vocal about their disappointment, you've lost another connection and potential referrals. So freelance work, then, becomes a balance of what the product is envisioned to be, what resources the client has and time they give you, and your ability, which only comes with experience, to see the project scale and know whether it's deliverable or not, and in what shape.
Ultimately, I think, it behooves us, it becomes part of our jobs, as freelance developers, to subtly educate clients on what the iron triangle is and how it should really be an elastic triangle, so that communication is constant and productive, expectations are managed and kept realistic, and the product that is delivered is both qualitatively high and has the scope the client desired. That way, you can deliver a product you are proud of, something you unhesitatingly include in your portfolio. And, just as importantly, you can deliver a product that meets (and possibly exceeds) the clients needs and expectations. Oh, and all that leads to repeat clients and word of mouth referrals. Which is ultimately what we want. Yes, for those more experienced developers who can pick and choose their projects this might be nothing new, but for those starting out, this is invaluable advice to keep in the back of your mind as you build a name or brand for yourself.
Remember how I asked you to guess what the team behind the site chose after I showed them their options? Well, you probably guessed wrong: I convinced them to go for a full overhaul because the long term cost of choosing rush jobs was much higher in terms of money, headaches, and frustrations, lost time and work, and lost readers due to a malfunctioning site. And both parties were, in the end, much more satisfied with the work that was done.