I think the flaw here is that what works today may not work tomorrow and in many situations, it is easy to see where those breaking points will arise.
Take your team sitting in one room building a monolith. Unless the software is intended to always be smaller and targeted, or the software fails in the market, that team will eventually scale and no longer fit in this room, and now you've got a monolithic application that can't be effectively maintained and enhanced by the organization.
There is value in designing your system for the organization that will own it, but there is also a value in designing your organization for the system you wish to develop.
Experience and published research have shown time and time again that whey you try to fight Conway's law, you will lose, so one or the other will have to give. For long-lived applications, you'll find more success if you can alter the organizational structure to fit the system.
Conway's law doesn't make those claims, but this has been tested by researchers and industry giants (a Microsoft team published a paper on this a part of a Vista retrospective) and those papers do make such claims.
Authors can typically "suggest" reviewers for their papers. There have been a few scandals in the past where papers were published after being reviewed by family members, or even the original author using a maiden name. Elsevier, and many of the related companies under the Reed Elsevier family, make their money by facilitating the process, or making data searchable. Once upon a time this was huge as doing either of those things was a significantly costly and time intensive exercise. Today, they continue on pure momentum. If a few major research universities were to band together and form a cooperative non-profit journal, things would start to unravel for Elsevier.
The problem with these systems is that they are very old, and thus do not benefit from many of the more modern developments in the field nor do many quality developers learn the language.
The benefit with these systems, though, is that they are very old. With that age comes completeness. They're battle hardened, thoroughly tested, and a known quantity within the institutions that leverage them.
History is littered with companies that attempted to replace the core of their business with one big project written with newer technology, only to fail catastrophically.
During my first gig with a bank, I was appalled to see the ancient technology in play at the heart of the bank's systems, and the retired developers coming in part time on schedules they set for outrageous hourly rates to do maintenance tasks on that system. Over time, though, I came to realize that this was the most reliable and cost effective solution the bank had available.
The third option listed is what I see happening, but at a much slower pace than the article suggests:
> Basically, Döderlein suggests making light-weight add-ons in more current programming languages that only rely on COBOL for the core feature of the old systems. However, the key thing is how the connection to the old system is made.
> Gradually banks will be able to address each and every product need that they have with new platforms that will replace the overly complicated COBOL add-ons. This compartmentalizes the banks’ COBOL-problem and makes it cheaper to fix, as it won’t have to be done all at once.
It's a glacial pace, but it's being attempted. The heart of the old systems, though, were still untouched last I had visibility into those inner workings.
An individual's data sharing with Facebook is less of the issue, here, though. You personally not using it doesn't prevent you from becoming the common thread that ties others together.
Just because I'm not on Facebook (I'm not), anyone that's allowed Facebook to see their own contacts, in their phone or email, has shown that they are or are not connected to me in some way. Without me actually ever even having an account with Facebook they can correlate this data from users to see who is likely to know one another by a shared connection to me. Just because my particular node on the relationship tree has more blanks than it would if I was a Facebook user does not mean I don't create a node at all.
My guess for this Facebook issue in particular is that the Doc potentially did absolutely nothing herself, but rather all of her patients had mail and phone contact lists that included her and that common thread along with the same geographic area was enough to trigger a recommended match. In other words, this was equally likely to happen even if the doctor never had a Facebook page of her own.
A typical move to subscription based pricing LOWERS costs to the consumer, but the company gets the benefit of more predictable recurring revenues. That makes the pricing JetBrains puts out a little bit of a head-scratcher.
I think we're saying the same thing, but with different slants. The perception of Amazon right now (again, I don't know first hand) is that the work there is extremely intense to the point of maddening, and that can make it very attractive for certain people, and very unattractive for others. If you want to gain good experiences quickly and build your resume with a big name, it's a very viable option for you so long as you are willing to make the trade-off in work/life balance and stress. If you're no longer at that point in your career, it's not going to be for you.
It's purely anecdotal, but it's been a well known "fact" within my circle of developers that working for Amazon is a death march and not something you should consider unless you are desperate or intend to make it a short stint where they are offering a title and pay increase worth the 1-2 years of hell that working there would be.
True or not, perception is reality and Amazon has attained a rather poor reputation in the circles I travel. I have considered positions with them in the past but because of my perception of what working for them would mean, I've rejected several for not being worth it (pay increase not big enough), and one due to simple logistics (they wanted me in a city I wouldn't move to).
There is a very serious benefit to recognizing a losing hand and folding before you're in too deep. You see a weakness in Google's execution, and I'd agree in some places, but there is some wisdom in closing up failed experiments rather than doubling down as Microsoft has done with several of their investments in the past.
The benefits of driver-less vehicles in terms of accidents and fatalities aside, consider for a moment just how under utilized the current transportation capacity is in this country. On average, even at peak drive times, what percentage of vehicles are actually being used? Just look down your street or at any parking lot you pass on your way into the office.
In order to get the convenience of not having to call a taxi which could then require a long wait every time we need to go somewhere, we take out loans for tens of thousands of dollars to own a vehicle that is all ours. We then pay to maintain the multi-ton machine, build custom paths and storage buildings on our homes just to store them, and everywhere we go large swatches of land are set aside just to give us temporary storage for our vehicles since we can't reasonably visit any location without this machine in tow.
In a reality where we must own a vehicle in order to move around quickly and easily, all of these things make perfect sense and are just a part of our lives so much so that we don't even think about them most of the time. This one "little" change can completely transform it all.
Even if Google never moves to acquire Uber, though, they may simply look at it as Uber creating the social acceptance and market demand for this type of service. That would then make Google entering into the market with a competing service later an easier and a more predictably profitable venture.
"Gear", in this case, meaning the medium the photos are stored on. The headline (and image in the post) try to make it sound like thousands of dollars of camera equipment is on the line here, when really we're talking about SD cards. It's a modern equivalent of saying that if you violate the contract, you have to give us the film and/or negatives.
How is this different from the phone based 2-factor that Google once had for their own products? Honest question, not being sarcastic here.
Google used to have an authentication system that would display a QR code on the screen which you would use your phone to navigate to. That URL would then, assuming your phone was already authenticated to Google, log you in on the computer as well. I was trying to remember the name of the system, but can't come up with it.
The short version is that Google determined the system to be too insecure and vulnerable to exploit and canceled the system.
Take your team sitting in one room building a monolith. Unless the software is intended to always be smaller and targeted, or the software fails in the market, that team will eventually scale and no longer fit in this room, and now you've got a monolithic application that can't be effectively maintained and enhanced by the organization.
There is value in designing your system for the organization that will own it, but there is also a value in designing your organization for the system you wish to develop.
Experience and published research have shown time and time again that whey you try to fight Conway's law, you will lose, so one or the other will have to give. For long-lived applications, you'll find more success if you can alter the organizational structure to fit the system.