Live data from Hacker News

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

news.ycombinator.com

91–100 of 607 posts

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

#91
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…

Genuine question: how do you suggest for that code to be maintained long-term if the original team was just freelancers?

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

#92
I work on an internal team like you would be building, I think for a company of your size and probably needs it is very much a needed thing to control the software in-house. Not having people that are dedicated and know your stuff leads to the situation you're in. Just do it. We've outsourced a couple small projects, then re-written them within our team because the quality and lack of specification is just...bad.

My current industry is pumping chemicals, it's non-glamorous but it's a need that must be fed, versus "fancy tech" or whatever. We keep a team of guys employed and happy. Just pay them decently well, don't try to micromanage them, give them good requirements and honest feedback, give them the tools they need.

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

#93
post #91
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…

Genuine question: how do you suggest for that code to be maintained long-term if the original team was just freelancers?

Code is often written for an audience: yourself on a year, maybe a younger team member you have In mind. Knowing you won't be around to explain can help drive some decisions and write docs for the audience.

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

#95
I’ll caveat my response here: this is provided as general guidance and should be seen as such.

1. Have you considered managing your providers performance? What could you do in this area?

2. Have you considered going to market for other providers to start new or to take the solution over? Is that even feasible?

3. Have you considered the long term capability build you need in your company if you decide to bring this in?

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

#96
I have not navigated a similar transition, but I have studied CS and read tons of business books.

I think if you do this and take the development seriously, it will be a ridiculous good return on investment. The success to Tencent according Mohnish Pabrai was that they had ROI on their developers over 10 years. They just put everything they could in development and if it was too much they would spend the rest on lower ROI categories. Overall 50% ROI. (IIRC).

It’s also essentially vertical integration if you do this. If you think it can make your beer taste nicer, as Jeff Bezos put it, then it’s probably worth it. Note that Amazon’s in-house team spawned a new industry. Also, Tesla is currently much ahead on competitors due to their software. I think many car manufacturers underestimate how much Tesla is ahead. The apparently even have their own ERP system called Tesla OS.

For attracting and retaining, I think you can definitely do it. There are engineers who like to see physically how their product is being used. Short feedback cycles can be very rewarding. Also, to retain I would look at Napoleon. What is the best for morale? Winning. Give ambitious projects and make them succeed.

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

#98
post #57

Unless this software is your core business, I would look at a third alternative: contracting the work out to experienced developers to replace the platform. If it works well, you can bring development in house slowly after the platform is more mature. Worst case, you’ll have a more responsive external party managing the platform for you.

Worst case is that you don't know how to run a software team and you end up spinning your wheels for ages and then have to onboard a Dev team and convince them they want to clean up someone elses tech debt. Thus making everything cost 10x what management initially thought. This is probably the last thing I would suggest.

[deleted]

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

#99
No advice per se, but questions you'll want to consider as you read others posts:

1. why do you believe you can build it better? (even with the most amazing team)

2a. its easy to over-estimate the gains of a rewrite, and dramatically under-estimate the negatives. how bad could things get, for the business, if you migrated to a worse solution? (lost revenue, lost customers, etc)

2b. after you answer #2a, do the gains (of a rewrite) now really seem so big?

3. if you outsource this rewrite to a 3rd party (freelance, contractor, etc) - how is that any different than today? you're already "outsourcing" this to an existing vendor. How would you maintain code from non-employees?

4. can the business even support the cost (and it's a positive cost/benefit analysis) on hiring full-time employees to rewrite and maintain this code base - forever.

5a. what do your competitors do? (buy the same vendor software or they built their own)

5b. if they use the same 3rd party vendor, is the market big enough for you to turn this into a new revenue generating business (sell this in-house app you'd build)?

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

#100
I worked on freight and logistics software for 10+ years for a New Zealand based company that has significant operations in USA, Australia, Europe and Asia. (domestic freight/road, air, sea, 3PL)

We were a bespoke software dev shop, and the freight company was our customer.

During my time there we were transitioning to their third “major” version of the software over about 30 years. It was a new system designed to handle the US market, where the customer was a relatively new entrant who had been running off the shelf software for some time.

Due to the way they run their business, with strong P+L requirements down to each individual location/site they had a presence, and even individual trucks operating as separate business units, a lot of what got built was effectively accounting. If this sounds like you, or you use a lot of third party carriers, keep this in mind: tracking freight movements alone isn’t that hard, but you need really strong accounting fundamentals in the system from the get-go to be able to really understand costs in this business. Some off the shelf software doesn’t do this particularly well.

Based on this - my strongest advice would be to choose boring tech (Java or .NET) and recruit specifically for some core developers who have a solid grounding in accounting fundamentals, or do some serious training on this before embarking on the design. You will inevitably end up posting journal entries to your accounting software, so treat cost tracking as a double entry accounting system rather than trying to construct a journal as an output.

The customer is pretty vocal in their annual reports (publicly available as they’re listed) about their successes in IT as well as their business model. They look at having control of their platform “in house” (product ownership in house, outsourced development of their own platform) as a core part of their success.

If you would like to chat, I’m not hard to find - look me up on GitHub, then search my name + New Zealand on Linked In. (My customer is also pretty obvious from there).

Post reply on HN