- How Many Employees Does It Take to Make and Run a Scalable Social Network?
- Leveraging Technology as It Improves
- This Book Is For...
- This Book Is Not About...
- Structure of the Book
- References
Leveraging Technology as It Improves
Software Development Has Been Improving Constantly…
Technology moves quickly. Moore’s Law, that the number of transistors that can fit on a chip doubles every two years, has an equivalent in the software development world: The best way to build a piece of software from scratch gets a little bit easier every year. Often these small incremental changes are missed.
Everyone sees and recognizes that big tectonic shifts such as the public cloud have changed the game. Organizations that were slow to adapt have fallen behind, whereas others that recognized this shift and adapted have been able to win in the marketplace. But these big shifts are only part of the story. Hundreds of new services launched every year improve software development and provide meaningful benefits to organizations willing to incorporate them into their software.
Tasks that were extremely challenging 10 years ago, such as reliably resizing images, performing a fuzzy text search with tens of gigabytes of data, or handling hundreds of millions of monthly visitors from around the globe in milliseconds, are now often as simple to achieve as plugging a lamp into a wall. This is because technological improvements are not built in isolation; they are built on top of other technological innovations.
Thus, if one innovation per year can double output, then after 10 years, output could be increased by 210 = 1,024 times, not 2 × 10 = 20 times. This rate of innovation far exceeds what any one organization can build, so the benefit of learning how to harness it for an organization far exceeds the value of being the most innovative organization, building the maximum that the organization can build.
…But Isn’t Being Adopted Effectively
If innovation in technology—specifically, in how to build software more efficiently and effectively—is happening and making development so much easier, why are these changes not being widely adopted?
Sadly, there is no continuing education in information technology. Most managers, architects, and senior staff in IT departments also have no set expectations that they should be regularly changing how they do their job, as new technology comes out. It is torture for someone to learn how to do something at the start of their career and then, after several successful years, throw out that knowledge and start again. The benefits of change must be intuitively obvious because so much personal and organizational inertia surrounds the industry. Even then, real change often requires significant changes in culture, mindset, architecture, coding practices, and technology leadership.
Additionally, even if teams identify significant changes they want to make, they still are called upon to deliver new features and functionality within their existing technology stacks. An organization that identifies changes it wants to make in how it builds and runs software must have buy-in and coordination at all levels in order to make significant changes.
The most successful people do two jobs: the job they were hired to do and the job of figuring out how to do that primary job better. This is a required mentality for everyone working on, in, and around the best software development teams. It is especially difficult in software development because of the rapid rate of change. Constantly thinking about how to do a job better, even if it requires learning brand new skills and doing jobs differently, is the only way to take full advantage of technology—and is the right way to approach reading this book.