Hi there.
Newbie to this forum. Embedded and telecoms sw engineer, over 9 years experience C/C++, plus various other bits. Also been a software tester.
I would like to comment on the following.
James is blackmailing NXT, dumping just to stamp his feet, and for what? He could have fixed the problem.
Assumption: Fixed the problem = fixing the code.
Fixing the code isn't the main issue (unless the codebase is especially messy).
- Testing the fixed code takes time (and if there are any unintended consequences to the fix then you go around the fix and test cycle again).
- Then you have to deploy the fixed code and again check for any issues (although having a testnet should minimise this).
- In amongst this you have to be supporting your customer base, whose deployments have been broken, this is quite a drag on getting any of the above done (answering angry emails, reassuring them that a fix is on the way, etc).
- Once full tested then you issue the fixed code to customers, with instructions on how to upgrade.
- For those customer who are less technically advanced, you then have to handhold them through deploying the fixed code. It might even come down to remotely deploying it on their behalf.
- During this time you may become aware of issues with the customers system (incorrect configuration), you may also have to analyse and fix that as well in order to deploy the new code <-- worst case but possible.
- Also if you have customers with their own code added on then fixing this will also take a lot of time.
Interestingly, the more successful the product, the more live deployments you have, the bigger the headache.
All the time you are doing this means that you are not doing what you had planned to be doing (i.e. developing your own code, meeting the set deadlines). Also it normally means you are fixing an issue created by a partner/thirdparty at you own expense.
Several times in my career I've worked on projects where you partner with other companies, using their API, and then they change it, and it breaks your code and therefore your customers code.
It tends to make developers cranky, because it's such a pain. It can also cause you to rethink if you still want to partner with this company (especially if this becomes a habit), or maybe partner with someone else (also a pain because that will probably mean major changes to the codebase, or maybe there is no alternative to partner with so you just have to accept it and work out procedures to mange this when it occurs again).
So I can see why the api change will have upset developers that rely on the API.
Apologies - I don't mean to criticize anyone with the above. I just wanted to point out that, yes, if we just had to fix the code then it wouldn't be a problem, but it is far more complicated than that when you are supporting a live customer userbase already.
Cheers
Dave