It can be really time consuming and take the team's focus off of the primary goal as well, so we try to get teams to focus on the things that they are uniquely qualified to do, rather than build software to support their operation.
As a dev currently building out several fairly-complex in-house tools for a small startup, I can relate to this first-hand.
It’s enormously frustrating as a perfectionist with a slightly neurotic obsession with (in a balanced and healthy way, trust me ;D) and appreciation for best practices, I have had to (against better judgement) sacrifice many things such as extensive time spent on in-depth automated testing, abstraction of reusable code for polymorphism and shared packages, extremely in depth documentation, and many other aspects that would contribute to long term viability and efficacy. This is of course for the sake of a business-friendly timeline, and that I can appreciate.
There is a definite balance, and I have (and continue to) learn enormously from this business view on software. The “it just works” ethos can be scary further down the road. The economic upsides to this perspective for an MVP or POC type of development are absolutely massive, but I can’t help but think this could be supplemented further by dedicating more resources to focusing on best practices.
Whether that focus comes from an internal team with more dedicated resources or a third party, I’m still unsure as to how that decision should be made.
Either way, it has been very helpful in further developing my skills in communicating things like tech debt (what notions like automated testing actually mean in terms of value to a SaaS company) to the CEO and other colleagues who do not have software dev experience.
1. Building in house is expensive, slow, and painful, and most teams have better things to spend their time on. We’re helping several teams move off their in-house solution because they aren’t satisfied with it.
2. We are building out automation and scripting capabilities. We support integration with Python scripts and other local commanding destinations via our API.
3. Love the idea! We already support real-time comments that are embedded in procedures. We want to build out even more things along those lines to streamline communications.
1.) How do you convince space orgs that using a third-party SaaS offering is a better approach than building it in-house? Especially as part of the ERP the org may be using already?
2.) Does Epsilon3 support scripted procedures? What language(s) does it support?
3.) Any thoughts on a ChatOps like interface (e.g. Slack)?