Live data from Hacker News

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

news.ycombinator.com

41–50 of 607 posts

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

#42
Here's what I would do.

Hire some people to start building it, publish the code under a copyleft license such as the GPL and start hiring consultants to contribute to it. This will give you control over the critical "must haves" while making it possible to eventually spin a lot of the maintenance off to third party companies.

Software that's developed this way has a long history of being very high quality as there's much more cohesion and communication of theory when the developers and costumers work for the same company while at the same time the GPL will protect the project from potential takeovers via internal politics.

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

#43
I've worked at a large company that ran internally developed logistics software. It worked for them.

> Strategies for attracting and retaining tech talent in a non-tech industry

While you might be in a sector that isn't tech, you have tech. Put yourself in a software engineer's shoes, from a career perspective. We tried to keep up to speed with respect to things like framework/platform version, development practices, etc.

Make it clear and obvious that you will continue to invest in technology. We went to mobile early because it made sense for our business. We continued to invest as mobile changed with the introduction of iOS, and as computer vision got better.

Feel free to reach out if you want to discuss further.

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

#44
The single most important thing is to hire the right person for leading (technical) this project. Even a tiny (There're interesting things to build in all industry; logistics is not an exception.

I've seen stuff like this before and the most common reason for failure is the "technical" person focusing on entrenching their position instead of focusing on delivery.

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

#46
As a Principal Engineer in FAANG, I’d caution against bringing software development in-house without someone who deeply understands how software is built at the leadership level within your company.

Software can be intangible, making it difficult to manage budgets and timelines. You might find yourself asking, ‘We’re spending all this money, but what exactly are we getting for it?’ What’s the point of all this CapEx?

Moreover, it’s easy to place unrealistic demands on software development. If you, the business, change your mind every two weeks about what the software should be or do, the constant churn in feature requests can bog down the code and hinder development—through no fault of the developers.

While you don’t necessarily need a CTO, it’s crucial to have someone you trust, even when the answers you receive aren’t what you want to hear.

Is it possible to find a new outside vendor?

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

#47
I spent some 13 years working for a manufacturing firm writing custom management software for a similar sized manufacturing company. I now work for a SaSS firm in a different industry with a few hundred clients.

The thing that I learned from this is you either buy off the shelf software and run your company the way that the software company thinks you should run your business. You can, like some of our clients, fight the software and figure out all the janky work arounds you want, but ultimately you are bound by that software.

Or, you can write your own software and run your company the way you want it to run, with all the weird quirks of your business.

I get why smaller companies/firms buy software instead of rolling their own. It's a huge amount of overhead for little apparent benefit. It's worse when the software vendor isn't helpful or attentive to your needs.

My gut would be to say find a few software engineers you trust, hopefully with experience doing EDIFACT files (I've done this myself and the specs are a bear to dig through). I have this feeling mostly due to the unresponsive software vendor and your operating in a small niche.

For attracting talent, pay them well, and make them feel appreciated, and listened to. You'll be running a tight ship with very few points of failure (the bus factor), just one or two people leaving could paralyze your operation. You don't want the software people to start looking for jobs elsewhere in such a small department. My previous employer did not do well in that department and lost 90% of their software staff in a 3 year time span. And when your department is 4-5 people that's devastating.

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

#48
post #6

> We're using a third-party product that functions, but barely. > Our business operates in a specific niche and there are no other providers who cater specifically to our industry. If you decide to do in-house, I’d recommend thinking about competing against existing as a new revenue stream, and spinning it off as a separate business unit as much as possible. I imagine this is implied in your question but it wasn’t sp…

IMO spinning off comes with it's own complexities in terms of product - If you are writing it for 'in house' you are writing bespoke software to your own requirements, but there are players out there in the logistics software market (across most verticals) that are making products designed to support different configurations / businesses / processes by default (i.e. the business logic isn't as rigid as you would build it for your own in-house software, and you build the software differently if you are designing it to be used as configured software rather than just to support your own requirements).

Would be interested to know the industry and any specific requirements that are very unique!

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

#49
> Strategies for attracting and retaining tech talent in a non-tech industry

As someone who is a tech lead at a non-tech company that does software in house for a niche product in a niche market...

You can either treat the software as a product in it of itself (as opposed to bolting it on to other projects for your core business) or you should expect to include some hazard pay to compensate for the mental and spiritual trauma caused by trying to pretend you can treat the software like a line item in non-software projects that "just" need software support, ending up with 4-5 project managers trying to oversee/status a single software release.

We do the latter and if some of the other benefits were not as good as they are, it would absolutely be a deal breaker.

I suspect most other non-tech companies also operate in a similarly sub-optimal way (the blind leading the blind), but why would I put up with that level of ass-hattery for anything less than what the market can bear?

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

#50
First, get a senior person to lead the effort. They need to have experience hiring and managing developer teams. Ideally, it is NOT going to be someone with a lot of wizz-bang shiny tech on their CV. You need someone who wants to understand your business, and will focus on business value, and swallow the elephant one piece at a time.

> Strategies for attracting and retaining tech talent in a non-tech industry

This varies, but if you manager to hire and retain 200 employees, I'm guessing that you'll do alright.

> Experiences transitioning from third-party to in-house software (success stories and cautionary tales).

If you have a decent manager and someone who can make sound technical decisions, you'll do well.

> Potential pitfalls we might not be considering.

You seem to have good awareness of the danger areas. Devil is in the details. Figuring out how to slice the problem and building things piece by piece will be important.

> Alternative solutions we should explore.

In general, outsourcing companies are hit or miss, but if you find a good one, you will get many of the benefits without the downside of managing software dev in house.

Having a more seasoned person supporting the lead engineer will help you avoid costly pitfalls. I'm being self-serving, but a fractional CTO working a few hours per week might bring the kinds of safety check that will make such an endeavor more successful.

Post reply on HN