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.
> 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.
You're using the wrong tool for the job there, if you want people to be supported regardless of their actual risk levels then you should get socialised medicine rather than artificially restricting what factors insurance companies can take into account (and there will be plenty of information leakage from due to other factors they are allowed to consider correlating with the banned ones).
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.
I have a Samsung phone that used to be their top of the line. I have never updated it because I know the next update disables call recording. I believe any subsequent phone has non-working (probably not in every region) call recording so that is a deal breaker for me.
It seems like they got lobbied by insurance companies who scam people over the phone (they promise options that turn out to be a lie) and you can't really prove it unless you record them. Call recording saved me few times from losing money. You can also record calls with your parents, so you can listen to them forever.
>It seems like they got lobbied by insurance companies who scam people over the phone (they promise options that turn out to be a lie) and you can't really prove it unless you record them.
Seems like a weird conspiracy theory to me. What leverage do insurance companies have over google? Moreover, isn't it trivial to record with a second phone?
In most of the customer support calls I make, I speak up right after connecting that I'm recording the call for legal purposes while the IVR plays. It's a bit tricky for marketing calls received, but I try nonetheless.
- 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 understand how the UK becomes a manufacturing economy without drastically lowering the standard of living.
And the Singapore on Thames from a regulatory perspective is a non starter. If someone is looking to operate out of a Singapore like nation why would they choose the UK? The only reason would be proximity to the EU but the EU will almost certainly erect massive barriers if the UK did anything of the sort. And so would the US. The US would almost certainly not allow the UK to undercut its already low standards.
Any other major country would be better served by simply locating yourself in Singapore or Dubai or the myriad SEZ’s countries the world over are setting up.
I think there's also a mechanism of the extremist positions driving politics. E.g. Brexiteers that e.g. opposed the trend towards further centralization in the EU wanted out of some of the political influence sphere, but were in favor of e.g. strong alignment on industry and goods (I think Grayling at some point said that he "didn't campaign for Brexit for the right to produce motors slightly differently"). But May didn't get that done (and put herself in a bad spot in many ways by putting out statements then having to walk them back), and lost out to more hardliner positions. And the opposition was also quite useless in helping a closely-aligned Brexit along (or even having a clear position at all, since it was also split between positions). Some argue that if the energy that went into trying to re- or undo the referendum had gone into getting a closer-aligned Brexit done during Mays time, that could have happened. But it didn't, and everyone looked bad while Boris promised whatever he wanted.
UK has higher standards for livestock than EU, esp. related to well being and roaming space; which is partly why it is very difficult for UK farmers to compete with almost anywhere else. I think you mischaracterize the disparity of standards in that particular space. I don’t comment on your other points.
If the Conservatives think Singapore's state plays a small role, they must be thinking about some mythical Singapore, because the real one is pretty authoritarian (although it seems to act for the public good) and fairly involved. Also, I think it is easier to have "good" government of a city-state size with a homogeneous population than for something an order of magnitude more people and with a non-homogenous population.
Based on my British Brexit friend, I suggest another school of thought: concern for sovereignty but not nationalist. The EU rules requiring free movement result in people from poorer countries willing to work for lower wages depress wages for British people. Also, the free movement is essentially unlimited immigration and the society can't absorb as many immigrants as have been coming.
> If the Conservatives think Singapore's state plays a small role, they must be thinking about some mythical Singapore
These elites speak in abstract terms, typically of things they never actually experienced or seriously analysed. They largely dabble in ideology, mostly to cover the immediate interests of themselves and their cronies.
why do there need to be "schools of thought" about the opposition when people could just ask them? Seems to me to be another instance of the political echo-chambers around contentious issues like Brexit. We'd have much better political perspectives if both sides talked to each other instead of theorising about the other side in their own bubbles.
Ironic given that Corbyn was also Eurosceptic - Brexit was a bipartisan issue with pro/con arguments on both sides of the aisle.
I think it's more "schools of thought" inside the pro-Brexit groups? (although missing any pro-closely-aligned-Brexit groups, since those got pretty pushed out the solution space in the last years)
If that's meant to be the schools of thought for pro-Brexit groups, it's sorely lacking. Though it goes unsurprisingly under-reported, there were many different reasons I heard when talking to people about their support for Brexit, ranging from critiques of EU's fundamentally neoliberal nature, to its bureaucratic inefficiency, to issues of decentralisation of power, issues of tall hierarchies being too one-size-fits-all, the EU's future if the federalist factions take power, and so on. And that's just the handful of people I spoke to at the time, plus some casual listening to campaigners.
Even the idea that Brexit was driven by nationalism, while at least partially true, doesn't really dive into what nationalism means in this context - it's usually just used as a no-no word.
that's the caricature form, yes, in the same way that communism is just gulags and breadlines. But there are nationalist sentiments like "I value my country's unique culture" that have nothing to do with xenophobia. Or "we should control who comes into the country to ensure we get the right kind of labour skills we need".
Funnily enough, if you want to talk racist anti-immigration sentiment - in my parents' lifetime that was the stock-and-trade of the Labour working class, despite being staunchly socialist (which as an ideology is inherently international). Ideology often doesn't make much sense.
There is the idea of Singapore as a small plucky low-tax, small-government country that's extremely high growth and well-off by being at "the gates to Asia" as a trade and manufacturing hub.
And the idea is that an independent UK could be the same for the (slow, inflexible) EU. Which ignores that Singapore actually has high government investments in industries and does the hub role so well because it has good trade integration with its neighbors. Which the UK had in the EU, but could only expect to keep in a Brexit that strongly aligns it with EU policy (which would stop it from giving too much preferential treatment to its own industries etc)
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.