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…
Ask HN: Should we bring software dev in-house?
431–440 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#432If 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?
#433An 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?
#434I 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?
#435To 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?
#436IME 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.
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?
#437The hard part is finding that "cracked" dev.
Re: Ask HN: Should we bring software dev in-house?
#438If 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...)
Re: Ask HN: Should we bring software dev in-house?
#439Re: Ask HN: Should we bring software dev in-house?
#440My 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.