Live data from Hacker News

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

news.ycombinator.com

481–490 of 607 posts

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

#481

Earlier quoted context omitted.

> This is difficult and time consuming so start now. A specific difficulty you are likely to face: Your expert employees are busy doing their jobs. Writing requirements means taking attention away from that work - a difficult proposition, especially if they have managers who will ask why their KPIs are slipping.

Maybe a nit pick, but I would not accept the expert employees writing requirement documents that are "thrown over the wall" to the dev team. You need personal access to talk to the experts anytime some question comes up. This means 1-2 experts work part time as PMs more or less, which will impact their regular work. Costly, but I don't trust any other way.

I think there are variations of this. Yes, your experts need to give an amount of time to the effort. Making them a PM, in any sense of the word, is a step beyond contributing their expertise and can be avoided.

What you need is someone with significant dev experience, but enough outside exposure to step into the PM role. Ideally, it'd be someone with interest in user experience research, or a personality that connect outside of a dev team. They should be able to perform this role in a mechanical fashion to avoid a dedicated PM.

Doing this will be effective enough until things are at the point where a dedicated PM can be justified. If there is a struggle with the user experience aspects and getting knowledge out of the experts, you can get expertise from an agency on a short-term basis.

Adding a pure PM is going to significantly slow you down unless are one of the rare switchers who flip between dev, PM, and dev manager roles. People don't know what to make of these people, but they exist, especially in the freelance contract world. People will only full-time experience tend to look down on them because they can't understand it.

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

#482
Maybe just hire a data engineer or two to start. They could potentially deal with the pain points and make life easier for your team. A lot of data engineering these days involves glueing various services together and managing the data flows between them. So an experienced data engineer should be able to do what you need.

Overtime, you could move away from the software in question as various functions are replaced with other services or internal code. Or if you realize that replicating the software in question would be too prohibitive, at least you have some folks that are adept at dealing with that type of stuff.

It is worth mentioning that when managing software projects, the complexity and frustrations tend to sneak up on you. The first prototypes tend to come together fast, and are nice and clean and crisp. But overtime, the feature set grows, the complexity grows, and the cost and time it takes to iterate grows. If you only need a very small slice of the features of the software in question, and you are paying an arm and a leg for said software, then it might make sense to roll your own. But it is easy to underestimate the complexity of what you need accomplished and rolling your own could end up being a very costly mistake.

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

#484
What size is the software you are using? If it's niche, you might be able to straight up aquire them.

Or at least get a source code license so you can have an inhouse time improve it.

I would recommend against building something from scratch without having the necessary experience

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

#485
There are likely ways to have your cake and eat it too. Rather than replace the existing system, consider augmenting it with your own and then eventually, over time replace the existing system.

Showing short term and long term wins concurrently is a good recipe for success for tech as much as it is for business.

Some questions that may help you: 1. What are the biggest problems with your existing system and how does that relate with the biggest problem for your business?

2. Is there an API or any manual process you can use to communicate between new systems and the existing system?

3. Is there an engineering leader you can bring on to help or consult?

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

#486
I hear you loud and clear! In robotics, every company has the same make-vs-buy dilemma with respect to fleet management software (quite comparable to logistics). I've been in your shoes. This is why I believe in third-party solutions that don't try to be one-size-fits-all, but instead enable you to build your own, perfect system yourself, and that's what I'm working on now. I've recently written about it here: https://transitiverobotics.com/blog/make-vs-buy Feel free to find me if you want to chat and compare notes.

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

#488

Earlier quoted context omitted.

The original question was the perfect setup for an ad, more or less asking “have you ever done this before?”, “What should I be concerned about?”, and “How do I even start this?”. This response may seem ads-y, but it also answers the questions and provides interesting original thoughts (e.g., to start with a cost/benefit analysis). Even if it’s an ad, imo it’s a useful one

I saw a presentation on e-commerce back in the 90s, and this was an astroturfing strategy that was pitched even back then. Don't post a thread about your company, post a question on one account, and then on another account post that your company is the answer. Really it's a strategy that's been around for a lot longer than the internet. Not saying that this is astroturfing, just that this format has been around forev…

Ya, if it’s two accounts controlled by the same person I agree it’s disingenuous. I think (hope?) that’s not the case here though

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

#489

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…

> 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. You seem to be making that assertion with 0 evidence. I've seen plenty of businesses fall behind because their tech is old and becomes an anchor, and I've seen businesses whose primary competitive advantage is their tech.

I've also seen businesses fall behind because they were chasing the latest tech fads even though those did nothing for their business.

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

#490
I actually own a studio that does just this.

I think that for a lot of businesses, they can hire internal developers prematurely before they have a clear vision of the product that they're building or need.

We structured our studio as a group of (very) senior talent, most with over a decade of experience each across Product Design, Software Engineering, and Product Management, where thee entirety of our studio is available on each project.

We focus on documentation, developer experience, and working with companies to get the initial product in a state of both product management and cleanliness to ensure that they're reading to onboard specific team members internally to carry the product forward.

It can be very cost prohibitive to create a new product without having designers, developers, product owners, all that are dedicated to your vision. A developer may miss key user experience interactions, making it difficult to use. A designer may forgot key features from a business perspective. Having access to all of the talent for a new product is hard.

As others have said here, I recommend finding very talented and experienced SENIOR Engineers. If you are intent on them being an internal team, ensure they have excellent project management skills and have built their own side project from scratch, so they know what it takes to build a full product from the ground up.

An engineer that builds their own products has experience that is invaluable when it comes to building functional tools that people want to use.

Post reply on HN