Firstly, it's important to note that on Hacker News, responders are probably going to be biased towards writing software that solves your problems.
Secondly, it sounds to me as if you are jumping ahead, and favoring one particular solution, rather than looking at this as business problem. If I were tackling it, I'd be making a list of all the possible solutions:
- Stay as you are
- Stay as you are but make a deal to buy the source code/or perhaps the company that makes the product if that's feasible/or the division
- Buy-in an entirely different commercial platform
- Build your own as a clone of what you already use, and extend out
- Build your own as an entirely new system - something that exactly right for you
- Glue systems together to get something that works for you
- Probably there are more.
Then I'd list the advantages and disadvantages, the risks, and guesstimates on costs and monetary benefits. This does not need to be a long process - a month and a spreadsheet.
At the end of this process, I'd be thinking about next steps to facilitate the likely candidates. E.g. initial talks to vendors or approaches through an agent about buying the company.
If build-your-own is still on the list, then I'd look at having someone spend a few months documenting and thinking about your existing software, specifically with the aim of mapping out the likely pain-points - e.g. does the system use an interesting scheduling algorithm and if so, what is special, and where does it fail?
This stuff will eventually form the basis of spec for the backbone of a new system. But it's first job is to build some organizational expertise in the software, rather than the use of the software. You want some maps of the territory.
If at the end of this, you have a sense of the pitfalls, then I would think about mapping out what is really needed - interviewing all the levels of your org that have an interest - from the end-users/operators, through to the board. You want to find the stuff that's not documented. You probably don't want to get to a spec, but you do want to have a document that accurately reflects your needs (and also the love-to-haves, and the opportunities to extend)- and it can be used to judge whether a buy-in or a build-your-own can successfully meet your needs.
If you even get this far, this is the point at which you should be deciding between build-your-own and buy-in.
And if it's build-your-own, then this is where you take all the stuff you've learned to spec it.
And if this is the solution, I'd be thinking about what technology will serve you best at least cost, now and ongoing. E.g. should you be building a web app, and if so, what tech could function as the core, so that you don't have to spend money on re-inventing layouts.
Strategies - these are not secret:
- Make your business a place that people want to work - that means getting rid of bullies and trouble-makers, and encouraging a supportive environment
- Make sure there are challenges, and they are achievable
- Offer excellent packages - this can be a mix - work-from-home, healthcare, pay, etc - it's the whole package that matters
- Understand that if you don't offer people a pathway to improvement, then you will lose them
- Ensure that the actual physical work environment is conducive to concentration
- Ensure that the software team are a proper part of the fabric of your company, and not an afterthought.
Transitioning software too, is not rocket-science. You need a solid plan for the transition. You need to train people constantly. You need changes to be small, incremental wherever possible, and clearly communicated ahead of time; you want the people who use the software to feel in control - that this is to help them, rather than to hinder them. And if there are organizational changes as a result, then you need to be sure that you are not shafting staff; you want people on your side, not against you.
- Build a small core team who know the problem in depth. You really need to understand v1 and v2 data and the mappings, as well as the functionality in each.
- Build a test system that is insulated from customers; you want to be able to use this as if it's the real thing, but to be absolutely, completely, dead certain that it will not affect live systems, and that no output from this will reach people it should not. Make sure there are visual indicators as well as logical traps on data exiting this system. Make this repeatable - you are going to use this system a lot to re-run tests. Despite the firebreaks, you will have some brown pants moments.
- The ideal is to move from v1 to v2 gradually, using a passthrough system. However, ime, this is often not possible, and at some point there will be a hard switch between systems.
- Develop migration plans with multiple off-ramps and fallbacks, and monitoring. By the time you press the switch you should know exactly how everything will work, and you should have no issues, despite this, you should have layers of contingency to allow for business as usual when the unplanned happens. This is a mix between technical and business and it should have been properly understood by everyone involved. Monitoring is critically important. Your plans should include aftercare... for example, what happens if you think the migration is successful, and two weeks later you discover an issue with 200,000 transactions. How will you reconcile? How will you communicate with the affected parties?
- Look for classes of things... Can you find 100,000 dead accounts that can be removed? Can you find 500,000 that have only ever had one transaction? Look for classes of errors - and fix them before migration. Keep a record of all of this, and make certain that you have covered all cases and all records. If you are lucky, you will be able to migrate classes from v1 to v2 and have the passthrough transparently manage this.
- Ideally, have a log of transactions that can be replayed on demand. So that you can run systems in parallel and so that in the event of issues, you can unwind.
- Keep written logs of all the things that you and the team do. You _will_ forget stuff you've done. This is true on an hour to hour basis as well as a month-to-month basis.
- Work on making migrations fast. Can you organise it so that 16m migrations take 10 minutes? This allows you test and retest. You want anyone to be able to run on-demand migrations.
- Look to the end-users. For an upgrade to be successfully deployed, both the business and the end-users must be happy; you will want to run test groups, pilots, group conversations, and make your team available to the end-users. Nothing should be surprising by the end. You will also need to know that v2 is performant - catch these problems before they become general issues of dissatisfaction. Look also for pain points and try to ensure that you remove them in v2. Change is painful, but if you can show that there are benefits you will ameliorate much of the criticism.
- Have defined end-points. You do not want to be doing this in 5 years time.
No, that isn't exactly how insurance works, and it would be almost pointless for individuals if it did work that way.
Instead, it works by bucketing risk. In the simplest form, everyone is in one bucket, ignoring individual risk. That means that all other things being equal (e.g. size and value of your house), despite you have low risk of your house flooding, you would be paying exactly the same premium as the person who who has very high risk because their house is built on a flood plain.
Of course people paying more for their risk than it warrants may see that as unfair - so insurers use more buckets - e.g. bucketing high, medium and low risks.
But there's a delicate balance here - for instance, insurers may just decide not to insure the high-risk category. Or even if they do, the premiums may be unaffordable or the insurance benefits substantially restricted. And the natural extension of categorizing like this is to put an individual in a category by themselves - and then to limit payout. Essentially making the insurance not any better than a savings account, and probably worse if you don't claim at the beginning of the policy, before there's a large pot in the savings account.
From the point of view of perfect capitalists, the insurers would like to insure people with negligible risk, for high premiums, for low benefits - to make the most profit. From a social-good point of view, we would like insurers to cover risk that people cannot control (e.g. genetic risk) for reasonable premiums and good benefits. Categorizing lives somewhere between these two - a kind of necessary un/fairness.
Another out of topic - I keep seeing your comments and in a comment about two years ago you said your profile had a link to your research. I looked at your profile to find out a bit about the things you are working on, but since then you've edited your profile. Any chance you could add a link/links again for a day or two?
It's perfectly possible that Interfax is a reliable source of information about Ukraine, although it seems to be mostly based in Russia and mostly staffed by Russians, but we do need to remember that they are subject to the "15 years in prison for 'fake' news" law. So I'm taking this with a pinch of salt, or maybe a small handful, until more is known.
Physics has had a 470 year head start, if you measure from Copernicus. Of course it looks simple. It wasn't simple at the time; it's taken something like 14 generations so far.
I'm not especially pro-Samsung, and I'm just one consumer and I'm sure that for every unhappy one, there's someone who loves LG or loathes Samsung, but I will never buy any LG product at all if there's something else available which is about equivalent.
They sold me their top-end phone, years ago, for a top-end price, on the basis that they would update Android in the next three months. It was a nice phone, but three became six, which became a few years - three or four or five.
Eventually they did offer the option, of course by then I was not using the phone, but I tried to upgrade anyway, and my phone would not upgrade. There was no support when I asked apart from 'download it and it should work'.
So in answer to your question, it's not about Samsung, it's about LG for me - and they destroyed all credibility with me - I don't believe claims on build quality, I don't believe claims about support, I don't believe any of their advertising. And I actively advise friends not to buy their products, when asked.
- True hard-core Brexiteers really do care about sovereignty. They are nationalists.They want nobody but themselves to have any element of control. If that means the destruction of the economy, they are fine with that, like nationalists everywhere.
- The Conservative party has been interested in the idea of the UK as Singapore-upon-Thames. Partly this is about reducing the role of the state (and thus taxes, one might think) and partly about re-introducing a vibrant manufacturing economy. Many of the people who punted this idea are also Brexiteers. Being a member of the EU was a barrier to establishing a low-wage economy that can compete with the East. They view the EU as outdated because it's a rule-based organisation. There are rules on social standards, product safety, animal health and a huge array of other matters. These people will tolerate temporary economic setbacks (ten years?) in the pursuit of jam in the future.
- Opportunists. People who are motivated by power, and will be wherever there's the opportunity to be in control. They will sacrifice anybody else in its pursuit.
I don't think that brought in bee keeping exists very much in the UK. I live near the edge of fields, in a semi-rural setting. I've never seen it. I have see plenty of wild bees and bee hives.
I guess, I can say that I worked on a project for introducing interactive advertising displays into their branches. It was killed because they didn't like the power cabling.
I disagree a bit with the article. The premise is that you shouldn't make login forms behave badly for password managers, and I agree with this. But at the same time, people using password managers are not necessarily the major use case for a site or some software. You should make it easiest for the largest number of people you can, and that might mean decluttering the UI and co-incidentally making it harder for password managers.
Similar. I can't quantify, but I seem to be getting less useful results, certainly on the first page, and often beyond. I'm not sure it's not just perception though because I've not kept any log and it's also possible there are genuinely no matches to the searches I've been doing.
I've worked in the same market as you, I think, from the hints in your comments.
I've run or had a hand in running conferences and trade shows, as well as having built software and systems to keep the show on the road, from registration systems, management systems, surveying and apps. And I know the business side of startups too.
Perhaps you want to have a chat. HN has my email.
Without knowing anything, I'd speculate that if you aren't finding traction, then it's related to the structure of the conference/exhibition market which is a tough space to crack.
Secondly, it sounds to me as if you are jumping ahead, and favoring one particular solution, rather than looking at this as business problem. If I were tackling it, I'd be making a list of all the possible solutions: - Stay as you are - Stay as you are but make a deal to buy the source code/or perhaps the company that makes the product if that's feasible/or the division - Buy-in an entirely different commercial platform - Build your own as a clone of what you already use, and extend out - Build your own as an entirely new system - something that exactly right for you - Glue systems together to get something that works for you - Probably there are more.
Then I'd list the advantages and disadvantages, the risks, and guesstimates on costs and monetary benefits. This does not need to be a long process - a month and a spreadsheet.
At the end of this process, I'd be thinking about next steps to facilitate the likely candidates. E.g. initial talks to vendors or approaches through an agent about buying the company.
If build-your-own is still on the list, then I'd look at having someone spend a few months documenting and thinking about your existing software, specifically with the aim of mapping out the likely pain-points - e.g. does the system use an interesting scheduling algorithm and if so, what is special, and where does it fail?
This stuff will eventually form the basis of spec for the backbone of a new system. But it's first job is to build some organizational expertise in the software, rather than the use of the software. You want some maps of the territory.
If at the end of this, you have a sense of the pitfalls, then I would think about mapping out what is really needed - interviewing all the levels of your org that have an interest - from the end-users/operators, through to the board. You want to find the stuff that's not documented. You probably don't want to get to a spec, but you do want to have a document that accurately reflects your needs (and also the love-to-haves, and the opportunities to extend)- and it can be used to judge whether a buy-in or a build-your-own can successfully meet your needs.
If you even get this far, this is the point at which you should be deciding between build-your-own and buy-in.
And if it's build-your-own, then this is where you take all the stuff you've learned to spec it.
And if this is the solution, I'd be thinking about what technology will serve you best at least cost, now and ongoing. E.g. should you be building a web app, and if so, what tech could function as the core, so that you don't have to spend money on re-inventing layouts.
Strategies - these are not secret: - Make your business a place that people want to work - that means getting rid of bullies and trouble-makers, and encouraging a supportive environment - Make sure there are challenges, and they are achievable - Offer excellent packages - this can be a mix - work-from-home, healthcare, pay, etc - it's the whole package that matters - Understand that if you don't offer people a pathway to improvement, then you will lose them - Ensure that the actual physical work environment is conducive to concentration - Ensure that the software team are a proper part of the fabric of your company, and not an afterthought.
Transitioning software too, is not rocket-science. You need a solid plan for the transition. You need to train people constantly. You need changes to be small, incremental wherever possible, and clearly communicated ahead of time; you want the people who use the software to feel in control - that this is to help them, rather than to hinder them. And if there are organizational changes as a result, then you need to be sure that you are not shafting staff; you want people on your side, not against you.