Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Should we bring software dev in-house?

news.ycombinator.com

Post reply on HN
Print view View original

541–550 of 607 posts

Re: Ask HN: Should we bring software dev in-house?

#541

Post by randomtree »

I was a hands-on engineering manager brought to lead a similar effort at an ad agency to build out their adtech stack inhouse.

Worked out fine. I've also interviewed a number of people in similar situations. Seems to work out fine when people are interested in what they are doing.

One thing to consider is the cost of it, and the size of the team you would need. I would argue you'd need at least five people regardless of the size of your project to get any semblance of dev culture that would propel the team forward.

As for attracting talent, there's a tremendous amount of talented developers that don't make the cut to get into FAANG for different reasons. Get a technical manager to bootstrap the project, set up interviews, and you should be good.

Also, don't forget about dev tools and ops expenses, a need for oncall, and hiring devops to run it.

Re: Ask HN: Should we bring software dev in-house?

#542

Post by theshrike79 »

JamesSwift wrote: post #419
theshrike79 wrote: post #333

Earlier quoted context omitted.

Strangler Fig pattern works really well: https://martinfowler.com/bliki/StranglerFigApplication.html You split out segments of the old application and rewrite it, slowly moving traffic over - eventually slowly strangling the old application and replacing it with new parts.

Ive never seen it work in practice. Every time I see it end up with Appv1, Appv2, Appv3 all running at the same time because the new systems cant move quick enough to add new features so they get added to the older versions. But the newer systems offer unique things the older didnt. So they all coexist and never die.

That sounds like you're trying to rewrite the whole app, NEVER do that[0].

You shouldn't end up with appv1, v2, v3.

You should have appv1 along with appv1-foobarmeasurement-v2 running. Then you slowly move traffic to v2 of foobarmeasurement until it can handle 100% of the load and has all the features - then you remove that feature from appv1 completely.

Then you GOTO 10 and pick a new feature to slowly strangle.

[0] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Re: Ask HN: Should we bring software dev in-house?

#543

Post by leptons »

agentultra wrote: post #458

Consider that the software you're using, buggy and kludgy as it is, isn't the reason your business is making (or failing to make) profits. If you bring a software team in-house you run a lot of risks: - Second system syndrome : the software we use today is full of bugs and annoying limitations we have to work around. Let's learn what we can from that system and develop our own bugs and annoying limitations. - Cost ce…

Agree with pretty much everything you said. It's the devil you know vs. creating a whole new devil you don't know.

I wonder if it's viable for OP's company to buy the company they depend on for this software, and then staff it up and get the bugs fixed. That way they retain the domain knowledge from this company, and they get everything they want done to be prioritized. This would also likely prevent any future competition if they own the company that's making this one-of-a-kind software.

Re: Ask HN: Should we bring software dev in-house?

#544

Post by lazyeye »

ozim wrote: post #206
kelnos wrote: post #175

Earlier quoted context omitted.

> I've found that the best programmers (and the ones you'd want) are more interested in the technical aspects of the problem and business and customer impact, rather than the sexiness of the business domain. Just want to heartily agree with this point here. Certainly many of us do get excited about particular business domains from time to time, but in my own experience, I get more excited about technical challenges,…

For me red flag is that for OP as a developer I will end up being a cost. Even with all the good words he wrote how company can improve by doing own dev - reality is that company makes money in logistics and as a software dev I would be second class citizen and cost center. That is why I much rather work in company that makes money on software, because here I am money making.

I dont know if it always works this way. A software-first company has more experience at hiring/firing software devs and is better at "screwing you over", extracting maximum work for the least money. Its their bread and butter. Not all companies but some are like this.

Re: Ask HN: Should we bring software dev in-house?

#545

Post by passion__desire »

Since you are trying to implement it inhouse. How about choosing a better stack? Hire a high profile consultant like Saša Jurić and get the best stack implementation (i.e. Elixir). Here's talk by him on how he solves customer's problems.

Simplifying Systems with Elixir • Sasa Juric • YOW! 2020

https://www.youtube.com/watch?v=EDfm2fVS4Bo

Re: Ask HN: Should we bring software dev in-house?

#546

Post by athrowaway3z »

I've scrolled past the top 30 comments and somehow the absolute most basic question is only asked in a roundabout way in 1.

What are the financial rewards if you do? You say speed of execution & lacking crucial insight.

The crucial insight is most likely wishful thinking. I've seen too many useless BI dashboards to take your word for it. If this were true, you'd hire a contractor to make that very specific tool to give you that very specific insight that is going to pay for itself within a year tops.

