The only thing that flies faster than time is the progress of technology. Once after lunch, a chip-designing friend excused himself quickly with the deft explanation that Moore\u2019s Law meant that he had to make his chip set 0.67 percent faster each week, even while on vacation. If he didn\u2019t, the chips wouldn\u2019t double in speed every two years.
Now that 2017 is here, it\u2019s time to take stock of the technological changes ahead, if only to help you know where to place your bets in building programming skills for the future.
From the increasing security headache of the internet of things to machine learning everywhere, the future of programming keeps getting harder to predict.
There are naysayers who claim the chip companies have hit a wall. They\u2019re no longer doubling chip speed every two years as they did during the halcyon years of the \u201980s and \u201990s. Perhaps — but it doesn\u2019t matter anymore because the boundaries between chips are less defined than ever.
In the past, the speed of the CPU in the box on your desk mattered because, well, you could only go as fast as the silicon hamster inside could spin its wheel. Buying a bigger, faster hamster every few years doubled your productivity, too.
But now the CPU on your desk barely displays information on the screen. Most of the work is done in the cloud where it\u2019s not clear how many hamsters are working on your job. When you search Google, their massive cloud could devote 10, 20, even 1,000 hamsters to finding the right answer for you.
The challenge for programmers is finding clever ways to elastically deploy just enough computing power to each user\u2019s problem so that the solution comes fast enough and the user doesn\u2019t get bored and wander off to a competitor\u2019s site. There\u2019s plenty of power available. The cloud companies will let you handle the crush of users, but you have to find algorithms that work easily in parallel, then arrange for the servers to work in synchrony.
The Mirai botnet that unfolded in this past fall was a wake-up call for programmers who are creating the next generation of the internet of things. These clever little devices can be infected like any other computer, and they can use their internet connection to wreak havoc and let slip the dogs of war. And as everyone knows, dogs can pretend to be anyone on the internet.
The trouble is that the current supply chain for gadgets doesn\u2019t have any mechanism for fixing software. The lifecycle of a gadget usually begins with a long trip from a manufacturing plant to a warehouse and finally to the user. It\u2019s not usual for up to 10 months to unfold between assembly and first use. The gadgets are shipped halfway around the world over those long, lingering months. They sit in boxes waiting in shipping containers. Then they sit on pallets at big box stores or in warehouses. By the time they\u2019re unpacked, anything could have happened to them.
The challenge is keeping track of it all. It\u2019s hard enough to update the batteries in the smoke detectors every time the clocks change. But now we\u2019ll have to wonder about our toaster oven, our clothes dryer, and pretty much everything in the house. Is the software up-to-date? Have all the security patches been applied? The number of devices is making it harder to do anything intelligent about monitoring the home network. There are more than 30 devices with IP addresses connected to my wireless router, and I know the identity of only 24 of them. If I wanted to maintain a smart firewall, I would go nuts opening up the right ports for the right smart things.
Giving these devices the chance to run arbitrary code is a blessing and a curse. If programmers want to perform clever tasks and let users have maximum flexibility, the platforms should be open. That\u2019s how the maker revolution and open source creativity flourishes. But this also gives virus writers more opportunity than ever before. All they need to do is find one brand of widget that hasn\u2019t updated a particular driver — voil\u00e0, they\u2019ve found millions of widgets primed to host bots.
When the HTML standards committee started embedding video tags into HTML itself, they probably didn\u2019t have grand plans of remaking entertainment. They probably only wanted to solve the glitches from plugins. But the basic video tags respond to JavaScript commands, and that makes them essentially programmable.
That is a big change. In the past, most videos have been consumed very passively. You sit down at the couch, push the play button, and see what the video\u2019s editor decided you should see. Everyone watching that cat video sees the cats in the same sequence decided by the cat video\u2019s creator. Sure, a few fast-forward but videos head to their conclusion with as much regularity as Swiss trains.
JavaScript\u2019s control of video is limited, but the slickest web designers are figuring clever ways to integrate video with the rest of the web page in a seamless canvas. This opens up the possibility for the user to control how the narrative unfolds and interact with the video. No one can be sure what the writers, artists, and editors will imagine but they\u2019ll require programming talent to make it happen.
Many of the slickest websites already have video tightly running in clever spots. Soon they\u2019ll all want moving things. It won\u2019t be enough to put an IMG tag with a JPEG file. You\u2019ll need to grab video — and deal with the standards issues that have fragmented the browser world.
It\u2019s hard to be mad at gaming consoles. The games are great, and the graphics are amazing. They\u2019ve built great video cards and relatively stable software platforms for us to relax in the living room and dream about shooting bad guys or throwing a football.
Living room consoles are only the beginning. The makers of items for the rest of the house are following the same path. They could have chosen an open source ecosystem, but the manufacturers are building their own closed platforms.
This fragments the marketplace and makes it harder for programmers to keep everything straight. What runs on one light switch won\u2019t run on another. The hair dryer may speak the same protocol as the toaster, but it probably won\u2019t. It’s more work for programmers on getting up to speed and fewer opportunities to reuse our work.
After the 2016 U. S. presidential election, word-slinging pundits made fun of data-slinging pundits, suggesting that all of their statistical analysis was an exercise in foolishness. Predictions were dramatically wrong, and the big data people looked bad.
How did they come to this conclusion? By comparing one set of numbers (the predictions) with another set of numbers (the election results). They still needed the data.
Data is the way we see in the internet. Light brings us information about the real world, but numbers tell us about everything online. Some people may make bad predictions based on imperfect numbers, but that doesn\u2019t mean we should stop gathering and interpreting the numbers.
Data gathering, collating, curating, and parsing will continue to be one of the most important jobs for the enterprise. The decision makers need the numbers, and the programmers will continue to be tasked with delivering data in a way that\u2019s easier to understand. This doesn\u2019t mean the answers will be perfect. Context and intuition will continue to have a role, but the need to wrangle data won\u2019t go away simply because a few folks predicted that Donald Trump wouldn\u2019t be elected. This means more work for programmers, as there is no end in sight for our need to build bigger, faster, more data-intensive software.
When kids in college take a course called \u201cData Structures,\u201d they get to learn what life was like when their grandparents wrote code and couldn\u2019t depend on the existence of a layer called \u201cthe database.\u201d Real programmers had to store, sort, and join tables full of data, without the help of Oracle, MySQL, or MongoDB.
Machine learning algorithms are a few short years away from making that jump. Right now programmers and data scientists need to write much of their own code to perform complex analysis. Soon, languages like R and some of the cleverest business intelligence tools will stop being special and start being a regular feature in most software stacks. They\u2019ll go from being four or five special slides in the PowerPoint sales deck to a little rectangle in the architecture drawing that\u2019s taken for granted.
It won\u2019t happen overnight, and it\u2019s not clear exactly what shape it will be, but it\u2019s clear that more and more business plans depend on machine learning algorithms finding the best solutions.
Each day it seems like there is one fewer reason for you to use a PC. Between the rise of smartphones, living room consoles, and the tablet, the only folks who still seem to cling to PCs are office workers and students who need to turn in an assignment.
This can be a challenge for programmers. It used to be easy to assume that software or website users would have a keyboard and a mouse. Now many users don\u2019t have either. Smartphone users are mashing their fingers into a glass screen that barely has room for all 26 letters. Console users are pushing arrow keys on a remote.
Designing websites is getting trickier because a touch event is slightly different from a click event. Users have different amounts of precision and screens vary greatly in size. It\u2019s not easy to keep it all straight, and it\u2019s only going to get worse in the years ahead.
The passing of the PC isn\u2019t only the slow death of a particular form factor. It\u2019s the dying of a particularly open and welcoming marketplace. The death of the PC will be a closing of possibilities.
When the PCs first shipped, a programmer could compile code, copy it onto disks, pop those disks into ziplock bags, and the world could buy it. There was no middle man, no gatekeeper, no stern central force asking us to say, \u201cMother, may I?\u201d
Consoles are tightly locked down. No one gets into that marketplace without an investment of capital. The app stores are a bit more open, but they\u2019re still walled gardens that limit what we can do. Sure, they are still open to programmers who jump through the right hoops but anyone who makes a false move can be tossed. (Somehow they\u2019re always delaying our apps while the malware slips through. Go figure.)
This distinction is important for open source. It\u2019s not solely about selling floppy disks in baggies. We\u2019re losing the ability to share code because we\u2019re losing the ability to compile and run code. The end of the PC is a big part of the end of openness. For now, most of the people reading this probably have a decent desktop that can compile and run code, but that\u2019s slowly changing.
Fewer people have the opportunity to write code and share it. For all of the talk about the need to teach the next generation to program, there are fewer practical vectors for open code to be distributed.
It\u2019s not cars alone. Some want to make autonomous planes that aren\u2019t encumbered by the need for roads. Others want to create autonomous skateboards for very lightweight travel. If it moves, some hacker has dreams of telling it where to go.
Programmers won\u2019t control what people see on the screen. They\u2019ll control where people go and how they interact with the world. And people are only part of the game. All of our stuff will also move autonomously.
If you want dinner from a famous chef downtown, an autonomous skateboard with a heated chamber may bring it to your house. If you want your lawn mowed, an autonomous lawn mower will replace the neighborhood kid.
And programmers can use all of the cool ideas they had during the first internet revolution. If you thought pop-up ads were bad on the internet, wait until programmers are paid to divert your autonomous roller skates past the kitchen vent of a new restaurant. Hungry yet?
The ink was barely dry on the Bill of Rights when debates over what it means for a search of our papers to be reasonable began. Now, more than 200 years later, we\u2019re still arguing the details.
Changes in technology open up new avenues for the law. A few years ago, the Supreme Court decided that vehicle tracking technology requires a warrant. But that\u2019s only when the police plant the tracker in the car. No one really knows what rules apply when someone subpoenas the tracking data from Waze, Google Maps, or any of the hundreds of other apps that cache our locations.
What about influencing how the machines operate? It\u2019s one thing to download data, but it\u2019s frightfully tempting to change the data, too. Is it fair for the police (or private actors) to forge documents, headers, or bits? Does it matter if the targets are true terrorists or simply people who\u2019ve parked too long in a no-parking spot without feeding the meter?
These are only a few of the big questions for developers in the years ahead. Software architects need to anticipate these issues during design. They need to think of questions around privacy and the law before any code is written. If they don\u2019t, there\u2019s a good chance the company will get blindsided by these issues later — conceivably at massive scale.
Moreover, code itself is a version of law. Programmers define what software can and can\u2019t do. When we write code, we are in effect defining the freedoms and limitations of one little corner of the world.
In theory, we shouldn\u2019t need containers. Your executable should simply run, and the operating system should manage permissions and scheduling so that all the executables get along. Alas, that dream is receding faster than ever. Fewer and fewer executables live alone. Many need differing versions of various libraries or other special accommodations. Even \u201crun anywhere\u201d technologies like Java get into trouble because there are so many different versions of the virtual machine.
Good VMs can fix this, but they\u2019re fat. Containers are skinny and lightweight. They\u2019re easy to use and thus impossible not to love. We will see more and more containers at all levels of the enterprise, and it\u2019s hard to resist their charms.
More about Bill Google IMG MySQL Oracle<\/p>\n