6

I have started work on writing a tool to version the database schemas we use at work and enable migrations under version control. My first research into existing tools turned out to be too cursory due to searching for the wrong key words and I'm now aware of Flyway and Liquibase. Now I'm wondering if it wouldn't be better to scrap this pet project and just use one of these tools.

Some background: We work in a small team, namely one developer and several sysadmins and domain experts, who will use the software, but can't be expected to write any. Apart from different software project we use internally (a web platform here, some ETL processes there) we also have projects for each client that use the internal software projects in different capacities. Sorry if that sounds vague, but I can't talk in detail about it.

This is already one thing that may necessitate writing our own tool. As far as I can tell both tools mentioned above don't make a distinction between a schema and a project. We need to use the same schema for any number of projects. Still, there might be an easy way to customize these tools for this task.

Writing our own tool obviously has a lot of disadvantages and the only other uptake I can see is that development of the tool itself is much easier if you're familiar with it compared to having to understand a million lines of code.

I could also argue that the tool needs to be as simple as possible to be usable by the entire team, but then a wrapper around one of the "commercial" tools is likely still less work than getting the custom tool to a completely workable state.

What I'm asking is now what other aspects of "build vs buy" I have to take into consideration here. Does it all come down to the expected work hours poured into making a solution workable? Is it ever worth it to write your own solution?

Improve this question
1
  • From what you tell this question is hard to answer. It depends on a lot of things. In general, in my experience of-the-shelf tools typically do 90% of what you need and then you find yourself working around the limitations for the entire life cycle of the product the tool was supposed to support. It can be utterly frustrating needing a simple little extra from a black-box kind of tool you have no control over.
    – Martin Maat
    Apr 4, 2019 at 8:24

4 Answers 4

Reset to default
6

Is it ever worth it to write your own solution?

In theory, no. Unless it's your companies product, or not available at all, you should use an off the shelf component; and there are many DB versioning softwares out there.

Your time is better spent adding features to your product

I remember reading an article in The Register some years back where they had gathered various Tech CEOs to talk about tech projects in their respective companies. They found that they had all spent millions having customisations built into standard software that they, in hindsight, really should have changed their internal processes to match the software instead.

I'm sure that this will match many peoples experience, where they find a legacy tool is incompatible with current best practice and has no migration path due to it being built internally years ago and the devs have left, or having had customisations added by contractors when it was installed.

In practice, for a small company with limited requirements and no budget, writing something yourself might be better than having nothing at all. But you should be looking to migrate away from your custom method as soon as possible.

Improve this answer
1
  • Comments are not for extended discussion; this conversation has been moved to chat.
    – user53019
    Apr 6, 2019 at 0:59
3

Is it ever worth it to write your own solution?

Absolutely - but only in a limited set of circumstances:

To augment your own technologies

Your software may have certain features that make it difficult to readily interact with other 3rd party software without significant development effort.

The software doesn't exist

You may require software that simply doesn't exist and possibly never will do. Hint: beware salesmen promising that product X will have feature Y "very soon".

You require specialist features

You may find that although software is available, it isn't easy to interface it with your existing systems or perhaps it doesn't perform well enough. I remember seeing about a dozen vendors in a previous role to source software to sort very large data files. While they all performed admirably for general sorting tests, they struggled with our data. In the end we wrote our own sort software and it outperformed them all comfortably. We even had several enquiries about selling our technology back to the vendors.

That isn't to say you should just go ahead and do it - due diligence should take place to ensure it is absolutely the correct decision.

Aside from the standard make/buy decision, you may want to look into outsourcing it. This would allow you to concentrate on day to day work while the risk is shared (in the form of escrow). If you don't want to risk sole traders, recruitment agencies are often willing to make developers available to complete work for a set fee.

Improve this answer
1
  • The last point about outsourcing is interesting. I don't think it's an option here, but I also never thought much about it. I'll make sure to consider it with other topics when they come up.
    – Etienne Ott
    Apr 2, 2019 at 12:01
1

I want to bring some nuance to cases where I think writing your own has advantages.

  • it happens regularly that you only need a small part of an off-the-shelf solution. As the off-the-shelf-solution needs to take into account all cases and all situations it can be quite bloated for your specific case.
  • all the plumbing to let various off-the-shelf-components work together can sometimes have a worse negative impact on the project then writing something yourself (personally I think this goes wrong in the JavaScript community)
  • for complicated projects to fully integrate an off-the-shelf-solution it can mean that you have to build a lot of ugly workarounds just to fully integrate it into your own products/pipelines. I've worked at a large game company where at a certain point they ditched the "tool/editor framework" that was being pushed by the parent company. I think it was a big effort, but they were able to ditch a lot of workaround code and actually make something that beautifully integrates and has less hacks/plugins/other plumbing. Of course for a game company editor tools are quite close to their core business.

But both other answers are great, and my gut feeling in this particular case is that you also shouldn't write your own.

Improve this answer
1

This is an interesting case.

Normally, and possibly this case as well, you should immediately kill your darling and implement the off-the-shelf solution.

However, a bare migration package is a really simple piece of software. Most off-the-shelf packages are too bloated because they include a database abstraction layer, and you would simply use the one you're already using in your app. You could tailor your own solution to exactly fit your needs.

Like you mention in your example, with the multitenancy. The solution we have to use, is a separate migration table for each project/customer with each its own configuration file. That's a lot of duplication that you wouldn't need.

So as long as you keep it really simple it could be better to use your own software. But if you find yourself needing extra features, delete it and get the off-the-shelf product.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.