ActiveState has over twenty years of experience creating custom solutions for Python, Perl and Tcl open source projects, including:
- Custom installers featuring portable languages
- Custom distributions for EOL language versions (such as Python 2)
- Custom distributions for “big iron” platforms, such as Solaris, HP-UX and AIX
- And much more
In some cases, it can be far more efficient to outsource custom engineering work rather than tackling it in-house. This blog is intended to help you make the best business decision for your needs.
Identifying Software Core Competencies
Generally speaking, any application or service functionality you want your customers to use on a regular basis should be considered core development work that you would expect your internal team to tackle. But what about features that customers will use only once, such as when initially installing your product? Or a feature that only a handful of customers, albeit key customers, require?
And then there’s the question of open source tooling, which is something your developers use every day, but the more time developers spend on tooling means less time working on features/functionality. Open source tooling is a commodity, whose use offers little in the way of differentiation for your organization. It’s not something your team should be spending an inordinate amount of time on, but that’s exactly what’s happening if they’re all building/updating their own development environments, for example.
If your organization has adopted agile development, you know that maximizing the velocity of your development team is key to getting more code completed per sprint. But velocity points are often allocated to more than just coding “core competency” features – they can include all kinds of “work to be done,” as well:
- No expertise on the team to tackle a new task? “Work to be done” will need to include research and investigation.
- No development environment for the project? “Work to be done” will need to include build engineering.
- Code vulnerability in an unsupported language? “Work to be done” will have to include not only the usual investigation associated with any remediation work, but also patch creation or else backporting the fix from a supported version of the language.
The further you move away from your team’s core competencies, the more time and resources “work to be done” sucks up, making an outsourced solution increasingly viable.
Three Keys to Cost-Benefit Analysis
For work that falls outside your team’s core competencies, you’ll need to make a build versus buy decision. Of course, any decision to build or buy features/functionality needs to be backed up by a cost-benefit analysis that should take into consideration the following factors:
- Budget – the cost portion of the cost-benefit analysis should include not only the cost for the original implementation but also for ongoing maintenance and support.
- For internal projects, this is typically the cost of your internal development resources. Keep in mind that studies have shown developers spend ~30% of their time doing maintenance work.
- For external projects, this is either a one-time fixed cost, or else an open-ended “time & materials” cost, which increases the risk of running over budget.
- Time to Market – if your team has no resident expert, the time to learn, implement and debug a homegrown solution to a complex problem can significantly increase the risk of delaying time to market versus hiring an expert that can deliver a solution in a timely manner.
- Opportunity Cost – time spent working on functionality that isn’t your core competency is time spent NOT working on advancing your product. As a result, you increase the risk of falling behind your competitors. Using an external vendor frees up your internal resources to focus on more value-added features that can close competitive gaps.
After weighing the risks, the costs and the benefits, a return on investment (ROI) calculation should point you in the right direction for your business.
Conclusions
With decades of experience working with open source languages, and hundreds of thousands of man hours of expertise in Python, Perl and Tcl, ActiveState can help your organization overcome the challenges you may be facing in creating timely, cost-effective solutions for your customers. Some of the custom engineering projects we have successfully completed for our own customer base include:
- Debug builds of runtime environments, simplifying bug identification and troubleshooting.
- Custom installers that include portable versions of runtime environments, ensuring that all customers have a standard deployment, and thereby reducing customer incident reports.
- Backporting of security fixes for EOL languages for Python 2, ensuring customers can continue running their revenue generating applications in a secure manner.
- Extending legacy applications with a Python API, allowing users to more easily integrate them with their own applications and systems.
We can do the same for your organization. And of course, we also offer commercial support and maintenance for all our Python, Perl and Tcl solutions, as well.
Have a complex or time consuming Python, Perl or Tcl build/feature that’s not part of your core competency? Contact Sales to find out if custom engineering for ActiveState is the right solution for your organization.
Need more information about build engineering? Try these:
