48

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.

3
  • 2
    Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on The Workplace Meta, or in The Workplace Chat. Comments continuing discussion may be removed.
    – DarkCygnus
    May 26 at 19:06
  • 1
    "as for now we haven't had any problems". There's your answer right there. What problem are you trying to fix if there aren't any problems?
    – Richard
    May 28 at 13:27
  • @Richard: The second paragraph describes what I would consider two pretty severe problems: "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." The OP may want to rephrase their question to take this into account. May 29 at 7:52

11 Answers 11

47

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 getting 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.

7
  • 11
    The cost of migrating once you have already used these custom tool can also be huge. Critical data might be in non-standard formats, and you have to retrain everyone. You can maybe prevent new tools from being created, but migrating out is another can of worms May 26 at 9:00
  • @MartinEpsz Considered everything, migration might still be worth it. While it is a heavy investment (in ~20 years only ever experienced 1 ERP-Migration at a customer's), it has more aspects than just the "make-or-buy" in $, but also in liabilities. Most dedicated ERP-makers keep up with latest law&order. If Fred from IT gets a § wrong, tax authorities may be after your bottocks, soon.
    – Fildor
    May 26 at 14:45
  • 5
    The other reason why you might consider internal tooling is if you have a very large organization and can devote a team entirely to the maintenance of those tools. Developing in-house means you can specifically tailor the tool to exactly your own business processes. We've been switching over some internal systems to off-the-shelf systems, and it's been a mixed bag. New ticketing system? Huge improvement. New test database? It's a wash. New office directory? Basically unusable. But OP doesn't appear to work for such an organization, so it's a moot point here.
    – A. R.
    May 26 at 20:42
  • Even in the large organization case, it's often more cost-effective to use an external tool along with one or more internal maintainers who can configure the tool to your organization's needs faster than a similar tool could be written from scratch.
    – Ixrec
    May 26 at 22:45
  • 4
    I worked in a financial organization once where everything we did was custom-built. What tipped the boat toward canned products was we had a cyber attack that accessed our critical data, and the software audit afterward to understand and develop a comprehensive solution. The cost of upgrading our current system, vs. a migration to a canned solution make it obvious that we needed to abandon ship.
    – Jay
    May 27 at 20:36
39

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.

4
  • 21
    To add to this, I would highlight that it wouldn't be a one time cost. Management may assume that after the tool is built there would be no cost associated with it. They may not consider the cost of having to run and maintain the service. Without this, they my then consider that a one time cost would be less expensive in the long run when it may in fact be more expensive.
    – Shorn
    May 26 at 3:40
  • 1
    I agree - also, it is possible that maintenance of self-made solutions could suddenly get very expensive and time consuming, if key personnel is lost, so there are nobody left knowing how the custom solutions are maintained, deployed, etc. etc.
    – Gertsen
    May 26 at 10:06
  • I also have seen people - often management - regularly underestimate exactly how complicated of a problem ERP is to solve. The best in-house ERP I have ever seen was egregiously expensive to maintain, let alone write. For most organizations it will not take much effort (relatively) to create a compelling trade analysis for purchasing commercial software.
    – Slate
    May 26 at 18:07
  • 3
    Cost of downtime is also huge. When you have to fix a problem, you have to pull manpower off of a task that would normally generate income. Do we lose the ability to make new sales because the system is broken, or do we fix it and miss a project deadline, causing us to lose an existing customer? You don't have to make those sorts of decisions when you have third-party software with a service contract.
    – bta
    May 26 at 20:22
16

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.

3
  • 4
    Note that the OP isn't suggesting a change to existing tools, but rather suggesting not changing existing tools. May 26 at 14:23
  • While "We should all be using X because everybody is using it" isn't very strong, "We should have feature X, because it is industry standard, and I don't want to live without it myself". It is a strong argument, because if it is an industry standard feature, and something you want, why would you stick around in a company where management decides you don't need it, when the next company will have you use it?
    – hyde
    May 26 at 20:04
  • 3
    Standard isn't always inherently better either. And part of learning to be a pro is learning to adapt to the tools and procedures available, while quietly helping to continuously improve things. In any case, my advice remains that the querant is not yet well enough established to drive this change, or even to credibly suggest it.
    – keshlam
    May 26 at 20:27
9

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.
6

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.

3

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.

1
  • I remember this book!!! Yep and yep.
    – Xavier J
    May 26 at 21:32
3

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.
3
  • I've worked at a place where the management response to this kind of evidence (or time estimates in general) was, "Our people are smarter, so we can do it in half the time" (or some other fraction). There may be other irrational excuses as well. May 26 at 15:43
  • couldn't "man hours" become "working hours"? (that's what they were, after all: hours working, not hours being a man)
    – Aaron F
    May 26 at 17:27
  • I would add to this that it’s important to make sure management understands that this is an estimate if the team is doing nothing else with that time. No other projects, no time spent maintaining other code, not time spent interacting with users (internal or external), just time spent working on that specific project. There’s a huge difference in bottom line between the team not being usable for anything else during that time, and the team being able to work on the project in their spare time. May 26 at 18:30
1

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.

1

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?

1

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.

1

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.

3
  • This is my feeling about the situation, too. I've spent too much time wrestling with 3rd-party systems and libraries, where I could have implemented the functionality I needed myself in less time, learnt more, and had more fun in the process. I'm fed up with days of debugging problems, just to eventually find out that I've just discovered a bug in the latest 'stable' release of someone else's product. I could have used that time to develop my own company's (superior) product instead. Sometimes NIHS isn't bad: joelonsoftware.com/2001/10/14/…
    – Aaron F
    May 27 at 12:12
  • I am not sure that the assumption of there being “enough” time and money to do this holds, if management is unaware of the true cost of this approach. They might be unaware of the true cost of what they make a living of and suddenly go out of business. May 31 at 4:26
  • according to the question this isn't something they started doing just now, but that this has been going on for a while and hasn't had a problem for now, so we can assume they have "enough" margin to not be an immediate threat; but still as i said if the company goes down it's not his problem, he should just take advantage of the situation and the experience while it last. if he end ups becoming manager then that would be another history
    – KiraraVS
    Jun 2 at 5:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .