Ask HN: Should we bring software dev in-house?
551–560 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#552It is the information asymmetry. How do you expect to hire competent devs/providers? Yourself? A random third party HR company? (hint: still the same problem cause as today)
You have to find a way to crack this, no matter the approach you take.
There's also the problem of finding a too competent provider/developer who gets bored or is distracted with other things.
You need to accept it's a learning process and do the homework. You can't throw money at it. You can't cheat. There's no way around it. Sorry.
Re: Ask HN: Should we bring software dev in-house?
#553Earlier quoted context omitted.
$5M/year? In the US maybe. A team of 5 senior freelancers in Europe will cost about 150-200k per person.
Employer tax contributions Office space Hardware and software, SaaS licensing, cloud costs, etc. Hiring costs (recruitment, recruiters, time lost in selection and hiring) Secondary cost to rest of the business to change processes, retrain, integrate, help the dev team understand requirements, effectively build and iterate, etc. Quite possibly a bunch of compliance, security, audit, pen testing, and other regulatory c…
You don’t make tax contributions for them. They bring their own hardware and usually software unless otherwise agreed.
The rest of the stuff is just a laundry list you made up to try and blow costs way past what they actually could be if you’re prudent. Come on
Re: Ask HN: Should we bring software dev in-house?
#554Re: Ask HN: Should we bring software dev in-house?
#555with that said it has been my experience that a key first member in this is to find a passionate person within your org, whom you consider an expert or very knowledgeable in your business, and convince them to transition their full-time role to build these types of solutions. Find this person, convert them, and give them complete creative autonomy to pursue these efforts head-on. This person will implicitly possess an intrinsic understanding the problems with the highest value:effort ratio for the company, and when necessary, be able to fill the (many) necessary assumptions it takes to make functional apps that provide real value. You would be surprised at the simplicity and crudeness of what a smashingly successful app can have (and most importantly, what others will actually use) - so long as it addresses the right problem.
Re: Ask HN: Should we bring software dev in-house?
#556> "This feels like a quagmire in which development can quickly stall." It depends. In the end EDIFACT is just a protocol. If you go the Java route Smooks, for example, has pretty decent support to read/write EDIFACT messages. If you do not want to do the heavy lifting yourself, both AWS and Azure provide SaaS services to do the heavy lifting for you (AWS: B2B Data Interchange, Azure: Azure Logic Apps) > Besides, can…
I'm not familiar with EDIFACT, but just from the context I'd assume that a) there is something on the other end that expects the data to be exactly in a specific format, which may not be documented correctly or in a language your devs can read, b) the consequences of not getting it 100% right are expensive, c) there are a lot of these "somethings", each potentially requiring their own format/special quirks for which…
Wikipedia provides a pretty good explanation: https://en.wikipedia.org/wiki/EDIFACT
The beauty of EDIFACT by the way, is that with enough time and effort it can get parsed and validated using any text processing tool at your disposal because everything is _rigorously_ specified by the UN.
For example I once had to do it with a set of specs, standard Linux text processing tools and a sprinkle of shell scripting for a school assignment.
Re: Ask HN: Should we bring software dev in-house?
#557Here's a recent case study from one of our clients: https://www.mapbox.com/showcase/sotargruppen
I also write widely on anything related to software and logistics: https://afi.io/blog
I won't tell you whether you should build or buy, but I'll tell you what to avoid.
Avoid - large system integrators like IBM. They will charge you a lot of money and then just outsource it to someone else (source: me, we occasionally do subcontracting work). - freelance engineers from a website like Fiverr. You want someone who's done this before, many times, and has seen what worked and didn't work. Logistics is very niche, and outside of a few speciality dev shops you won't find engineers who have experience solving real world customer problems. There are really good engineers at Waymo for example, but they won't work for you (or me).
There a quote attributed to the late Charlie Munger. When asked how he would select a future investment manager for Berkshire Hathaway, he replied, "It reminds me of the young guy who went up to Mozart and said, 'I'd like to write symphonies.' When Mozart said, 'You're too young,' the young man replied, 'But you were young when you started.' Mozart pointed out, 'Yes, but I wasn't asking anyone else for advice on how to do it.'"
You want someone who's done it before.
Re: Ask HN: Should we bring software dev in-house?
#558IME 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…
Where I’m at we brought some software in-house and that part was skipped, or ignored. Years later, in talking with the lead on that project, he will admit that was a big miss. On the one had, to make change he didn’t want to be tied down and pushed around by past politics and issues, but on the other hand, some big fundamental problems were carried forward from the old solution to the new, and there was no way to really fix them after the fact, without effectively starting over.
Re: Ask HN: Should we bring software dev in-house?
#559IME 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…