Good Fast Cheap

I work in contract software development. In my job, there are clients. Clients tend to want things done good, fast and cheap. In response to that, many software professionals would say, "pick two." I, however, say that you can have all three if you can arrive at a specific definition of "good" and implement a few principles.

Over the course of my career, I've arrived at some helpful pointers/axioms/principles:

Sometimes Good Enough is Good Enough

Many developers that I've worked with are still in the very academic mindset. This isn't a bad mindset, per se, but it isn't helpful at shipping quality software products on a tight budget and deadline. They haven't yet learned that sometimes good enough is good enough. You see, the client doesn't typically care whether you used such-and-such algorithm, or employed the latest insert-trendy-thing-here technology. The client doesn't care whether you used a "bloated" framework or the latest hot new thing. At the end of the day, what concerns them is whether you got their software done, and whether it is usable.

Other developers tend to get really excited by new technologies they'd like to try. They get all wrapped up in making sure they have solved problems that, in reality, will never happen. Academically, I get it. We're motivated by learning new stuff, and we like to think that we've engineered the thing to be bulletproof. In most cases, though, the only one that cares about being bulletproof is the engineer. The client just wants the thing to work and they want it done within their budget.

The 50 Percent Rule

A 50% finished product that the client has in there hands is 100% better than a 99% completed product that the developers are still optimizing. The lesson is, get what you can done, and get it to the client on time. They're more likely to approve additional budget if you get them something usable; something they can get excited about. You can always iterate on the remaining 50 percent and they may end up deciding they didn't need feature X afterall.

MVP (Minimum Viable Product)

When delivering a "half-done" product. Make sure it's the half they care about. Find out what features are absolutely necessary for the product to be useful and aim for that first. The rest is fluff at this point, and may not be needed at all. The most important thing is nailing down a MVP and getting it in the client's hands by the deadline.

People tend to be surprised how little they actually need for a product to be useful. They tend to get focused on how it looks or neat bells and whistles. In the end, form follows function. Get the functionality in place first. The rest can be refined later or not at all.

Use Tech You Know

As engineers and software developers, we always want to try the latest new thing. Building an MVP for a client on a tight budget is not the time to explore new things. Stick to what you know and can develop quickly with. Don't waste time building something from scratch when someone else has a perfectly good library you can use. In other words, don't reinvent the wheel just because it's fun and challenging. The client will thank you for using "boring" tech. In addition, something that's well known can be more easily maintained by others and will tend to have more support available for it.

"Right" is Relative

Sometimes, clients have their own idea of what is right or best. If you believe there is a better way, you can (and should) do your best to explain your position. Then, step back. They may disagree with you. They may demand that you do it their way. In the end, they're "right" because they're paying you to do what they asked. I suppose this goes back to the saying, "the customer is always right." They may not be actually right -- not in the academic sense anyway, and you can probably prove it. However, they are right in the relativistic sense, in that they are as "right" as the amount of money they are paying you.