How to convince management that not all software tools should be internally made?

Question

I work at a technology company where we have around 10 programming-capable people. For some reason our management thinks that we should create all the internal tools ourself. By this I mean ERP, knowledge management as well as specialized software tools for production (this I understand completely). There is also constant urge from management to replace our existing industry standard tools with self-made tools "because our productivity increases". To give one example of this behaviour is that management has considered that we would build Gitlab-alternative in-house.

This has resulted in a situation where our internal tools are a lot worse than industrial standard tools, and there is not enough people working on the software of our actual products. There is also obviously increasing amount of upkeep from our internal tools.

When talking with my peers it feels like the concern is shared, but it feels that none of my peers knows how to address our concerns with management as for now we haven't had any problems. I'm also relatively new in the company so I don't feel like it's my place to raise the concern.

Answer 1

You probably can't.

Most organizations have figured out that running a standard best-of-breed is miles better than something you develop in-house. Unless you are a really-out-there operation, like an auto assembly plant, it's unlikely you have requirements that really need to be met via custom software. The chance that you and your buddies have the knowledge to build a custom ERP is almost zero. So you are part of a very non-self-aware organization.

I see custom-built built ERP's fairly often. They are riddled with weaknesses, especially when it comes time to connect them to an outside system like an OMS or WMS, simply because the builders knew only their specific requirements without understanding how these things ought to be done. Oh, you want to change your costing method? Sorry, we can't, because we hard-coded our old one.

There will be too many people in the organization who are emotionally tied to these old applications they helped create. It's hard to call someone's baby ugly, and these old apps are exactly that - ugly babies. You as a new guy just aren't going to able to affect that.

Answer 2

I would suggest looking at the bottom line. Internal tools do not bring in much revenue but still require to pay the salary of those who program it. Compare it to a situation where you pay X dollars a month for a github/gitlab instance and the programmers can write a few plugins or simply work for clients.

The difference may be larger than management think, and make them reconsider this.

They may simply underestimate the amount of work (and hence time) needed to get something equivalent in a “few years” to a polished product that can be bought off the shelves today.

Answer 3

Take some months (probably a year at least) to get used to the tools being used and enumerate exactly what they can't do that other tools can (which may be less than you think, once you actually get to know them), what they are especially efficient or inefficient at, and what it's costing to maintain them versus a REALISTIC estimate of what it would cost to replace them and retrain everyone (which is usually much more than you think; disruption has costs).

Then you may have something that can stand as a formal proposal to management. Though they're much more likely to consider it if it can be done incrementally and prove itself at every step, rather than all-or-nothing.

Until then, and without that effort to present it as a fully supported and documented proposal, odds of management even agreeing to listen to the proposal are minimal.

EVERY newcomer thinks they can improve things by replacing part of the business process. It rarely works out to be worth the effort. You may be the exception, but by now everyone's pretty tired of hearing "We should all be using" whatever the tool-of-the-day is.

Quoting Dean Inge: "There are two kinds of fool. One says 'this is old, and therefore good.' The other says 'this is new, and therefore better.'" If you can't prove your case, and the folks who have to make the decision don't yet have a reason to trust your judgement, hold off until at least one of those has changed. Preferably both.

Answer 4

When speaking with management, it's - broadly generalizing - all about time and money; with "fit for purpose" being of secondary concern. This is not to talk bad about management, but because it is the function of management to manage time and money. The people you talk with very likely come more from business schools than engineering backgrounds.

So, you have to talk their language. You have to convince them that their plan of creating a bespoke software is much more expensive in the long run (think "total cost of ownership") than using some standard software.

Things that go into the TCO:

• You have to build the thing. This costs employee-hours, and possibly also opportunity costs (while you are still building the software, you don't have it, and can't use it for what you are probably needing it - this in itself produces costs).
• You have to deploy and run it. Hardware or cloud capacity is not free.
• You have to implement new features over time. This costs the employee-time itself, but also secondarily the requirement to keep these employees and/or their knowledge around even when you don't actually need any new features.
• You have to maintain it. I.e., fix broken servers, occasionally recover data, keep security up, and so on and forth. You usually need separate teams of people to do these things, your average developer is not a great 24/7 ops person, and vice versa. More personell costs. Also, if you skimp on this, there might be unimaginably costly worst-case scenarios; imagine losing all your customers in your CRM, or all your source code in your self-written github alternative. This could mean that the company stops to exists right there and then.
• Assuming that standard software might be easier to use (which honestly is not always a safe assumption), new employees might need significant time to work with the custom app; and new developers might take months to be able to develop features with confidence.

I hope that helps.

As an aside, some reasons why doing a lot of these things yourself can also be found. This list maybe helps you to get your thoughts in order and be prepared when your management brings them up:

