531–540 of 607 posts
Earlier quoted context omitted.
Most business do not require on call for their internal tools
Depending on the area of logistics OP is in, it's not unlikely that he'd need on-call engineers for his logistics management system. Blockages in supply chain can be extremely expensive.
My advice would be to continue using contractors, but different ones, and focus their attention on building a better product.
> "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…
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 the provider may have already built workarounds.
Is that the case? If so, trying to build anything yourself will be a nightmare, and my first approach would be to find something that handles this part and beat my data into it, even if it means using some fully-featured software package just for this feature.
Rough version:
- Outsourced to a company. Supposedly top people.
- My friend joined that company. He threw his heart into it. Eventually, he got the contract. He was the only person fully committed to the success, and the outsourced company was committed but not to the same extent. The key here is that he had extreme ownership over it and threw his being into making it work, and he was (became) very good with people - devs, execs etc., while helping to make enough of the right technical choices.
- He made a lot of money, because he was helping a significant business during a lot of churn as they grew. He helped them a lot, over 25+ years.
- At some point I joined them for far too long, but I learned a ton of what was good and bad about this.
- The company bought a few others as they grew, rolled this system out to those companies. It worked well for them.
- Even in this case, helping them be the biggest in their (local) industry, they eventually wanted to move to a big-boy system. The lines of custom code become paper cuts. Arguing over budget, infinite demands from across the company. Friend, as always, helped them in every way possible to get the right result.
- Friend helped them move from a custom system to an ERP + custom. That hasn't been plain sailing, it's extremely hard to move from a custom solution because it fits like a (sometimes hairy) glove. Over the long term, probably the right move. But you lose a lot of time in the switch, time that could be spent beating competitors.
He was fully dedicated to the customer success. He charged extremely well, it made him financially. He owned it. You absolutely need ownership, and you need a smart person owning it. He knew that his success lay in always putting them first. If you can hire that person, great, but in this case the money helped him be fully committed, for an extended period of time.
I later spent time at a startup bank, where we assembled an incredible system out of build + buy, with a SAP core. This will absolutely trigger the HN crowd but it was an excellent base. You do not want to be figuring out how you do rounding, or multi-currency, or storing user data. You do not want to be responsible for every line of code in your stack indefinitely. You want to know what is yours to own and build and will help you differentiate, and what is important to have but will just get you parity (e.g. accounting, invoicing, marketing, whatever). You don't want 100% custom code unless software is a big part of your business and it'll give you an edge over competitors, because it's both an asset and a liability. The thing to keep in mind here is TCO - Total Cost of Ownership. A good ERP will help you roll out business features really fast without having to reinvent the wheel. Don't modify too much of the ERP where it's not really important to do so, rather use as much standard tooling as possible, because you need to own all the changes. There are also absolutely risks here. SAP deployments can crush companies.
Skills. You want a setup that has easy access to skills, indefinitely. It's very hard to build something and know that it'll always be in fashion. React will one day go the way of COBOL. The team replaced the front-end a number of times and kept the core database. That stable core was the best thing they had, for a very long time.
Remain agile. If a component or team isn't working, switch. Don't marry every technology. In the bank, we switched very large pieces out and it was always the right choice. CRM, API Gateway, messaging technology, hosting technology for some parts of the stack.
Be careful what you depend on. Every part of the stack wants to make you dependent on them.
Try to avoid a big boolean switch when you turn off the whole system and move to the other one. If you can strangle the old system and chip off pieces as you learn, great. Sometimes it's not possible and you're in for a lot of weekends while you check the new one does everything the old one did, and doesn't fail in some weird way.
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…
Probably the best way to think about this whole project is not as a project, but as a capability to grow internally. As a big project, you'll get stuck at 80% and never deliver. If you start small and deliver continuously, you'll get stuck at reducing the pain by 80%, which is probably a huge win.
Software is grown. Start small and focus on delivering value quickly to build momentum and credibility, but make sure that the team lead knows that your vision is to eventually replace the other systems.
https://simonsarris.com/p/growing-software-developers
It presumes you have at least 1-2 people already as a team, though.
So I have been on both sides of this. Not as a dev but in IT.
1 - As IT support for customers of a CRUD software.
The truth was, the company did not know their own software.
Coded in the 90s, touched up in the late 00s.
Original devs long gone, all quit en-masse.
Current dev team forced to bolt on new features.
Rework of the entire app needed (on-prem IIS and MSSQL dependant).
Sales & Management (they were the same people) selling features to customers that did not exist or were not on roadmap (straight up lying to customers)
"Project management" consisted of them calling devs/support cellphones wanting $New_Feature coded they just showed a mock-up of to a customer.
2 - As an MSP IT technician. Customers have no idea what we do or what they buy.
"Why are you so expensive/Why is this not just included when ur so expensive!!!"
- vmware servers in secure DC, management of windows server and linux (updates & backup, installation of software etc, monitoring for cpu, ram, disk, network)
- management of on-prem AD and Office 365 Entra users and groups
- Exchange and Office 365 management for email
- Endpoint management (Hardware, GPO settings, Entra policy, windows updates, software inventory and install & updates, remote support for users over RMM)
- Antivirus management (SOC not included)
- DNS filter
- Office 365 Backup (This is needed, MS has no care for your data on Sharepoint)
- Network (WAN, Firewall, L2 Switch, WiFi & management/troubleshoot and updates for all of it)
Then we get a "deer in headlights" look and "but you are just IT"
Just my 2c. I have no idea what to do in your situation. Maybe you are getting ripped off, but it will also not be easy.
Earlier quoted context omitted.
Yes, and also when you hire software developers you want someone who understands that they are running internal tools which is COMPLETELY different from building consumer apps. Simplicity is key. Keep the team small and lean. Also the build vs buy decision has to be made with every feature. If its not your competitive advantage just buy it. Dont make a new database, just use postgres etc. There are a different set of…
This is a huge thing. Way too many internal teams build their tooling "too well", to a point where it could be a separate startup product in itself with a tiny amount of extra work. Like game companies writing their own engine and ending up as a game engine company eventually =)
This used to be standard.
PS1 and PS2 was coded in Assembly basically. No OS. All games had "drivers" in them. There was only renderware as a ready-made engine. Every Final Fantasy game was a new engine, FFX and FFXII are 2 very different engines. Bespoke only for that game. And beautiful. Same with RE4. Same with God of War 1 and 2. Unbelievable. Same with xbox and gamecube. Even in the 365 era, the Halo games were its own engine.
Look back at the dark Unreal 3 period 2006-2010. Most UE3 games looked like shit. A brown bloomy mess.