[lostcolony]

I've seen plenty of in house projects of reasonable size and scope succeed (on time, on budget, users happy). I've yet to see comparably sized projects by consultancies succeed.

Honestly, the -only- projects I've worked on that haven't succeeded, on time, on budget, involved consultancies. I'm not saying that's necessarily the consultancies' fault, but there are perverse incentives in place, on both sides, and that favors a lot of upfront design work and CYA, rather than agility, responsibility, and responding to new information.

[ethbr0]

Accomplishing hard things internally is one problem: accomplishing the hard thing.

Doing the same as a consultant is two problems: (1) doing the hard thing & (2) finding the right internal people & getting necessary information out of them.

Consultants are better at (1) than internal teams, more often than not. (Excluding modern tech companies)

I have yet to be convinced that anyone is good enough at (2), that a more successful plan isn't avoiding it altogether

[lostcolony]

I hear you, and agree with you, except I've worked at multiple non-tech companies that still had better people than the consultants that were brought in.

I worked for a tools company and we were the ones pointing out that the consultant's solution, intended to be a consumer application exposed to the world, was not written to actually have multiple nodes for any sort of scale up or fail-over. When they added that, we were the ones that pointed out it fell over at 10 RPS and didn't recover without human intervention. Etc.

I think you're maybe explicitly thinking of internal IT groups, rather than internal software groups, and I would agree with that, because, again, misaligned incentives. IT is all about preventing change; you don't want to risk breaking key services, and so you try and ensure that every interest has a representative and that change only happens when all of them sign off on it. That is a very slow and very flawed way to create -new- things of value, and because of that, deferring all of that to a different entity makes a lot of sense. Just, that different entity can be an internal software group more efficiently than an external one, I've found.

[ethbr0]

By that definition, many places don't have internal software teams.

[lostcolony]

Yep. Show me an org with a software group that is a part of IT, subject to IT bureaucracy, and I'll show you a software group that delivers software no one wants once a quarter (or something equally as ludicrous).

Maybe a 'one true Scotsman' argument, but every 'software group' that was a part of IT that I've seen might as well be called the 'personal project group', because they spent more time working on those than they did making progress in that environment.

[ethbr0]

I think of it as people-inertia too.

If IT sucks for people who want to change things and roll out new and exciting products, most of those people will... not work in IT.

Consequently, when you're soliciting ideas from your team, there aren't any of those people to speak up.

And if no one asks "Why are we doing this?" or "What if we did this differently?", then it's much easier to pretend another way doesn't exist.

[lostcolony]

Right, and the aggregate affect it has on individuals, and that creation of a feedback loop, is useful to understand for why the culture won't change. I'm just listing out how the initial expectations and organizational incentives in IT tend to run counter to what is needed in software. IT you don't -want- agility, and so you purposely structure your org to make change as difficult as possible. Software development that gets structured that way tends to be developed very, very slowly, and with no real user feedback. IT basically mandates waterfall approaches, decision by committee, and dilution of responsibility.

[pantulis]

I'd also add doing not only the hard thing, but also the non-sexy thing.

[mechEpleb]

In house there's less incentive to underbid and overpromise