This is why Amazon doesn't get prosecuted for monopolistic practices, but Apple did for price-fixing on books. Amazon lowers prices (good for consumers, bad for competitors) and Apple was trying to raise them (bad for consumers).
The European Union would look at this differently. They say that one company possessing too much market-share is inherently bad for the marketplace.
Can you really trust an Amazon to keep having a focus on low prices? What about when there is no more competition?
To answer that question I found one more article. You have to dig, but it's there at the bottom of the top paragraph of page 4:
Basically, you can trust them if their anti-competitive (but pro-consumer) price lowering has to stay low because any raising of prices will result in new players immediately entering the market.
What does all this have to do with technology? Well it helps explain some differences between the US and Europe.
The other thing that is related is that there isn't really a software or online business that isn't susceptible to a new competitor.
To create software you may need software developers and servers, but you don't need other raw materials or a factory, so the cost is much lower than in analog industries.
Software business are inherently winner take all because world-wide delivery is so simple, there are no geographic restrictions on products, therefore the best will win and when they win they will win very big.
But they can only stay on top if the innovate relentlessly or buy companies who do.
Otherwise someone will find away to come along and eat their lunch.
Those are rockets and they hold up the cloud. Those black hash-mark areas are patches in the cloud where things didn't work right. Because of these flaws someone needed to sew the cloud together. The patches are comprised of 81% code and 22% duct tape.
Why don't the cables burn up in the rocket exhaust? That is because of trained monkeys wearing asbestos suits. When the cable breaks or one monkey burns up, a monkey is added to the chain.
This concludes our brief tutorial on the cloud.
Here's the deal. This was inspired by a discussion with a client about a large cloud service provider. The service provider informed the client that the hardware that their instances ran on was bad and needed to be replaced. This is not the first time this has happened.
To me this revelation of 'hardware problem' feels tone deaf because everything about the cloud (which I mostly love) is predicated on us (the customers) not caring about hardware anymore: pricing structures, product offerings, marketing materials, billing. It seems wrong to then blame the hardware when it is convenient. My client didn't ask for you to tie their instance to some faulty hardware. My client had previously been entirely oblivious (and rightly so) to what hardware the instance ran on. Why don't they just quietly move the VM and fix the problem themselves?
Even if it was totally manual, it would give me a lot more faith in the magic and that they have their stuff together.
Truly, I love the cloud. Even if it is imperfect, it powers a lot of the modern world (including this site). I love it mostly because it is a technical marvel and it empowers business, but this customer service flaw makes me doubt the technical greatness. Why do that?
I really believe that cloud, IoT, and mobile technology are job creators in the long run, because there will just be so much of it.
Just, please, don't blame the hardware when the rest of the time you don't want me to think about it.
I've posted this article recently, but it got me thinking about why code is harder to read than to write. So, I will post it again, to make your life easier and explain why I think that code is still harder to read than write, even all these years later. Here's the article:
The title of this post seems counter-intuitive because we think of reading and writing in relationship to human language, but programming languages are not like human language.
What are the important differences? Here is the main one:
Programming languages can't be read aloud.
So when we talk about 'reading code' we're using 'reading' in a purely metaphorical sense. When you 'read' code you don't actually read it - you're looking at it and trying to make sense of what it does.
This is nothing like reading a book, paragraph, or sentence written in human language.
When you review code you study, you re-read, you look things up. You jump around from file to file. You may consult web pages. Even in programming languages you are familiar with and with a business domain you know, these tasks can be time consuming.
You're trying to 'read' something that can't be read, across many files, and trying to ascertain the author's intent not just comprehend a sentence.
An equivalent would be trying to read in a language where you had to look up every third word, every time you read something because:
Every author used the language in a novel way. AND
Every page of a book was put in a different file and they were constantly referencing each other and not in order.
It would be hard. And it would not really be reading. That's what 'reading' code is.
If you are a developer what code are you accountable for?
Is it only your own? Is it your own plus that of a system that you've worked on for some period of time? Is it your team's? Is it every project ever worked on at your company?
I ask this because I've seen a lot of different answers and I will share with you my own approach to this and why that has been my approach.
When I approach a code base I did not create, my first question is to ask, "What can I learn from this code?". This question can and should consume you for some time. You won't know the answer right away, if you think you do, you probably aren't listening closely enough.
Once you know what you should be learning and have begun to learn you can ask how you can make it better. There are always ways to make improvements and to meld your learning with what you already know.
At no point during this process do I use the phrase 'spaghetti code', precisely because it places the source of misunderstandings outside the self onto an inanimate object: 'the code'.
Code is, at one level, a tool to communicate to a machine what you want it to do. It can't be 'spaghetti' if the machine understands it and does what the humans in the room wanted it to do.
On another level, code is a tool to communicate between one developer and another the intent to make a program and what that program was supposed to do. You may choose to blame the previous developer (who completed their assignment), but I don't see how that helps any business situation you happen to be in.
My approach was to be accountable for all code that I touched.
For code written, from scratch by me, I am accountable for all of it, no matter how long ago I wrote it.
As a boss or manager, I don't necessarily expect every person to have that level of accountability, but I expect them to be on a journey that moves in that direction.
And I hate, hate, hate the term 'spaghetti code' (if that wasn't already clear) because it is such a victim phrase. Are you the victim of code? I certainly never wanted to be. I wanted to win and make the code do what it was supposed to do.
Think of the great developers you know. Do they use that phrase? I've never heard one do it.
Add to the list a couple of other things that I feel the need to learn for my side project:
But I am having the darndest time with TypeScript. Not so much the syntax or language or ecosystem. Especially for ecosystem, WebStorm has been enormously helpful.
No, with TypeScript I am struggling with debugging and wrestling through problems in the browser. So far my journey could best be described as 7 steps forward and 8 steps back.
By which I mean, there was an initial phase where I thought I knew what I was doing - this was validated by "successes" where I got actual code that I wrote transpiled and working in the browser.
But as I ventured further in - mainly to get the Angular http module working. I have been deconstructing my working code more and more to strip it down to the bare bones and try to understand why a couple of things have gone wrong.
The end result is that I will understand the whole thing better, I suppose. But it is still very frustrating, and I am not yet at the end of my "journey backwards", so to speak.
Also, I'm removing one:
Simply not worth the time for what I'm doing. And I already understand a lot about databases, if I ever really want to pick that up.