• A custom software for e.g. time management can be cheaper than a standard solution because it costs no "eternal" license fees, and also because the company may only need very few features (basically, standard solutions might simply offer too much).
• Sometimes the company needs to customize standard software to their own processes and needs, and this can lead to huge development costs. And once you go down that path you get into worth vendor lock-in than ever because depending on the dev environment it may simply not be quite possible to get all the domain specific information out in a way to be able to switch to another product easily.
• You might not be OK with storing your data in the cloud, or there may be practical reasons that makes that less desirable. Yes, I know this sounds crazy, but people are still allowed to have this opinion. Not every standard software comes in a non-cloud version these days.
• DIYing it does give you full control about any little detail of the software. Sure, you also responsible to also get every little detail right, but you can tweak everything.

Answer 5

If you're new to the company, I'm assuming you're going through or have recently gone through the onboarding process. The other answers about this not being your problem to solve are correct, in that the waste of time and money isn't coming out of your pocket, but there are ways in which this impacts you and you can raise those problems.

You can speak to your manager about the onboarding process and how the lack of industry-standard tools has made it harder and slower to get established, and that you are concerned more changes in this direction will make it even harder for new hires in the future. You can also flag the amount of maintenance you're currently doing in sprint retrospectives if you're in an agile workplace, or some equivalent feedback sessions if not. Bring up that this is time not spent delivering value elsewhere, and ideally start by focusing on the internal tools that are easiest/cheapest to replace with external ones. Suggest a couple of opensource options if they exist.

There is also constant urge from management to replace our existing industry standard tools with self-made tools "because our productivity increases". To give one example of this behaviour is that management has considered that we would build Gitlab-alternative in-house.

Given the phrasing here, it sounds like management has received pushback on this from someone/several someones already, so it might be that these ideas never get implemented and you just have to get used to talking middle management out of silly/infeasible ideas on occasion, which is a useful skill to have. If the current situation is actually a stalemate where some tools are internal and others are external, then (carefully) supporting your side might help get things into a healthier state in the long term.

Either way, I would definitely temper my expectations in that scenario.

Answer 6

Thorbjørn Ravn Andersen's answer mentions bottom line. I want to drill into a bit more detail. Here is an approach I've used previously for people that have a high probability to be swayed by rational arguments:

Step 1: Find out how many work hours went into developing (e.g.) GitHub as it is today (or any other COTS tool that you are urged to replace and where this figure could be found out or reasonable estimated - a rough estimate is in many cases sufficient).

Step 2: divide by your current team size (10) to find out how many hours (divide further by 8 for days, or 40 for weeks, etc.) of full time work by the whole team would be required to equal that. (Ignore all other assumptions e.g. equal skills/experience/domain knowledge, etc.)

This gives you a rough, but reasonable estimate of both cost and time required to do the same sort of thing in-house. You can take this concrete figure to management, which will probably understand that much better than an argument based on general principles and hand-waving explanations.

I am prepared to bet that these concrete figures will show some mind-boggling quantities. They usually do. Which is the purpose of this exercise. Commercial projects are able to recoup the cost by selling to many, many users, each at a fraction of the dev cost. Inhouse the organisation bears the whole cost for a single instance.

The basic policy should be:

• for general purpose tools, get best-of-breed, most popularly used off-the-shelf (either COTS (Commercial Off The Shelf) or FOSS (Free/Open Source Software)).
• for very specialized areas that are not well represented, or not represented at all outside the organisation, it makes sense to develop in-house. That should represent the core purpose and reason for existence of your company: in-house domain knowledge and expertise and core values that sets the business apart from its competitors.

Answer 7

It's not all or nothing

The Mythical Man-Month book, vintage 1975, already addresses this. So I would recommend you read it to better argue with management.

In this book, you can read about the "tool maker", a job that indeed increases team productivity by resolving specific problems in specific teams.

But not all problems are "all" specific. A lot of commercial and open source solutions exist that have better functionality and frees the team developers to... develop!

Any time a developer develops a team tool that frees developer time, the productivity goes up. But any time a developer is blocked, reinventing the wheel, the only thing this causes is to productivity is to drop.

Sorry, but It's seem that management is deep in the Not Invented Here Syndrome, that is very difficult to "cure". There is no easy sollution, it will take time to change anything.

Answer 8

A lot of really good answers already but let me bring a different viewpoint.

You are working for a company that, although with some complains, it has enough work done/revenue ratio to be able to dedicate a sizable part of their personnel and time to develop in-house software without ending on the streets next month, and they decided to dedicate that "extra" money/time in making new internal tools, tools that have alternatives because they are quite used in the industry.

From where I'm standing you have found the golden goose of IT jobs and you're complaining that you don't like the gold.

Every job is both a way to earn income and a place to learn something new, and you have stumbled into a place where you can learn about how to make the kind of product that millions of people across the world use daily and on company time. A lot of people would kill for a chance like that.

A lot of people think that the IT dream is to make the next new app that everybody uses, but the real business is to make the better version of that crappy app that everybody "needs" to use because there's no alternative and cash on the millions of grateful users around the world. There are a lot of cases of companies making some internal tool to avoid suffering the "standard" tool and ending with a new blooming business, to the point of dropping their original business to go full time on the new product.

