3 ms·

I have to agree with this. We recently replaced a homegrown webapp with its MS Dyanmics GP equivalent and headaches have increased exponentially. It's as if the

by tomc1985 10y ago

I have to agree with this. We recently replaced a homegrown webapp with its MS Dyanmics GP equivalent and headaches have increased exponentially. It's as if the system was designed to be so complex as to require a team of people to operate, plus a manager to supervise, plus a support person to field phone calls... when one guy churned out the original in a day, and ran for a year-and-a-half with only minor technical (and no major organizational) hiccups.

jasonjei 10y ago
When you write of Microsoft Dynamics GP, this FizzBuzz Enterprise Edition repo comes to mind: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
xyience 10y ago
> It's as if the system was designed to be so complex as to require a team of people to operate, plus a manager to supervise, plus a support person to field phone calls This is exactly it. Even if not intentionally designed, it ends up that way. As andrewstuart2 mentioned above, "[customers] also got the full expertise of the salesforce engineering organization (which clearly is far from incompetent) being brought to bear on the problem, at no extra charge to them as a customer". This is great I guess, but if your home-grown solution doesn't use, say, Oracle, to start out with, you're going to eliminate a heck of a lot of necessary engineering expertise when things go wrong. Break up systems even more and suddenly just one generalist can do it all on the side...
dano 10y ago
A classic build vs. buy situation where the purchase seems like the solution and in reality, it is a purchase plus development plus support. In many cases the internally designed, function specific, application is better because of its constrained functionality. Many companies, mine included, have made the mistake of purchasing a silver bullet rather than forging one with our own time, talent, and treasure.

jasonjei 10y ago

When you write of Microsoft Dynamics GP, this FizzBuzz Enterprise Edition repo comes to mind: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

xyience 10y ago

> It's as if the system was designed to be so complex as to require a team of people to operate, plus a manager to supervise, plus a support person to field phone calls This is exactly it. Even if not intentionally designed, it ends up that way. As andrewstuart2 mentioned above, "[customers] also got the full expertise of the salesforce engineering organization (which clearly is far from incompetent) being brought to bear on the problem, at no extra charge to them as a customer". This is great I guess, but if your home-grown solution doesn't use, say, Oracle, to start out with, you're going to eliminate a heck of a lot of necessary engineering expertise when things go wrong. Break up systems even more and suddenly just one generalist can do it all on the side...

dano 10y ago

A classic build vs. buy situation where the purchase seems like the solution and in reality, it is a purchase plus development plus support. In many cases the internally designed, function specific, application is better because of its constrained functionality. Many companies, mine included, have made the mistake of purchasing a silver bullet rather than forging one with our own time, talent, and treasure.