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'??
-
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'??
It's certainly a trend - we're an expensive resource and re-using programming talent across multiple clients has some economic advantages. However, custom applications are more targeted on individual needs, so they're not going to go away!
Life is like a s**t sandwich; the more bread you have, the less s**t you eat.
-
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'??
The trend is to try to use the cheapest 3rd party software available, even if it doesn't match the requirements. Then complain loudly and blame your IT department which, since it was 3rd party software, can't do a damn thing about it. The next step would be to try even cheaper 3rd party software.
-
The trend is to try to use the cheapest 3rd party software available, even if it doesn't match the requirements. Then complain loudly and blame your IT department which, since it was 3rd party software, can't do a damn thing about it. The next step would be to try even cheaper 3rd party software.
So as developers who want to do development, what do we do? join the 'vendor' company? :-D
-
So as developers who want to do development, what do we do? join the 'vendor' company? :-D
-
So as developers who want to do development, what do we do? join the 'vendor' company? :-D
Yes - join the vendor company. How many hardware engineers does a typical company employ? Not many - they buy from vendors. Similarly should be the case for software.
-
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'??
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. By having that functionality taken care of by a third party vendor, you can focus on the apps that bring money into your business. We still have some utility apps, that their are no vendors for but that could change too.
-
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. By having that functionality taken care of by a third party vendor, you can focus on the apps that bring money into your business. We still have some utility apps, that their are no vendors for but that could change too.
The last company I worked in had a dedicated dev team to create and maintain their applications, which were written from scratch and went through a number of rewrites and releases and so on as normal, and did exactly what the company needed, and was a large part of what made the company number one in the country in its field. New features were delivered quickly, bugs were fixed very quickly, anything was possible if the business or their users could justify it. The devs were close to the business and its users, and understood them both. The company I now work for also has a dedicated dev team to create and maintain applications. One monster that I worked on was written by a third party who then stopped maintaining and supporting it so we bought the source code and modified it ourselves over a number of years. It was a nightmare, but the bits we created ourselves worked extremely well and all the positives from above applied too. A few years ago this was replaced with an application from a third party vendor. It has been a huge pain (still not over yet) trying to bend it to fit the business, changes are expensive, take many months, and have to be tempered with the core functionality, much of which is a poor fit. Bug fixes take even longer as they have to go off to the original software house and go into normal release cycles. Customisations have been biting us in the ass ever since go live, and are getting worse, part of the problem is that we have a faceless blob of resource to work on these things for us who neither know, nor understand the business we are in. Generally speaking we try to use the systems we write in house that are around the new vendor supplied monster to fudge any problems before we resort to the vendor. Of course many of the issues were caused by the business trying to choose the cheap option, although a cheap option that has probably already cost around the same as employing a hundred devs for a year. And I'm not going to get onto the application that was purchased on the back of a bet made in a golf course clubhouse. Everything written in house works, and it works as the business needs, it is responsive, and takes into account how our users work. Far, far more effort is put into just keeping the vendor bought systems up and available.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
-
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?
I was a consultant at a large aerospace company that ended up going the same route. It was a weird experience -- the IT department originally had the full backing of the VP for that division to put together custom tools to integrate, streamline, and automate the work of several departments. All the departments were looking forward to the tools and had, in the past, done considerable due diligence researching commercial alternatives and none were happy with what was out there. When the VP retired, a couple people came in, one in the VP position and one as a new high-level manager of the IT department. It was clear from the get-go that these two guys had their own agenda. Furthermore, they had no experience in aerospace (one came from Ford of all places.) What was really sick though was that while they verbally backed our project to the team, they were clearly working on their own agenda behind the scenes, eventually terminating the project. Sadly as well, because we were bridging several departments, each was getting a better understanding of their respective issues and I felt we were facilitating communication and understanding between the departments, something that had nothing to do directly with writing the tools, this was a really neat side benefit that we were seeing. Of course, when the project was scrapped, that all essentially stopped. I'm not even sure whether a third party tool was ultimately selected. There were complaints from each department as to the inadequacy of the 3rd party software, and it was the recommendation of all the other departments involved that we keep developing the in-house tools. Of course, the two goons that took over did not listen. In the end, and this is pure conjecture, I think the whole reason for the change was even bigger -- the company was positioning itself to be bought out, which did actually happen, and I suspect that there were political and other influences in play that we also didn't know about, but as I said, that's pure conjecture, based on my years of experience as to how management (especially at the C-level) works and speaks with a forked tongue. And yes, I'm biased -- there were good people motivated to save the company real money, reduce errors in manufacturing, and we had demonstrated that this would also allow the company to respond much faster to manufacturing changes, etc., giving the company a significant competitive edge. There
-
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. By having that functionality taken care of by a third party vendor, you can focus on the apps that bring money into your business. We still have some utility apps, that their are no vendors for but that could change too.
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!
-
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. By having that functionality taken care of by a third party vendor, you can focus on the apps that bring money into your business. We still have some utility apps, that their are no vendors for but that could change too.
-
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. By having that functionality taken care of by a third party vendor, you can focus on the apps that bring money into your business. We still have some utility apps, that their are no vendors for but that could change too.
Third party applications that do exactly what you want, or close enough to it that they don't annoy you in their off-the-shelf state, are a good thing. They save time and effort and are generally properly tested. For example, who here is in a company that has its own browser, email client or word processor? None of us, because the standard offerings are good enough. When an application is supporting business functions or processes which are unique to the company, then a third party solution will always be problematic, because even if you have a close working relationship with the provider, they're not going to understand your business and company culture well enough to get the software to do what you need. For example, timesheet recording, project management and auditing, collaboration between teams and accounting all need at least a lot of customisation, and either you'll have your own or your people in charge of it will be swearing at their third party package a lot. And for systems that support your business purpose, your in-house development gives you your competitive advantage and flexibility. Oil companies write their own reservoir modelling systems, factories write their own plant and equipment management programs, satnav companies write their own mapping software, because if you buy that stuff in then you are just a front for someone else's innovation and there's no reason for clients to use you instead of the people you buy it from.
-
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'??
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.
-
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. :)