Vendor applications replacing home-grown ones?
-
Projects built internally and used for few years with my last employer were replaced by some vendor tool, and I didn't want to be in the shoes to 'config' 'support' and 'wait for another patch', so I joined a different firm, but after few months i was told that the project we've been working on is going to be replaced by some vendor tool...again! Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
Member 10815848 wrote:
Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
From my very limited understanding of business management strategies (I've made it a point to steer clear of entering management), the rule* is pretty simple... If it's central to your business, build it yourself. If there's nothing out there that's close enough to what you need, build it yourself. Otherwise, just pay someone else to build it for you. So the really company-specific tools will stay in-house, and anything generic enough to be used by multiple companies will eventually become a third-party vendor tool. * I don't know if it's a rule... This is just what I've unintentionally overheard/derived over the past decade...
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels) -
Projects built internally and used for few years with my last employer were replaced by some vendor tool, and I didn't want to be in the shoes to 'config' 'support' and 'wait for another patch', so I joined a different firm, but after few months i was told that the project we've been working on is going to be replaced by some vendor tool...again! Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
I currently work as a developer writing an inhouse ERP system. I joined after a colleague had started it and then became the sole developer. Building it from ordering through to picking, despatch, invoicing and reporting functionality. The advantage is that I can create highly customised changes for each department - my boss says that our clients don't know how spoilt they are. We are however heading down the route of exploring a 3rd party enterprise ERP system. It's interesting hearing some people say how this new system is an 'all singing all dancing system' - these people are in for something of a shock. How do I know this? Because I have based the system I a writing on, the good parts of, previous 3rd party ERP systems I have worked on. The advantage of a 3rd part system is that you can pay huge amounts of money to salesmen who will promise you the sky, and tell you that you are doing things wrong in your business as they know better. The advantage of a custom system is that, if you have an experienced team, you can build something that will do most of what a 3rd party system does, and in many case more than it does, for a lot less. There is one area where 3rd arty systems tend to excel and that is in the accounting side - writing the accounting side of an ERP system is probably the most complex part and so far I have been able to avoid this - so maybe a 3rd party system is the best choice, maybe it's not...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
-
I currently work as a developer writing an inhouse ERP system. I joined after a colleague had started it and then became the sole developer. Building it from ordering through to picking, despatch, invoicing and reporting functionality. The advantage is that I can create highly customised changes for each department - my boss says that our clients don't know how spoilt they are. We are however heading down the route of exploring a 3rd party enterprise ERP system. It's interesting hearing some people say how this new system is an 'all singing all dancing system' - these people are in for something of a shock. How do I know this? Because I have based the system I a writing on, the good parts of, previous 3rd party ERP systems I have worked on. The advantage of a 3rd part system is that you can pay huge amounts of money to salesmen who will promise you the sky, and tell you that you are doing things wrong in your business as they know better. The advantage of a custom system is that, if you have an experienced team, you can build something that will do most of what a 3rd party system does, and in many case more than it does, for a lot less. There is one area where 3rd arty systems tend to excel and that is in the accounting side - writing the accounting side of an ERP system is probably the most complex part and so far I have been able to avoid this - so maybe a 3rd party system is the best choice, maybe it's not...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
This is all a very good reason to work on your sales pitch if you're a small team of internal developers. Sometimes being able to sell software to the people who hired you to write it will save your job, other times just make your job more livable. Custom software is only worth what they think it is until you show them otherwise.
-
Projects built internally and used for few years with my last employer were replaced by some vendor tool, and I didn't want to be in the shoes to 'config' 'support' and 'wait for another patch', so I joined a different firm, but after few months i was told that the project we've been working on is going to be replaced by some vendor tool...again! Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
Member 10815848 wrote:
and I didn't want to be in the shoes to 'config' 'support' and 'wait for another patch',
Not sure I understand this. Are you a developer or a network admin? If the former then if there is no more development work then normally you get laid off. If the latter then admin might be tasked with creating custom solutions but that varies a great deal.
Member 10815848 wrote:
Is this the trend?
You do of course realize that the vendor selling the product has a "home grown application"? Other than that no there is no such trend, not in any discernible way. Programmers are in demand in the US and that demand is increasing in all non-biased measurements. And there is a shortage.
-
I currently work as a developer writing an inhouse ERP system. I joined after a colleague had started it and then became the sole developer. Building it from ordering through to picking, despatch, invoicing and reporting functionality. The advantage is that I can create highly customised changes for each department - my boss says that our clients don't know how spoilt they are. We are however heading down the route of exploring a 3rd party enterprise ERP system. It's interesting hearing some people say how this new system is an 'all singing all dancing system' - these people are in for something of a shock. How do I know this? Because I have based the system I a writing on, the good parts of, previous 3rd party ERP systems I have worked on. The advantage of a 3rd part system is that you can pay huge amounts of money to salesmen who will promise you the sky, and tell you that you are doing things wrong in your business as they know better. The advantage of a custom system is that, if you have an experienced team, you can build something that will do most of what a 3rd party system does, and in many case more than it does, for a lot less. There is one area where 3rd arty systems tend to excel and that is in the accounting side - writing the accounting side of an ERP system is probably the most complex part and so far I have been able to avoid this - so maybe a 3rd party system is the best choice, maybe it's not...
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
GuyThiebaut wrote:
The advantage of a custom system is that, if you have an experienced team, you can build something that will do most of what a 3rd party system does, and in many case more than it does, for a lot less.
Of course the reality is in the details. Such experience must not only include the ability to throw code but also the ability to gather the requirements in the first place and design the system. None of that is a given. And the same points apply to the creators of the 3rd party application.
GuyThiebaut wrote:
There is one area where 3rd arty systems tend to excel and that is in the accounting side
I worked for a company that sold only software like that. Financials, Inventory, etc. In a training session I came to realize that a couple of customers were discussing the best price for pallets of hard drives. So they could run this software. It ran on big iron and took a week just to install. Months to configure with help from the company. The software was a nightmare. And so was the development process. But provides good stories. Best memory from that was a meeting where the VP of my group (50+? developers) was lauding the efforts of one developer who had written his own interface between two systems. This was rather amazing to me because I knew that there was team of something like 5 different developers who had been working for several months to create exactly an interface like this.
-
Projects built internally and used for few years with my last employer were replaced by some vendor tool, and I didn't want to be in the shoes to 'config' 'support' and 'wait for another patch', so I joined a different firm, but after few months i was told that the project we've been working on is going to be replaced by some vendor tool...again! Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
I think 3rd party developers may not understand your business, but there sure good at creating easy to use interfaces that everybody can understand with little or no training. So as long as the code is rock solid and fast running, little or no attention will be paid to the underlying code. Employees want to feel or be computer savvy, and if they can't look at the program and use it right away, then the program is considered defective or trash. I make 3rd party software, and it's been a battle to dumb down the user interface for all to understand. It's an art form like making those phone apps. Plus the perception of speed counts as well, its a psychological battle in creating interfaces that flow constantly showing fast action to win the speed battle. Overall in the end, it boils down to how fast can an employee master the program, and use it as an effective tool day in and day out, and never complain about it. Regardless of who made them, apps don't last forever, and they have limited life spans.
-
Slacker007 wrote:
It has been my experience that there ends up being insufficient time and hours to maintain home-grown apps. Usually, homegrown apps suck, whether we want to admit it or not and are in constant need of maintenance or fixing.
Aren't you basically buying a home grown app, somebody elses albeit. The only difference is that you are at their mercy if something needs fixed or it doesn't quite fir your needs.
New version: WinHeist Version 2.1.0 Beta Have you ever just looked at someone and knew the wheel was turning but the hamster was dead? Trying to understand the behavior of some people is like trying to smell the color 9. I'm not crazy, my reality is just different than yours!
Microsoft Visual Studio is a home-grown app. The piece of crap file parser I wrote last month is a home-grown app. Which one do you think is going to get more attention and love. Probably the one that brings in the money versus the one that just makes my life a little easier. Semantics. :)
-
Microsoft Visual Studio is a home-grown app. The piece of crap file parser I wrote last month is a home-grown app. Which one do you think is going to get more attention and love. Probably the one that brings in the money versus the one that just makes my life a little easier. Semantics. :)
The difference is that uSoft had a team that worked on VS as opposed to a single person. Therefore they need to make a butt load of money on it to recoup.
New version: WinHeist Version 2.1.0 Beta Have you ever just looked at someone and knew the wheel was turning but the hamster was dead? Trying to understand the behavior of some people is like trying to smell the color 9. I'm not crazy, my reality is just different than yours!
-
Homegrown software sucks and is in constant need of maintenance. 3rd party software sucks and constantly needs fixes from 3rd party. Software sucks.
harold aptroot wrote:
Software sucks.
:thumbsup:
-
The difference is that uSoft had a team that worked on VS as opposed to a single person. Therefore they need to make a butt load of money on it to recoup.
New version: WinHeist Version 2.1.0 Beta Have you ever just looked at someone and knew the wheel was turning but the hamster was dead? Trying to understand the behavior of some people is like trying to smell the color 9. I'm not crazy, my reality is just different than yours!
I hear you Mike. :thumbsup:
-
Projects built internally and used for few years with my last employer were replaced by some vendor tool, and I didn't want to be in the shoes to 'config' 'support' and 'wait for another patch', so I joined a different firm, but after few months i was told that the project we've been working on is going to be replaced by some vendor tool...again! Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
Basically what Ian said is the way the foundation I work at does things. For things that are unique to the organization we do custom development, other stuff we buy and integrate. Our HR, Finance, intranet, reporting, main website are all customized 3rd party apps, but our grantmaking and scholarship tools are all custom built.
Curvature of the Mind now with 3D
-
So as developers who want to do development, what do we do? join the 'vendor' company? :-D
Member 10815848 wrote:
So as developers who want to do development, what do we do? join the 'vendor' company?
That won't do any good, because most vendor software now is just a bunch of cobbled-together frameworks.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Projects built internally and used for few years with my last employer were replaced by some vendor tool, and I didn't want to be in the shoes to 'config' 'support' and 'wait for another patch', so I joined a different firm, but after few months i was told that the project we've been working on is going to be replaced by some vendor tool...again! Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
A lot of it depends on how critical is is for the logic to stay in-house. If one of the functions of your business is producing documents, you aren't going to build a word-processor, because the logic of word-processors themselves is trivial to your business; but if you need software that, for example, models stuff or performs predictive calculations, (portions of) the logic of the work to be done might need to be built into the program, and you won't want to hand that over to a third party. Where an "everyman" program can be used, though, it will probably be cheaper, which is all that matters to many people.
I wanna be a eunuchs developer! Pass me a bread knife!
-
Projects built internally and used for few years with my last employer were replaced by some vendor tool, and I didn't want to be in the shoes to 'config' 'support' and 'wait for another patch', so I joined a different firm, but after few months i was told that the project we've been working on is going to be replaced by some vendor tool...again! Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
My agency spent several million dollars on a vendor application that never worked. They hired a contractor to get it to do the job that it was purchased to do and their representative used the time to party with the secretaries. I was tasked with looking at the application and found that out of 200+ tables only 4 had any data in them. They fired the contractor. I was part of a team to create an in house application and we got that going but our secretaries preferred their excel spreadsheets. Because the records were critical to the operation of the agency they were forced to use most of our application. Then management decided that it would be cheaper to get COTS software again and hire a contractor to adapt it. The cost estimates were so huge they apparently are giving up on that one. Management memory is short.
-
Projects built internally and used for few years with my last employer were replaced by some vendor tool, and I didn't want to be in the shoes to 'config' 'support' and 'wait for another patch', so I joined a different firm, but after few months i was told that the project we've been working on is going to be replaced by some vendor tool...again! Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
Internal applications are a cost of doing business that is the be minimized. So.. try not to make a career out of developing internal applications.. unless they are perceived by upper management as somehow adding to the company's differentiation within the marketplace. On the other hand, if you get to learn useful, marketable skills working with the vendor's tools, then it might be worthwhile. I know this is sort of a mercenary attitude, but it was one of my first lessons right out of college.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Third party vendors provide the cheapest solution to their problem, and unless you happen to be making a tool that's bringing in money for the company, there really is little sense in internally developing something they can pay a lot less for. At my last company, we were really small... anything that we could use open source software for, we did. Heck, you can even base projects on open source and just make minor adaptations to suit your needs.
Except for when it's one of the company's core competencies and they critically rely on it. Then it really needs to be homegrown. Companies do try to farm out their core competencies but this is a very bad strategy that never works properly. Image if Google tried farming out their data centers to IBM or EDS...How well would have that worked? Sending out your critical business to the current experts that really needed to be the next generational experts but weren't. Google spent a lot of time and effort perfecting their data centers into the next generation. All the other search providers that farmed out their data centers are where now? In the dust. This works the same for software. If your company/organization core competency is XYZ then unless there is a good 3rd party software tool that matches your process 75-90% that you can use then you really MUST do homegrown software else your efficiency will be severely negatively impacted as will your profitability. Few managers understand this.
-
Member 10815848 wrote:
Is this the trend? do you feel there are less home grown applications that could stick long enough and beat the 'vendor tool'??
From my very limited understanding of business management strategies (I've made it a point to steer clear of entering management), the rule* is pretty simple... If it's central to your business, build it yourself. If there's nothing out there that's close enough to what you need, build it yourself. Otherwise, just pay someone else to build it for you. So the really company-specific tools will stay in-house, and anything generic enough to be used by multiple companies will eventually become a third-party vendor tool. * I don't know if it's a rule... This is just what I've unintentionally overheard/derived over the past decade...
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Well said!
-
Except for when it's one of the company's core competencies and they critically rely on it. Then it really needs to be homegrown. Companies do try to farm out their core competencies but this is a very bad strategy that never works properly. Image if Google tried farming out their data centers to IBM or EDS...How well would have that worked? Sending out your critical business to the current experts that really needed to be the next generational experts but weren't. Google spent a lot of time and effort perfecting their data centers into the next generation. All the other search providers that farmed out their data centers are where now? In the dust. This works the same for software. If your company/organization core competency is XYZ then unless there is a good 3rd party software tool that matches your process 75-90% that you can use then you really MUST do homegrown software else your efficiency will be severely negatively impacted as will your profitability. Few managers understand this.
C Grant Anderson wrote:
Except for when it's one of the company's core competencies and they critically rely on it.
Well, yeah... in your example, you use an example of a company that's making money off the data they hold. So, it doesn't change my statement. On the other hand, if a small webcrawler comes online, are they doing to recreate searching and data archiving or use existing tools? It makes no sense to reinvent the wheel unless yours truly is different and innovative. Anything less is a waste of resources.