The speed of execution might be important. But do an honest accounting on how much money you're expecting this to make. If its about missing customers, call the one you missed and ask them if a faster execution was the dealbreaker.

The relevant third aspect is supply risk. Are you renting some hosted service from a failing company that might drag your current business down tomorrow? Hopefully not. Most - decent - software can keep working fine for years if the updates stop coming.

Now plot the extremes.

1) Build in-house and it turns into chaos and wasted money (do not underestimate the potential for chaos)

2) Don't acquire the skills in-house, miss out on the speed/insight ROI, and the supplier fails

Decide which plans laid out in the other comments are the best for the situation.

Re: Ask HN: Should we bring software dev in-house?

#547

Post by poisonborz »

davedx wrote: post #62

IME what works best getting new projects kick started is hiring a very small team of senior freelancers, making one of them lead, and letting them loose. I worked on such a team once and it was really excellent. The advantage of this strategy is if the experiment doesn't work out, terminating freelancers is much easier than permanent (I noted you're based in Europe). Contrary to what other people said, I wouldn't try…

I took over after such a situation at a company, them working for 5 years(!). Some of them were still around but over such a long span the team changed multiple times over.

In short, please no. No documentation, awkward separation of inhouse/external employees (regardless of team setup, you have different access to resources), there is just no creativity, everything is done loveless and cookie cutter.

If you plan long term, hire long term.

Re: Ask HN: Should we bring software dev in-house?

#548

Post by jpitz »

You may want to hire someone to really dive into this question.

That allows you to set up a NDA that allows you to go into the nitty gritty details of your niche and why this product is out of headroom.

A fresh technical perspective may also provide insight into a path forward that doesnt include rip-and-replace.

Re: Ask HN: Should we bring software dev in-house?

#549

Post by rubyn00bie »

Here are some insights I've learned over my career:

1. Your first hire will be your most difficult. Most engineers know other engineers, and will bring them over if the work (and pay) is good.

2. You get what you pay for. Hiring very senior staff will pay for itself, even if you could get four or five junior devs for the price of one senior. Very rarely, if ever, will "more developers" mean more productivity.

3. Pick a portion of your system you need to improve and start there. Make sure your engineering team is empowered to make decisions, and that there is a "champion" with the authority to make decisions across departments. A lot of orgs can die waiting for non-engineering portions of the company to make decisions. Even worse is when they wax and wane on those decisions.

4. Following point three, if your organization is disorganized, or unable to move quickly so will your engineering team.

5. Hire remote workers. There are a LOT of folks who will never set foot in an office again. It gives you access to an immense talent pool you may not have otherwise.

6. Be flexible. Most engineers I've know have a schedule, but that schedule isn't generally a strict 9-5.

7. Whatever language and platforms you decide to build with-- make sure you can hire for them. Some are great, but difficult to find experienced engineers. I say this as an Elixir developer.

Finally, Logistics sounds pretty fun and for the right folks it will be. Don't undersell the problem space or think of it as boring. The engineering work may be the opposite of boring, or your organization may just be a good place to work.

Good luck, mate!

Re: Ask HN: Should we bring software dev in-house?

#550

Post by smarthope1473 »

Short answer: you need a tech partner/officer

Long answer: The model of partnership can be different. The answer depends on your company future vision. Do you want to run a business and pay for everything that's not relevant to your domain or do you want to make the best business possible and crush your competitors?

There is a "Not invented here" principle software companies use to eliminate distracting factors and focus on what matters. However if every software you use isn't good, why not make your own? Plenty of companies do that.

A few options to consider:

1.Software provider

2.1. Re-negotiate software services with current provider. They can be irresponsible, underpaid or bad at negotiation and cannot explain you why they don't want to or cannot provide basic support.

2.2. Find a better software provider. There are plenty of outstaff companies in europe who'll be happy to help you with regular EU wages with a decent quality.

Better to transition slowly if you plan to abadon current contractor. Think of it as a drug use, come off slowly to make it easier.

2. In-house department

2.1. Find a tech lead (freelancer) and start educating one in your domain. Upwork, your network, whatever way is more comfortable for you to find an engineer. Don't worry about sexieness of your business domain, there are plenty of people who'll be willing to help. But one must become an expert in your domain, engineers do what they told to unless you make them understand what your company actually needs, so they can ask you reasonable questions.

2.2. Do you want to start a side software business in 2-5 years? This can be an opportunity for you to run a second/third/Nth company that provides SaaS logistics companies. I don't believe you are the only fish in the logistic sea, neither software providers or engineers are.

Feel free to ping me if you have any questions or need assistance: smart.hope1473@fastmail.com

(I'm in Europe and will be happy to meet over a beer)

Post reply on HN