Hacker News new | ask | show | jobs
by wpietri 2061 days ago
I think it depends a lot on the companies involved. From what I've seen, things usually fall along a spectrum from "fixed bid" to "time and materials". With the former, the company that wants the software puts together an explanation of what they want and then asks vendors to submit a price. With the latter, the vendor promises to provide X number of people at a rate of $Y for as long as the project goes. In between you'll find a lot of arrangements with various levels of guarantees for what's done when and for how much.

The essential problem is risk. From the client perspective, they don't know what's legitimately hard or how good the devs are. From the vendor perspective, clients never know what they want and may not pay even if you give it to them. And software projects frequently blow up; according to HBR, 1 in 6 have a 200% cost overrun and a 70% schedule overrun. Frequently expected business benefits don't materialize for reasons that are hard to determine. When that happens, neither side wants to be left holding the bag.

This is complicated by the fact that dev firms generally have fixed expenses (salary, rent, overhead) and variable income. They need to get maximum dollars out of every programmer hour if they want to make a profit.

The opaqueness leaves a lot of room for bad behavior on both sides. For example, I heard of one Accenture software project for a company that had a bunch of very fixed deadlines with their customers. Accenture sent in some very smart, senior people who produced a very pretty bid with lots of text and diagrams, and their skilled salespeople sold the work for $5 million. How would it be charged? I forget the exact numbers, bu roughly: the very smart, senior people would be $4k/day, and the junior people would be $2k/day. But Accenture sold them on a "blended rate" where they'd forget about nickel-and-diming the client and just send in the right people at the right times for a mere $3k/day. Of course, Accenture then flooded the project with younglings (who Glassdoor is saying get paid $50-$60k [1] these days). As you might guess, the project then fell behind the initial rosy predictions. Once the client was starting to sweat their hard contractual deadlines, Accenture then said, "Oops, the $5 million is all spent. Nothing works and we're going to go. But if you'd like we'll stay and actually finish it for another $5 million." The client didn't have any choice, so they paid up.

And there's plenty of bad behavior on the client side as well. I've heard of plenty of projects where the client asks for X, and when you deliver X, they say, "Well that's not what we wanted." Which is surely true, in that people often don't ask for the exact thing they end up wanting. So the client suddenly refuses to pay a dime until they get what they do want. For a dev shop that has been paying salaries to a bunch of programmers, that can be anywhere from scary to disastrous, because they're legally obliged to keep paying salaries no matter what the client does.

So I don't think there's a simple answer here. Honestly, the revenue model of some dev shops are things like "underbid and then bleed them out on change fees" or "promise geniuses and then load projects up with the cheapest goofs you can find" or "invest heavily in sales, overpromise wildly, and egregiously overwork your devs" or "underbid on the initial work, produce a snarl of spaghetti code that only your devs can maintain, and overcharge for years of ongoing maintenance".

I've known a number of reasonable, honest, conscientious devs who have tried setting up software development firms. They just wanted to do good work for clients, treat their people decently, and make reasonable profit. All of them have struggled, losing out on deals to people who were much better at gaming the system to make money.

Having been on both the hiring side and the contractor side over my career, the main thing I've learned is that I'd rather avoid it, as the incentives can so easily produce perverse outcomes.

[1] https://www.glassdoor.com/Salary/Accenture-Entry-Level-Softw...

2 comments

I find your comment very accurate of the status quo when you look at dev consulting companies at large.

The funny thing is: I started my software engineer career working for a large consulting firm and my frustration with the whole game was exactly my motivation 15 years ago to start my own business. I wanted to create a company that was 1) fun place to work for devs and 2) that was able to deliver on time and on budget on every single project (I'm obsessed about customer satisfaction).

15 years later and many many projects later I think I have definitely succeeded in my goal. So I think I have proof that software consulting doesn't really have to be that way. I can be fun, profitable and beneficial to all parties involved. We never had to hire a single sales person until 2020 because word of mouth kept us going.

By the way, we work at much better margins than those listed in here (I'm too shy to say the number though).

I think a lot has to do with passion and dedication. Knowing when to say no to customers and when to call bs on their deadlines.

I have definitely lost deals to other companies with a not-so-good value proposition but in the end those same customer come back calling us once they project melt in front of their eyes. I lost count how many times that happened. At least 30% of our project are a re-do of other companies fuck-ups.

Congrats! Yes, I should have mentioned that I know some people who have made a successful go of it. And yes, some clients are capable of actually learning lessons. Glad to hear you're finding them.
Can confirm, the "just charge a lot up front for good quality" strategy doesn't work very well. In retrospect it's obvious why, the client will always find other people promising the same results for less. Actually delivering, different story. Having been right doesn't do much for your bottom line, unfortunately.

The only way to maybe make it work is to sell to people who know what they are doing, but that gets dangerously close to the "I could have done that myself easily" territory.