devopsy.kinsta.cloud

Author: Mike Loukides

  • Rethinking Programmer Education for Today’s Coders

    Rethinking Programmer Education for Today’s Coders

    The proliferation of low-code and no-code applications are changing the landscape for software. In the past decade, growth in these areas has empowered employees to generate solutions at the speed of a digital world, regardless of their technical background.

    This raises several questions: What kind of programmers do businesses really need? Should they still rely on programmers formally trained at four-year universities—what you might call “white-collar” programmers? Or, instead, are blue-collar programmers with self-taught skills or those who learned from a bootcamp more valuable? What will get organizations the right mix of programming skills?

    The short answer is that all programmers can be of great value. In general, blue-collar programmers, after all, connect things within the computing environment, while white-collar programmers create the things that are connected. The essence of low-code is that it allows more people to connect things and use their creativity to become more productive. But it doesn’t eliminate the need for professional programming and tools at its foundation.

    At their core, low-code and no-code are about democratization. They allow people without technical skills to work creatively in ways that essentially make everyone a programmer. A parallel from an earlier computing generation is the Excel spreadsheet, which lets people with no programming background perform computational tasks and eventually work their way up from simple formatting to full-fledged programming. But at some point, polished programming skills are still necessary, no matter how easy no-code or low-code can make some of those elements.

    In the breakneck pace of cloud-based computing environments with new services constantly being developed and deployed to the edge, it’s worth considering the distinctions between the white- and blue-collar programmers and what kinds of education are appropriate for each.

    Four-Year Colleges Vs. Boot Camps

    A career as a programmer can seem intimidating for onlookers. This is particularly true when these jobs involve complex languages such as C++ and Java, which are often used in large projects that can take years to develop and involve millions of lines of code. Some of that is still true, but the evolution of programming over the years toward languages that require less code, such as Python, and to domain-specific languages (DSLs), has also started to lower the barriers to entry for programming.

    It’s true that you’ve never needed a four-year computer science degree to be a programmer. In fact, many that have dropped out of college—or never attended at all—have made significant contributions to the industry. However, universities do provide a foundation in theory and algorithms that have always served programmers well and enable them to branch out into new areas, such as artificial intelligence or other disciplines, such as bioinformatics. Coding bootcamps, for their part, can provide intensive training on DSLs or frameworks like Rails or React.js that can benefit companies’ plans, giving blue-collar programmers the practical skills that white-collar programmers may not have. They also attract career-changing attendees with four-year degrees in other subjects, including the humanities and the sciences, which brings badly needed new ways of thinking into the profession.

    While each method is valid, both four-year institutions and bootcamps also have their shortcomings. Universities delve deep into software development theory but often don’t emphasize critical aspects of doing the job, such as teamwork, testing and agile processes. Nor do they focus much on core areas of businesses today, like cloud computing. Boot camps, by targeting specific areas and emerging technologies and languages, can help people get internships or entry-level jobs, but don’t provide a broader theoretical knowledge of programming. And they can be hit-or-miss, with some of them using sketchy practices for payments and job placement.

    The inherent weaknesses in both white- and blue-collar training can be addressed through apprenticeships and internships, but only to a point. The question remains: Who will train low-code programmers on modern development and coding practices? A lot of companies throw around terms like Agile and CI/CD, but they’re often just new labels on old, inefficient practices. Companies will need white-collar programmers to bring blue-collar programmers up to speed.

    Programming for the Masses

    No-code software is a great enabler, allowing people with no formal education or experience to become proficient in a programming environment. On the other hand, for people who do have formal training—whether a formal education or boot camp experience—low-code simplifies their work, leaving time to focus on more complex projects. But programmer or not, users of no-code and low-code solutions need to understand more than just deployment and testing if they want their software to be reliable and useful.

    Professional developers can make a difference by creating and maintaining the pipelines used to build, test, archive and deploy low-code software; they will need to build new tools to accommodate low-code frameworks. And while familiarizing themselves with current development techniques, they could become the teachers of essential computing practices that don’t involve coding.

    A cooperative, productive relationship between white-collar and blue-collar programmers is essential to moving forward with software development, as it will allow both to continue acquiring new skills and experience outside of low-code, which is only a product of programming, no matter how ubiquitous it may be.

    Making the Connection

    Today, we’re entering a business world where practically everyone will need to code, making low-code and no-code frameworks necessary, especially for users without formal training. However, the importance of professional programmers will remain, too.

    We’re likely to see a proliferation of DSLs created to solve specific problems, which will eventually evolve toward general-purpose programming languages. Programmers will need to build web frameworks, cloud capabilities and more, including everything from web widgets to the high-level tools that let users work. That may be the only way we can begin to meet the demand for more people who can program as more devices come online, more connections are made and the world becomes increasingly reliant on automation.

  • Why It’s Time to Migrate Away From COBOL

    Why It’s Time to Migrate Away From COBOL

    Every few years an alarm goes up about the shortage of COBOL programmers, and then it dies down. While it’s hard to tell whether this cycle occurs because programmers are found or because other solutions are identified, the latest resurgence of interest is at least in part due to the pandemic and state governments’ use of software for social services that couldn’t stand the increased caseload of tens of millions of unemployment claims.

    As we continue to sit in the midst of the pandemic, organizations are thinking about the many ways businesses will have to change. For instance, will cash still be used in five years or will the business need to support some kind of cryptocurrency? It’s time to ask those big questions now—and determine whether it’s possible to make changes without touching COBOL code.

    For most organizations, I believe that in answering these questions they’ll find that it’s time to start migrating away from COBOL.

    The Rise (and Fall) of COBOL

    COBOL is one of the earliest programming languages. It was invented in 1960 and rose to prominence as a language that required minimal programming skills. Part of COBOL’s initial attraction was that it was a domain-specific language designed for business—not only was it easy for programmers to learn, it also could be understood by executives; hence, the acronym for “Common Business-Oriented Language.”

    COBOL was also one of the few programming languages that understood the requirements of business computing—most simply, the fact that an amount like 10 cents can’t be represented accurately in binary was a huge challenge. If you’re a bank, small rounding errors on each transaction add up. Libraries for business arithmetic could be written in other languages, but they’re scarce and hard to find.

    While COBOL never disappeared, its influence faded in the 1980s but many large institutions failed to transition away from it. Today, there are billions of lines of code in governments, banks, enterprises and elsewhere performing essential business functions with few programmers able to maintain them.

    Part of the reason why COBOL fell out of fashion was its inability to adopt things such as modularity or breaking down problems into smaller, functional pieces. When COBOL was invented, old business software was monolithic—and monolithic in a very deep sense. Internally, the software wasn’t partitioned into separate components that could be updated without affecting each other. It also tended to model forms that humans would fill out and couldn’t be submitted until the form was complete. Putting a web interface in front of those monoliths leads to a predictable result: long, complex forms that can take hours to fill out and are close to unusable on the modern web.

    While the COBOL language itself has evolved over the years (with revisions released in 1961, 1974 and 1985 and object-oriented COBOL released in 2002), you still have to ask: what will it take to bring a COBOL program written in the 1970s or 1980s up to date? Is redesigning a program to take advantage of COBOL 2014 any easier than porting it to Java or Python or Go or Rust? Furthermore, COBOL looks unfamiliar and forbidding to most modern programmers, which likely caused it to lose popularity in the first place.

    Finding an Alternative

    So, where are we now, with our billions of lines of COBOL running the world’s governments and finances? We certainly need more people who know and understand COBOL programs. There’s a lot of old code that needs to be maintained, pure and simple.

    But it goes deeper than that. COBOL is just another programming language; if we’re going to maintain (or replace) that software, we need programmers who understand the engineering decisions that made the software what it is. Programmers used a lot of tricks to work around the limitations of 1960s computers. Those tricks just don’t make sense to modern programmers; they solve problems we no longer have. We also need engineers and managers who are willing to look at our current situation—for example, the huge surge in unemployment applications—and think beyond the short-term solution. What does it take to reinvent current systems rather than replacing them? How can these systems become more human-centric? Can they be redesigned to match the way we live and work now? Putting a web front-end on a monolithic business process from the 1950s is the road to failure.

    The new generation of programmers must understand financial programming and how to design business systems. There’s little value in migrating from COBOL if you don’t get something better in return. What you should get in return is the flexibility to add new features and new user interfaces, the ability to adapt to changes in competitive conditions and implement changes in the regulatory environment, and so on. We don’t yet know what those new features will be (perhaps cryptocurrency or virtual reality user interfaces), but we do know that businesses will need the flexibility to add them.

    Simply put: Scrambling for COBOL programmers whenever there’s a crisis is not a viable business decision. Transitioning from COBOL is a change businesses will have to make eventually. This transition should be made when businesses have time to think it through, time to hire the right people and time to do a good job—rather than waiting for the next crisis.

    In the meantime, while businesses are baking in the time to think through their transition strategically, it’s important to note that this isn’t an all or nothing decision—i.e. let’s scrap our legacy software and replace it by Jan. 1, 2021. This is not Y2K. Using a microservices approach offers numerous advantage. For one, businesses can split their existing infrastructure into different independent services. They can start with pieces such as authentication, then move on to things such as billing and other services. Whatever businesses decide, they need an approach that’s modular so that it’s easy to add new features as needed. That requires careful thinking about design—and that thinking is more important than the programming language itself.