stoshe
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.
> 3 + 4 * 5 - 2 = 21
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.
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.
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).
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.
The site no longer exists, but some of the news about it at the time can still be found: http://www.webpronews.com/open-sesame-googles-newest-securit...
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.