Can someone explain me how this post works? I see here it's 5 hours old, but when I go to the OP profile it says it's 3 days old https://news.ycombinator.com/submitted?id=45HCPW
second chance pool
Ask HN: Should we bring software dev in-house?
121–130 of 607 posts
Re: Ask HN: Should we bring software dev in-house?
#122Since you can't find another vendor, it might be time to bring on software consulting practice that specializes in this area or at least doing something similar.
If you can find a firm that is capable of doing the work, then you can figure out how you will maintain the software. You'd have to determine whether it would be better to engage that firm for the maintenance or hire someone. Possibly a combination of both. This could be done while the software is being built.
Large software projects are more likely to take longer than estimated and go over budget, so be sure to factor this in to your calculations.
Re: Ask HN: Should we bring software dev in-house?
#123Here's a thought: "just" buy the vendor.
We don't have any of the details, but have you considered that? They already have the code to do what you want and know the problem space very well. Then your problems with them becomes a problem with themselves.
Re: Ask HN: Should we bring software dev in-house?
#124IME 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…
Genuine question: how do you suggest for that code to be maintained long-term if the original team was just freelancers?
If you do go this freelancer route I would assume that there will be no code to maintain long-term. The freelancers should be building a prototype, not something intended to last decades.
Either the freelancers work out and you begin hiring a permanent team (hopefully converting some freelancers to full-time) who will promptly rewrite / revise the prototype or you will go back to paying for software. Either way the prototype code should die or be taken over.
Re: Ask HN: Should we bring software dev in-house?
#125My 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 approach will limit the upfront costs and give you a much better idea of how feasible the replacement will be as a whole. It will almost certainly go smoother as well. Every rewrite/replacement of a large software project runs into a lot of unexpected challenges and complexity that will have to be ironed out, and this limits the disruption at any one time.
There are a lot of factors in whether or not to go this route, but it's certainly plausible that it's a good decision. I worked for a smaller company that did something similar and gradually built out their own internal workflow software tailored to the business. Overall it worked out quite well and they ended up with much better software at a lower price than they would have paid for outside tools. I'm sure there are plenty of examples of the opposite result as well. You're right to be cautious but I think it's an idea worth exploring further.
Re: Ask HN: Should we bring software dev in-house?
#126This seems like the story in "The Phoenix Project". If the outsourced software is critical to your operations, it seems it should be brought in-house. Software design is best done when the feedback loop is very tight. It never is with outsourced software.
As for how to go about building a team, you are better placed than I am to figure it out. Probably start with a small team with the most critical bits and build from there.
Re: Ask HN: Should we bring software dev in-house?
#127Get some experienced freelancers ( small team ) give them a proof of concept application to build. Review.
Re: Ask HN: Should we bring software dev in-house?
#128IME 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…
Strongly agree here. It's hard to find a CTO if you don't have access to any engineering talent that you trust and have vetted. A small, focused project with a team of very senior freelancers both gives you a chance to dip your toes into the idea of running your own in-house software development, and an opportunity to vet individuals who can help you make good hiring decisions down the road.
If you're interested in following this strategy, don't hesitate to reach out to poetic.artifice@gmail.com -- I'd be happy to help on both fronts.
As for your concern about logistics being not sexy enough - I've found that the best programmers (and the ones you'd want) are more interested in the technical aspects of the problem and business and customer impact, rather than the sexiness of the business domain.
Re: Ask HN: Should we bring software dev in-house?
#129Reasons not to do this:
- you don't really understand the full complexity of the domain or regulatory environment yourself
- you don't have the funding available to commit to not only the development team but also the infrastructure to support them (tooling, cloud environments, security team, policies to support this, technical writer, ...)
- you're not prepared to pay for top talent (assuming you can even judge it, see the point below). Starting something from scratch successfully requires a really experienced team who understand how to model and build things well. Who know how to build in sucha way that frequently changing things effectively become configuration rather than code etc etc. Most likely this means people who have 10+ years in the industry and preferably people with some product and industry experience.
- you expect this will be a one-time cost hit and then effectively free in perpetuity; software is expensive to maintain, requires ongoing security patching, keeping up with library and technology updates, and ongoing commitment even if from a business perspective nothing is charging.
- you don't have experts on hand who you can afford to have spending more of their time than you think is reasonable with your development team explaining in detail all of the lessons you've learnt from the current poorly performing software and what they really need.
- you're not prepared for it to take at least four times as long and be four times as painful as even your worst-case initial estimates.
- you're in an environment that requires eg. purchase of vendor libraries and/or integration to proprietary platforms and this impacts the economics of boutique development
- you're highly regulated and software you build/use has additional complications like certification/audit/... requirements - especially if you don't fully understand or can't communicate this effectively to the build team
- you don't know how to judge the competence or experience of your founding technical team; this will be critical to your success - more critical than almost anything else. One bad hire can derail your entire effort.
- you want an entity that you're bound to contractually and that you can sue for remedy when things go really wrong. And they will go wrong.
Of course there are lots of reasons to try to build the software yourself too, but hopefully the above gives a few counter points to think about.
Re: Ask HN: Should we bring software dev in-house?
#130IME 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…
As a developer who became this kind of a CTO a decade, maybe two before it became fashionable, I would have agreed with this in the past until I learned why otherwise with companies this size.
All the devs in this comments can do what I share below. 1000%. It’s a different way to make an impact and help make healthier spaces for technical teams to do what they want.
I’ll share one example. Clever architecture and leverage can beat most coding especially in the B2B space. I find I am fast at both architecting and uncovering useful system integration paths for the short and long term along with the flexibility in mind.
That being said, I have also seen a team of 100 devs flown in to write an ERP from scratch and it worked too because the process was fixed.
I won’t rule out a world beating team where 5-10 senior devs can beat a team of 50-100. I have got to be a part of those kinds of teams and also lead them. The caveat is being able to deliver world beating stuff is different than aspiring to it as well. It’s just not always sustainable way to live.
Since A company usually sells to companies the same size or larger. Anyone who comes from scratch can have their goose cooked pretty quick when a new client demand a different level of scrutiny in systems and data if coding from scratch.
Having deep enough experience to poke my head out in this thread both on my own as IC leading the charge, or or taking in my team, the orchestration of internal and third party vendors and resources is a big part of this. I deeply believe in external vendors operating in a client side platform I help implement and leave them with training that works.
A technically functional CTO who is still technical en putty to simplify and leverage to help deliver impact helps bring in different kinds of architectural and framework approaches.
I loving call it what management consultants talk about it don’t do. I’ve made learning and implementing that my craft to leverage solutions for anyone I put my time towards. It’s a life changer. Everyone wants the kinds of devs on YC to help their companies if they can learn a little bit of business.
It works well enough that I don’t need to pursue a public profile (although that is not changing), and warm introductions are a reality.
I share this because it’s possible for anyone who wants it instead of downplaying it. I help clear the path for the doers and builders, as one.
You have a fair indirect point that there’s a lot of different kinds of CTOs too.
If a business wants steady operation while switching over it will ultimately place a heavier loads on their teams.
If a business wants capacity to operate more smoothly to either grow capacity or increase flexibility for other things with their existing workforce.
This kind of thing may not always be built to success with the number of surprises and landmines discovered along the way.
Part of a transformation can become agile, parts of it water fall, all while holding the business and staff increasingly hostage while deciding to do a big bang switch over or daring to run in parallel.
Lots of people side things come up as well when changes happens to them instead of with them. It’s not uncommon for subject matter experts choose not to share information what itself can take some time.