As an employee you should be happy, you have the chance to do something really interesting on company time, learning about what it takes to do the kind of software that millions use and you don't even have to invent anything new, just refine and improve over what there's already out there.

If thing go south the company will stop it before is too late or it will go under, but you would be able to move to another place and carry with you the kind of experience that very few can have.

TL:DR: it's a really good learning experience, it might end up as a profitable new venture and worst case scenario the company is the one going under, not you.

Answer 9

It really depends on why they're reluctant to use third-party tools. One of the main reasons you see, though, is sticker shock over the price of many enterprise-grade software packages. For cost-averse managers, you may be able to lessen their reluctance by starting small and using free and open-source software.

When software doesn't cost anything, it's hard to argue against it based on cost. I once had a manager that I knew wouldn't approve buying a software system to manage our code reviews. I spent a few hours setting up an instance of Review Board and loading it with some sample data. I presented it to him, not as "can we get approval to deploy this software", but as "look at what we have!" When it's right there in front of them, ready to go, and didn't cost a dime, it's very difficult for even the most Scrooge-like manager to say no. Throwing out something that's fully functioning feels like a waste of resources, which they're naturally against.

Some managers might come back and say "hey I really like this, we should build something like it". You can then point them to one of the open source stat trackers like Openhub. On the Openhub page for Review Board, it mentions that their code base consists of almost 11,000 commits made by 280 different contributors. All together it's roughly 61 person-years worth of effort, and would cost over $5M to build (there's a calculator where you can enter your developer salary and it generates a total cost). When you have those sorts of hard numbers in front of you, it becomes painfully difficult to justify wasting years of time and spending mountains of money just to end up right back where you already are.

As I said, start small, maybe with a few tools that only your team uses (no big company-wide deployments yet). Once everybody gets comfortable with it, you can introduce something else. Before you know it you've got half of your workflow running on third-party tools. A natural evolution would be to pay to host the tool externally, since it would be a cost savings compared to how much you're effectively paying one of your developers to maintain it. From there you might purchase a support contract, or buy a paid add-on for extra functionality. Pretty soon, you've re-trained your manager to be accustomed to buying third-party software for things. When they suggest building the next tool in-house, find a comparable open-source project and show them how much time and money it took to build it. Would they like to wait that long and spend that much, or would they like to have the problem solved tomorrow and move on to things that actually generate money?

Answer 10

This seems to be a lack of a sound "make or buy" analysis (at least in the area of internal SW tools), which should be at the basis of any sound industrial plan and of strategic plans of a company.

It is not simple to do in general because it needs to involve a lot of different aspects of production and market situation (present and foreseeable future), and lots of variables.

This should be taught at any management school. I know about it not because I was ever involved in management, but because I studied it in the only management course my Engineering degree required to follow, so a professional manager should know far better.

Therefore you should think twice before questioning the decisions of your management before actually raising a concern, you being a junior employee.

However, as a former professional SW developer, I can see your concerns, and I share them somewhat (you didn't provide much details, so I cannot express a better judgement).

Before doing anything you should "investigate" whether or not your management did any actual research and analysis about the costs of building the tools in-house versus outsourcing them.

However if you really discover that no serious analysis has been done and they simply acted following their "gut-feelings", then you could try to persuade them that what they are doing is dumb (ofc. never saying that so bluntly).

For example, you could go to your direct manager and explain that tool X seems to cause some problems and it is expensive to maintain and subtract time from producing client SW, whereas you know that tool Y produced by ACME, Inc. is a well-tested tool that could substitute X, for less cost, more functionality and (in the end) more profitability.

The way you convey this to the manager is important, and can't be independent from a "psychological analysis" of the manager themselves, since some people really hate when "underlings" try to do their job (even if they do it better).

You could try a careful approach, where you put your concerns in form of questions (e.g. "Wouldn't it be better if we used Y? It seems that...etc."), but it the guy is not amicable, that is really a slippery slope. The most you can do is to show that you care for the company, but you should be aware that some managers care more for their position than for the company itself, so this approach is highly context dependent.

All in all, if you see that the company is not doing well because of these inefficiencies, then prepare your suitcase and begin looking for a new job, because if your attempt at improving things could backfire or, even if it doesn't, but they ignore you, the company could be headed for big troubles sooner or later, and the first heads that are cut are those of juniors.

Note also that some companies are so big or resilient that even if some departments are inefficient they still make good profits and don't risk much (e.g. because they have a huge competitive advantage, or they have other departments that are so good that the "bad" department is "carried along" with the flow). So don't run and cry wolf before you assess the situation with some degree of confidence.

Answer 11

Internal software tools need to be maintained, documented, and upgraded.

The maintainance, documentation and upgrade of these tools will require labor, which has some costs.

In a few years, some of the team working on these internal software tools will move to other corporations or have non-technical roles in the organization.

Replacing them will take money and time.

As an example, your operating system or your compiler is probably not home made.