Ask HN: Should we bring software dev in-house?
111–120 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#112Re: Ask HN: Should we bring software dev in-house?
#113I've worked for Engineering Services companies and they excel at this kind of work. We'd interview you to understand your needs, quote a price to provide what you want and a schedule to get it done, along with maintenance as needed.
Yes, I'm vastly oversimplifying to get the point across, but this might be a better model than trying to hire a single dev or create your own internal development team. I could only recommend doing that if you expected that your internal needs would grow continuously and that you could both feed your team enough work to keep them busy (and not wandering off into other jobs) and manage them well. Both of which can be far more difficult than it appears on the surface.
You're not looking for an Accenture or IBM Global Services, but a small company, probably in your local city that provides custom development services. If you're in the US, I'll give Saturn Systems a plug: worked with their team before on a development project and I think this would be right up their alley.
Re: Ask HN: Should we bring software dev in-house?
#114The issue of doing in-house is the issue of finding competent devs, meaning not only "someone who code" but someone who understand how to PROPER design things, witch is essentially a lost art. EDIFACT is dramatically simple, far more than modern XML-based peppol alike dialects, here the issue is "just" knowing that very likely any "institution" might have injected a gazillion of personal stuff, mostly undocumented or…
Re: Ask HN: Should we bring software dev in-house?
#115I'd not bring everything in-house at once unless you really have to. Your fear that the devil is in the details is very much justified (I have stories, boy, do I have stories ...). However, in your position I would definitively start building a dedicated tech team. That allows you to start developing real solutions to solve pain points in a way that feels less like "filling the gaps" and more like "the first steps towards a better future". It also may make you a better, more informed customer which may perhaps help with your current vendor as well. It also gives you something to fall back on if the proviable shit really hits the fan with your current vendor.
Do not underestimate the importance of product management. Product management drives your development team. If you now use a basically off-the-shelf product, this is likely taken care of for you. Or not, given you describe the vendor as stagnant. In either case, you need to have that covered well.
One-is-zero: do not rely on single individuals, build a team. At the leadership level you'd want at least a product lead, business analyst, cto and a senior software architect. Make sure they work together as a team and that there is healthy cross-over in expertise/experience so that people can cover for eachother. In-house, not contracted.
I'd advice against fully outsourcing to an agency. You can contract a development team, and depending on where you are located that may be the most realistic option, especially in the beginning. But make sure you are at the steering wheel and have the people and experience in-house to use that wheel well (see previous point).
Invest in boring things like documentation and testing right from the beginning. It will pay for itself many times over. If you let it slide, you'll never catch up and you'll pay for /that/ many times over.
Other than that there's probably a lot I've learned from my adventure so far, but I find it typically difficult to assess what the lessons learned are unless someone pokes me with the right questions. Feel free to reach out at my HN username @ mailbox.org.
Re: Ask HN: Should we bring software dev in-house?
#116The issue of doing in-house is the issue of finding competent devs, meaning not only "someone who code" but someone who understand how to PROPER design things, witch is essentially a lost art. EDIFACT is dramatically simple, far more than modern XML-based peppol alike dialects, here the issue is "just" knowing that very likely any "institution" might have injected a gazillion of personal stuff, mostly undocumented or…
I agree with @kkfx. lisp/clojure world is good to help with long-term maintainability, etc. To get an idea search for Rich Hickey's talk "Simple Made Easy"
Re: Ask HN: Should we bring software dev in-house?
#117Like others mentioned get a freelancer or an external team for starters. Engage them for 2 weeks. I run a dev agency. I recently made a chrome extension for a customer for the first time and it just took us 2 days instead of 2 weeks because we leveraged claude sonnet. So building a software today is incredibly easy, you can build almost anything at an incredible faster rate. So if you set 2 weeks engagement and you c…
It would probably take more than two weeks just to understand their business enough to be able to get your mind around what they need.
Re: Ask HN: Should we bring software dev in-house?
#118Randy Syring, Chief Executive Developer, Level 12
Re: Ask HN: Should we bring software dev in-house?
#119IME 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…
Re: Ask HN: Should we bring software dev in-house?
#120Besides, can we even attract experienced developers to a non-glamorous industry like logistics? Yes. This is a complete non-issue. Plenty of developers work for companies that aren't "glamorous / sexy tech companies." In fact, I'd almost be willing to bet that - in aggregate - more developers work for companies like yours than work for those glamorous tech companies. Consider - every auto manufacturer, auto parts cha…