Live data from Hacker News

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

news.ycombinator.com

431–440 of 607 posts

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

#431

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.

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 fro…

On the case of the OP, with a database, different pieces of software interact over the database. It's the simplest case.

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

#432
I’ve worked on internal tooling for companies for more than a decade now.

If you can get the right people, it is absolutely worth it. You gain complete alignment of incentives. You can easy access. You gain rapid turn around.

If you get the wrong devs, you also gain missed deadlines, a mess that is difficult to work with, solutions that don’t solve problems.

Basically, if you can hire the right people, it would almost certainly be worth it.

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

#433
SAP?

An alternative to this strategy might be to have your own software team that builds tools and processes for you to "work with" or "work around" your primary software without fully replacing it.

As others have mentioned, what you want is achievable, if managed the right way, with the migration done in stages.( Trying to replace the whole thing in one jump would be very risky.)

In the real world though its quite easy to miss requirements, some quirk of the existing software nobody really thinks is a feature, except that one person in the office who has gotten used to abusing that quirk to achieve a task.

There is also possibly a lot of domain knowledge that the software team you hire might not be versed in, which can be tricky, although this is partially solved by having a good project lead and strong communication between the teams (software and non-software)

Where is might get more tricky is if you to adhere to certain ISO/etc certifications.

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

#434
> Besides, can we even attract experienced developers to a non-glamorous industry like logistics?

I would certainly love the opportunity to do a greenfield data integration / crud application project in logistics. This is definitely the right thing for a passionate senior developer

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

#435
I've been an early engineer in multiple start-ups, have co-founded 2 startups, and about a year ago, took a position where my primary role was to in-house logistics software in the healthcare space being developed by a 3rd party for about 4 years.

To succeed, you need a founder-type person IMO, who's full-stack, and has built great engineering teams. Hard to find, but possible.

The company I joined was also not a software/tech company, and they put the trust in me to define our engineering policies, how product-management happens, and put an emphasize of knowledge transfer for my first 3 months.

If you want to connect + talk more I'm at michael[at]mat.tax

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

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

Having had the fun of taking over a project from a bunch of clever contractors I would caution: It may be too clever. There is value in simplicity and a stake in long term ownership. Some article here recently associated technical debt as lost institutional knowledge so handing the most key decisions to contractors has also drawbacks. One needs an integrated approach for design, build, maintenance and operation.

Agreed. Take long term ownership. Don't farm this out. There are some companies out there that provide support and consulting on open source projects. Rather than look for a freelancer to build an in-house application, find someone that can help you capitalize on tools that already exist.

My company does exactly this. We build and maintain an open source project (SpiffWorkflow, for process automation) and help our clients build internal skills to deploy it and use it. No license fees or SAAS lockin - and no team of developers that walk out the door when things get difficult.

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

#438
post #383

If your current third-party product is barely functional and unsupported, it's clear that you need to consider a replacement as part of your mid-term strategy. It seems that there is a high risk of your vendor ceasing operations or their solution not being able to support your growth. The sooner you start the transition, the less painful it will be. When deciding whether to build a replacement yourself, consider whet…

If it's actually unsupported, it could be a bargain. Maybe OP should approach the company and offer to buy it, rights/source code etc, then build on top of that (it is doing what they want, even if barely...)

Very risky. It would only make sense if that solution does exactly what the OP needs but lacks stability and some new features. However, it's very likely that the product is a generic one, and the OP will end up spending the next couple of years supporting features they don't need but are interconnected with the ones they actually use. This would be especially challenging if they buy only the rights/code without the development team behind it.

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

#440
I am in a very similar situation, working for a mid-sized logistics (300 employees with small offices around the globe, 400-500M annual revenue), but with a completely different side, we do practically everything in-house with a very old software that does everything, (Multivalue D3).

My experience on your points:

>We're having to resort to a separate low-code platform to fill in the gaps. Our business operates in a specific niche and there are no other providers who cater specifically to our industry.

We also use low-code applications like Talend and TIBCO, to fill some gaps, the older folks that don't want to deal with our ERP prefer using them this way for example.

Have you tried taking a look to https://www.flexport.com/ or https://www.shipbob.com/? Afaik, these are 2 of the most overrall used in the logistics industry.

We are very slowly migrating our system in different departments to more modern solutions, but always keep in mind that as soon as you start migrating, you will need to keep both systems up for a long period of time while this happens, and that means money and workers.

>On the other hand, while our current solution seems like a straightforward CRUD app, I fear the devil is in the details. Will we get stuck at 80% completion? We do a lot of data exchange via EDIFACT, for instance, with various government institutions all over Europe. This feels like a quagmire in which development can quickly stall.

Europe is slowly moving outside of the EDIFACT standard fortunately and slowly implementing SOAP/XML based systems, you will have a problem here in an in-house solution because Europe systems are usually convoluted and hard to implement from different countries, from a business-side pov exclusively. ( I can tell you from first hand experience ), so indeed, a big problem will arise here. If you also do customs clearance, this will get even harder, as laws vary from place to place in small and big details.

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

Finding them is hard, but keeping them is harder, any other logistics company that sees a trained IT specialist with deep business knowledge will try to poach it with a higher wage inmediatly, I had tons of offers from close companies because of my customs knowledge. Pay them well and keep them happy. There is no strategy here, devs move for money like everywhere else, some end up in banks or insurance after some consultancy job with business experience and stick there, you will have to risk training them in house or poaching them from elsewhere.

For an industry as complex and in my opinion, enterprise customizable company, I highly recommend you to try an in-house solution, users sometimes don't need a lot to do their work and the most important thing in logistics is being able to do it quickly and efficiently.

What I can tell you absolutely that it doesn't work is trying to migrate from a big swoop, I saw companies close to us do it and it just didn't work out, their processes slowed down a lot and clients started fleeing to other forwarders because of the time they took to process any shipment. Move slowly in your smallest department ( reefer, customs, import or export, invocing, anything that in your company isn't as importante) and move efficiently, make their work as fast as possible, then grab that feedback and start moving other departments.

Post reply on HN