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

341–350 of 607 posts

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

#341

Post by bazaz »

I'd recommend getting a remote, third-party team of contractors, and hiring a fractional CTO to manage that particular team and any related software. Having done that pattern before; it's less liability and cost for you, and easy for you to experiment and get the job done. You can easily end the contract with the team once your software is stable enough.

My only advice would be: don't attach different freelancers to each other and expect the job to get done. That might work in some particular use cases, but most software requires (at least) the engineering team to be in-sync with each other. Freelancers rarely have that skill.

Hiring a full-time tech team in-house is beneficial only when your engineering/software is tightly coupled with the domain. We often overestimate and think that's the case every time -- it really isn't!

Btw if you want to hire such a team, I'm on the engineering end: bazaz@grayhat.com.pk

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

#342

Post by Oras »

I worked in an e-commerce company before and was responsible for the logistics tech.

The first thing to keep in mind, is migration will not be easy, mainly because no one would understand how the current systems work or the decisions behind each function.

You’ll need subject matter experts from your team to guide the new devs during the migration.

Having a CTO to hire the team is two edge sword. If you get it right, you’ll save months down the line getting things right, but if you get it wrong, there is a chance you’ll have to rewrite everything again in a few years.

My suggestion hire a senior full stack developer to do one feature outside the current system but in a way that integrates with the workflow.

This experience will provide lots of learning for your company on how to manage expectations, tech stack required, speed of development, ROI. You’re not going for a large investment either, one developer will not break the bank.

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

#343

Post by Arjuna144 »

If you should decide to go inhouse, I can warmly recommend checking the *frappe framework*, with which the open-source ERPNext was built. Compared to other such things this is truly open source (not like odoo and others, which really try to catch you in with being "open-source" and then let you pay up for the features you really need).

It is very powerful and comes with so many batteries included and is actually quite fun to develop with.

https://frappeframework.com/

Here is a story of a big financial institution betting on inhouse dev using frappe. (There is a TLDR on the bottom of that page ;) )

https://zerodha.tech/blog/being-future-ready-with-common-sen...

All the best <3

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

#344

Post by Arjuna144 »

nocubicles wrote: post #17

I would get an open source ERP platform that you can extend yourself - for example Microsoft Dynamics Business Central or Odoo and start building on top of that platform. These platforms already have edi modules and all other basic functions such as sales and purchase module, finance etc. That will save you tens of thousands of development hours and you can start building your custom processes straight away.

I recommend using frappe framework, as the ones mentioned are not as "open" as frappe. Odoo was quite a disappointment, because everything you really need is locked behind a paywall...

https://frappeframework.com/

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

#345

Post by The_Colonel »

Silhouette wrote: post #278
intelVISA wrote: post #249

Earlier quoted context omitted.

I'm gonna go against this heavily tbh: If you don't have a 'trusted wrangler' freelancers won't build anything worthwhile as they're not interested in the long term unless forced. There must be somebody you know, or friend of friend, to get a warm intro to an experienced developer you can pay to oversee said team on an interim basis. No consultants, agencies etc. they'll fleece a non-tech like you, save your money an…

If you don't have a 'trusted wrangler' freelancers won't build anything worthwhile as they're not interested in the long term unless forced. Freelancers' careers live or die based on where future work is coming from. Happy clients are good for repeat business. Happy clients refer other potential clients. Happy clients are good for portfolios or case studies. Smart freelancers are all about keeping their clients happy…

My experience as an in-house dev working together with freelancers and body shops (in Europe) is less positive.

A pattern I commonly see is that they are heavily technology focused and don't really care about the domain, because domain-specific skills are not transferable. They are snake-oil salesmen, every problem can be solved by adopting some hot new piece of technology which can be added to their CV and increase their market value. What's frustrating is that their contribution is in the end often negative rather than merely zero - adopting over-architected solutions looking good on CV will result in great costs. If you have a strong technical leadership, you can catch their bullshit, but in the op's situation, they would be pretty much relying on freelancers' good will and abilities without much of a chance to verify their claims.

To be fair, I've met also a number of very good freelancers, usually staying with the company for years.

This same danger exists also with the normal employees, but I think this "pad the CV, move on" is more common in freelancers since they generally operate on shorter timescales.

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

#346

Post by hobofan »

theshrike79 wrote: post #333
rurp wrote: post #125

My biggest suggestion is to look into ways that the transition can be done in stages, rather than trying to replace everything in one big swoop. This is likely doable, especially since you are already having to rely on outside tools. Then to start building, hire a small team (employees or freelancers) and have them create a single piece of functionality that can be swapped out from the current workflow. This type of…

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.

It's a good pattern in theory, and the main route I'd personally choose most of the time.

However in practice, depending on the kind of application, it can be really hard to do those gradual rewrites in practice, especially if you want to modernize by introducing new programming languages.

E.g. for a legacy project on the JVM, how do you gradually shift things over to Kotlin? Or for the same project how do you go from Java to Rust? Of course you can also do that by splitting things out into REST services, but now you have to handle reliability issues of your transport layer and have to figure out how to pass large data through it and/or how to handle a barage of calls that were previously swift in-memory function calls. So in practice there are a boatload of potential challenges when doing gradual rewrites, and in my experience very few people have the expertise to pull them off in practice.

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

#347

Post by carlmr »

Too wrote: post #338
danielheath wrote: post #222

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.

These experts may also be hesitant to change. It could be due to many different reasons. One the personal spectrum, they can overvalue themselves or have fear of loosing their jobs. On the technical spectrum, they can be stuck in old tracks without computer knowledge and not thinking outside of the box. For example, in their eyes the objective is to move PDF file from directory A to directory B. In the ideal automate…

For the technical side, this is a part of what a good software engineering team should be teasing out from the verbal requirements. Check if the intermediate PDF is needed, if it is, it still shouldn't be part of the automation path, but instead serialize/send the data properly and output the PDF on the side.

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

#348

Post by snegrus »

You could explore using a platform that gives you more tools and support out of the box, that allows experimenting with a custom setup, but doesn't need a big (both costs to set up a team and time to manage and get something good enough done) investment upfront.

What I have in mind is Palantir Foundry, Snowflake or similar. SAP would be overkill.

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

#349

Post by Closi »

bjornsing wrote: post #289

> I'm an executive at a mid-sized logistics company (~200 employees, $200-300M annual revenue) getting more and more frustrated with our software situation and am considering taking software development in-house. Would be good to know what kind of margin you have on that revenue. Software development is expensive and if this project will eat a substantial part of your profits it may be hard to see it through. One of…

These are really great questions - if it will take a 4 person dev-team a year to build what you have at the moment at $100k per engineer, what would $400k in co-development spent with your existing vendor get you? Often quite a lot!
Post reply on HN