Re: never trust a PM
Only if they find out about it. It sounds as if this guy was one of the JFDI club.
42396 publicly visible posts • joined 16 Jun 2014
"Keeping tens or hundreds of physical/virtual servers and their associated applications operational and maintained 24/7 with tested DR is challenging from both a technical and cost perspective for many organisations with revenues less than US$10k/employee."
And isn't doing just that As A Service supposed to be someone else's computer's cloud's USP? Or is it really just someone else's computer after all?
"Slightly more seriously, an obsolete language rarely used in anger this century is not on my list of demands from employees."
When I retired - in this century - my last client had been a Delphi shop. The last I saw of them they were recruiting more and more people on a project which seemed to be getting rapidly out of control to re-write their flagship product in C#. That business no longer exists.
"Anyway, you cannot sell any because a competitor has the market."
First to market does not always win. What happened to MySpace?
Or you spend the 7 months building a nice adaptable design. The key component becomes unavailable. Because it's nicely adaptable you spend a couple of days adapting to a new one and crap all over the Agile guys while they're out of the market. You can do all sorts of stuff with hypotheticals.
"Charging for changes is a huge money maker."
And those changes being harder than they should to implement is a great money loser.
Rule 1. Development is the process of launching a product into maintenance.
Rule 2. Maintenance is the longest part of the product life-cycle unless the product was canned PDQ.
Corollary: Good development prepares the way for easy maintenance.
Rule 3. Forget the "You ain't gonna need it" stuff. You will. Sod's law variation no 286 says that if you don't have it you're going to need it even sooner.
Rule 4. Think of the most general problem you can of which the immediate requirement is an example and solve that problem. You might find it's no more difficult doing it that way; if the additional requirements come in while you're working and you were already meeting them it'll actually be easier than chopping and changing.
Rule 5. If you tailor your program to fit the requirements exactly the requirements will become your program's limitations.
Rule 6. Your program's limitations may well become its bugs.
Budgets only work to manage costs when there's somebody keeping an eye out on the overall budget and, in fact, on other stuff. I've seen maintenance type done n stupidly bad order, presumably by separate budget holders not coordinating so one operation comes along and craps on the new paint job that was just finished.
"They know about data and code - and they are separate. It seems that this OO thing likes treating one equal to the other. "
Not in any implementation I've seen.
You program in C? If so you'll know what a struct is.
You define your struct. Somewhere, possibly somewhere else, you write the code that uses the struct. The code will have statements to allocate one or more blocks of struct-sized memory and pass pointers to other code that twiddles bits inside those blocks. You might accidentally pass a pointer to some other struct - shit happens. When you've finished with a block, if you remember, you'll release the block. When you compile it binary code goes into your library or program file. When the code executes and gets to the part that allocates memory for the struct that allocation takes place in the data space. As you say, separate.
Now take the OO case. You define a data structure something like a struct but in the same section of code you provide the code that operates on that data structure including code to allocate and release space for the data structure. You compile it and binary code goes into the library or program file and when you execute the statement to allocate space for an object it goes into the data space. There really isn't much difference except the terms used and the fact that it's a bit more difficult to accidentally point the wrong data structure to code.
OK there are some extra bits and pieces such as inheritance but in regard to keeping instructions and data separate any decent OO implementation will do the same thing as your preferred non-OO system.
OO is really an extension to the way we did things for years and the real problem is that its inventors had to follow the industry standard and invent an entirely new vocabulary and make it into a religion, then add a dressing of hype. It took me years to see through that and when I did I realised it was just an improved version of the familiar.
"As they do this, their change failure rate is significantly lower than slower organisations [and] they recover from errors much more quickly."
Unless, of course, the slight error managed to corrupt the live data. Or allow a breach that's been exploited and you have to have a conversation with the ICO. Or something equally nasty.
"That means they will continue to lose money hand over fist until every other form of transportation including ALL public transport and ALL delivery and trucking companies have been driven to the wall."
That assumes they can get hold of enough money. If not it's they who go to the wall.
"That's not a customer service fail, that's an Ops fail. Do not fuck with production, especially other people's production."
That's probably not how the thinking works. Your production - that's what pays the wages. Other people's production - their problem.
The post-mortem should be interesting. If it's just "Our checks had a bug that did such and such instead of that and that. We've fixed it so it won't happen again." that's not very good. The real question is why it was even possible to implement something that would cut off a paying customer without intervention.
It goes back to the comment I made on the Martin Fowler article. It's all very well being a fast mover and fixing your errors so your quality improves quickly; when there's an error it can do substantial damage in the course of discovery.
"the potential brand damage to his cloud biz"
How about potential brand damage to cloud biz in general? It's another illustration of the dangers of relying on other people's computers. Irrespective of whether or not Raisup had their own backups they're still going to be off-line for some time until they're restored and tested elsewhere and their customers pointed to the new location. And all because of of an script run by a hosting co. The poor response might have been specific to DigitalOcean but the risk of a hoster's automated whim must surely be generic.
"Windows has extremely tight integration between programming languages and the operating system."
Extremely tight integration is just what Unixers don't want. It's what raised objections to systemd. You make Windows sound even worse that that although I've no doubt that the systemd authors are doing their best to catch up.
"It would be nice to not come into my office one morning and find that the machine rebooted over night and only recovered half the files I forgot to save on my way out the night before."
1. Don't want the machine to reboot overnight. A machine should reboot when I tell it and only then. Power failure can get in the way. A truly seamless update wouldn't need a reboot, of course but that concept is clearly going to be beyond the grasp of anyone weaned on Windows. To be fair I don't have that on Linux as yet for kernel updates although it does exist at a price.
2. Shut down applications you're not using. The only scope for data loss would then be applications you're leaving to chew away on a big task and in that case, see 1. above.
'Hello - this is Microsoft technical support'
This is an example of AI never doing anything useful. A good AI would switch the call through to Lenny or the like and then turn the speaker on for your entertainment. A better AI would handle the call itself, learning from past experience with similar calls.
"Are GCHQ that dense? Yes, yes they are."
No they're not. They just hope they can get away with it anyway.
They'll brain-wash the Home Sec to let them do it. And heaven help us if the current Home Sec. in the HO gets into No 10. The current Home Sec in 10 has been bad enough but the current Home Sec. in the HO actually wrote an article in the times describing himself going through the process without even being aware of what he was actually describing.
"if a set of data wasn’t believed to be useful, there wouldn’t be a market to buy it"
FTFY
Remember what I keep telling you, the only thing the advertising industry sells is advertising and this sort of thing is one of their products. It doesn't actually have to be useful, they only have to get clients to believe it is, probably by telling them that all their competitors are already buying it.