devopsy.kinsta.cloud

Tag: development languages

  • Watch Your Language(s)

    Watch Your Language(s)

    Just about every organization I am familiar with today is using more languages, frameworks, libraries, etc. than they were a decade ago. Back then, most organizations were doing a lot of Java, and maybe a little bit of PHP or .NET (almost always VB.NET). Now we have Java, Python, Ruby, Go, Swift, etc. And etc., etc.

    The problem is that employees don’t come pre-instructed with your selection of languages. Most developers can bring Java or Python and most know at least one other language well. All of them can learn (more on that in a moment), but when hiring, an organization needs to focus on the one or two languages the hiring team is using, not all the languages an organization might ask a developer to learn over the course of their employment. After all, when hiring 20 years ago, the tools of the mainframe team weren’t generally listed as requirements for a desktop developer. While there is a difference (desktop developers were only asked to work on mainframes when the shortage of experienced big iron devs got really bad), it is a similar situation today.

    You can hire with an eye to training, and most developers will be more than willing to pick up a new language and learn its ins and outs. But ask any manager that pays close attention, and they’ll let you know that there is a huge difference between time-to-productive and time-to-proficient. One manager told me that any programmer with experience could start contributing relatively quickly in Ruby, but to do the important stuff—things like knowing which array access methods were faster and the most efficient communication between Ruby and other languages—took far longer. His numbers seemed too high, in my opinion and based on my experience, so I asked around. All the managers I know that worked with Ruby (because to a great extent, this is language-dependent, so I didn’t want to make hasty generalizations though, in hindsight, the same data point in Python would have given me more responses) agreed there is a curve, and the range was somewhere between six months to two years. This is strictly anecdotal, but it seems the more technical the team in question, the longer the manager thought proficiency would take.

    But even if the lower number is accurate and applies more generally, it is an argument for keeping your language count down. Yes, some languages are better at X or Y or Z than others, but most modern languages can do just about everything an average enterprise team will ask of them. So, keeping languages within a smaller pre-defined set still allows teams to choose the best tool for the job while keeping the number of skills developers at the organization might need down to a manageable level.

    And keep wowing them. No matter what languages you are using, your user base is logging in and using the results daily—or perhaps your devices are reporting the results daily or processing them. No matter how you are delivering, you are, as our digital world shows. Keep rocking it, and do what you can to keep the number of languages under your roof down.

  • Best of 2021 – Programming Languages: Choose Wisely?

    Best of 2021 – Programming Languages: Choose Wisely?

    As we close out 2021, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the first in our series of the Best of 2021.

    We’ve got decades of experience in programming and language adoption under our belt at this point, and there are a few things we can say definitively that developers in general (and DevOps engineers specifically) should be aware of.

    First, it doesn’t matter as much as you think. It really doesn’t. Most developers don’t choose programming languages based on important things like optimization or general applicability. They choose a language based on ease of use, availability of third-party libraries and simplification of things like UI. Open source version availability helps, but only insofar as it spawns more third-party libraries. So, use the language that works best for the project, and don’t get too hung up on whether or not it’s the newest shiny one.

    Second, the changes in use and adoption that matter–the top five to 10 languages that make up the vast majority of all professional programming activity–don’t happen overnight. Both JavaScript and Python are considered “rapid ascent” in terms of uptake when they took off … but both were around for years before that spike in adoption occurred. So, learning any of the top few languages is a far better long-term investment than learning the hottest new language.

    Third, those top languages actually don’t change much. They were written to fulfill a need, and that doesn’t change much over time. Indeed, the only language I can think of that has fundamentally changed in its lifetime is C++, which seems to want to keep up with the times rather than keep serving its original niche. Python? Java? Still pretty much the same as when they became popular back in the day. And that’s a good thing. But that means if you want to try something new and engaging, you need to look to up-and-coming languages. At the time of this writing, specialist languages like R and Kafka are having their day, and that’s a good thing. After all, we know that different applications have different needs and different platforms have different needs–and have been trying to address that second one forever, currently with languages like Flutter. All of these will offer new ways of doing things, which is good exposure.

    Fourth, (though we briefly toyed with eliminating this one) organizations do determine the pool of available languages. Frankly, allowing each team to build a separate architecture was never a good idea from a long-term maintenance point of view … but a fairly large number of organizations played with the idea and learned the lessons about technical debt all over again. Now we’re back to “We use these languages, pick one,” which is better than “We’re an X shop,” and offers maintainability over time without burning a ton of man-hours.

    And finally, you can do anything with those languages your organization makes available. I’ve seen object-oriented assembler, I’ve seen entire websites served in C; the list goes on. The language you choose makes certain things easier or harder, but if you need to get it done, you’ll either get an exception to the language list, or you’ll figure out how to get it done with what’s available. But you can … But as my father used to love to say, “Just because you can, doesn’t mean you should.” He had nothing to do with programming and as little as possible to do with computers, but his logic still applies perfectly.

    So, grab an approved language, and crank out solutions. Just keep driving it home; you’re rocking it. Don’t stop, and don’t worry too much about which language you’re using, just focus on the language and do what needs doing–like you’ve done all along.  And spin us up even more cool apps.

     

  • So Many Options, So Little Time

    So Many Options, So Little Time

    So many language/framework options, so little testing time, that is.

    Recently, two projects I was working on drove me to check out a breadth of languages and/or frameworks to handle cross-platform development. While Unity and Unreal have traditionally been my game platforms of choice and I typically use Xamarin for cross-platform (though native development is more common for us on both Apple and Android), I decided I needed to do the occasional sweep to find out what is new out there.

    The two projects are a game on which I’m helping a new game developer learn and a graphics-heavy application that is unsuited to web development. Both would work best in a cross-platform environment; both would benefit from a game engine’s graphics manipulations. But both could be done in any language that supports graphics, as there isn’t a heavy physics requirement to the game.

    So I went looking at what’s available now and how it fits. From React Native to Godot to Flutter and even Kivy, I kicked the tires on each, got them running, ran and traced samples, wrote some code of my own, even talked with friends that were using them to get their opinion.

    Alternate frameworks languages

    The one thing that came through loud and clear? There is no way that security and testing are keeping up with this language/framework proliferation. Kivy has a language (more of a specification than an actual language, but still—source code) that can run on top of Python (it’s not required to use the framework, but it’s kind of assumed you will if the app gets beyond a certain size); Godot has a language that is integral to the framework and that you use pretty much everywhere. React has a ton of add-on code and both Flutter and Dart are new languages.

    I like stuff from each of them. I don’t like that we’re going to use them in ever-increasing amounts and we’re going to expect testing to stay on top of those implementations. Each of these platforms/languages/environments has a large following that is doing some of the testing, but since they’re all relatively new, “How much testing?” is a valid question. And tests have to be done in those languages, implying that those writing need to know them and so do testing teams.

    Where did we end up? We haven’t made a final decision yet, but taking input from the person I’m mentoring, coworkers and those who are using each of the above, we’ll probably end up using Godot. For 2D apps, it is the bomb. Our team is small, so I can offer my knowledge of Godot to shore up testing and everyone agrees that its Python-like language is acceptable, while the graphic design element is nicer than the competition. Both applications will benefit from Godot’s graphics processing capabilities and the game will benefit from game elements built into the Godot Engine.

    Here is an interesting side note: All of the products we looked at are open source. Both of the default products that we (and just about everyone else) would choose for the game are commercial. That’s interesting, but we don’t need the weight of those commercial solutions for a simple 2D interactive game/app.

    For you all, the questions might be harder to answer. With larger projects come larger requirements for source size, test, you name it. Choose carefully, with an eye on the future. Personally, I think React Native, Godot and Flutter would all be good choices for cross-platform applications, with Godot the best solution for cross-platform 2D games. And all three are likely to be around with a good size following for a long time, making them safer choices. That is less clear with Kivy, though the popularity of Python appears to be driving growth in Kivy use.

    Whatever you choose, plan for all phases of development, not just writing code. That’s true of everything, but new cross-platform tools are complex beasts, so it is worth reminding you all.

    And hey, if you have a cool app you developed with one of these tools, point me to it. Always good to see what you all are doing, and nice to see the breadth of solutions these languages can create.

  • Enterprises Face Growing Technical Debt

    Enterprises Face Growing Technical Debt

    Technologists are always espousing new, trendy development solutions. More robust frameworks, increased delivery, better integration. But rarely do these proponents consider the long-term side effects of introducing new technologies. As a result, technical debt is an all-to-common occurrence in most companies.

    Nearly a third of IT budgets are dedicated to addressing technical debt. Devoting so much effort to maintaining legacy code leaves fewer resources to support the status quo, let alone develop new solutions. In fact, a recent study found that 69% of IT leaders identify technical debt as a significant threat to their companies’ ability to innovate.

    “The Growing Threat of Technical Debt,” a report from OutSystems, surveyed 500 IT leaders about this conundrum. Below, we’ll explore the top causes of technical debt and consider ways to prevent it from getting out of control.

    What is Technical Debt?

    Technical debt seems counterintuitive. Isn’t technology supposed to help organizations become more productive? Why would it be a burden? Well, technical debt often arises from hasty decisions taken in the short term that have long-term consequences. It’s also often the result of a company juggling many competing technologies, some of which have become outdated.

    Technical debt can carry a hefty price tag. But this debt isn’t so much measured in the cost of hosting legacy technology or running broken code, but in the hours lost maintaining and patching it. The report found that, on average, businesses devote 28% of their IT budgets to addressing technical debt. This number increases to 40% within large enterprises.

    Common Causes

    There is not one single factor causing technical debt. Many issues within an organization contribute to the problem, including reliance on stale technology, pressure to deliver in the short term, constant change, developer churn and incorrect architectural decisions.

    The top cause of technical debt is too many development languages and frameworks, cited by 52% of respondents as a big or critical problem. Legacy technology can weigh an IT department down. But, it’s not necessarily only old tech getting in the way—it could be that IT is supporting too many competing agendas.

    The second top cause is a high turnover rate within developer teams. In today’s competitive climate, quality engineers are in short supply, and hiring can be challenging. It is thus difficult to attract and nourish steady engineering talent. If developers frequently leave for greener pastures, especially before documenting their procedures, best practices can easily be lost and efficient use of technology is stunted.

    The study found that other common causes include accepting known defects to meet deadlines, using outdated programming languages and frameworks and dealing with challenges in serving new markets or segments. At times, teams release software with known defects simply to meet deadlines. The sheer size of a large organization can lead to increased technical debt, and not addressing it compounds the issue further.

    In terms of industries, the report found the health care and social assistance category hit hardest. In this sector, 35% of IT budgets go toward addressing technical debt, on average. The next most-burdened group is the financial category, which was at 29% according to the report.

    The Costs of Technical Debt

    What are the costs of technical debt? There’s a high price to maintain, reduced hours for innovation and a detrimental effect on overall software performance. Team dynamics could also incur adverse reactions from sustaining technical debt.

    Technical debt requires an disproportionately high amount of time to maintain. On average, engineers spend 33% of their time dealing with technical debt, found Stripe’s “The Developer Coefficient” study. This equates to about 13.5 hours of an average work week.

    The more debt you take on, the smaller the budget left for running status quo operations and building new capabilities. Supporting technical debt not only has financial implications but could stifle future prospects; in fact, 69% of respondents said technical debt limits their capacity to innovate. In today’s acceleration economy, not setting aside resources for digital innovation, could break a business.

    “The combination of old code along with the new generation of mobile apps, stack applications and SaaS sprawl are robbing organizations of resources, time and the ability to innovate,” said Paulo Rosado, CEO, and Founder of OutSystems.

    Technical debt could also stunt performance. According to the survey, 61% of respondents said it causes a significant drag on their company’s performance. Stale projects could interfere with streamlining customer experiences and digital transformation goals.

    Lastly, technical debt could also negatively affect morale. Few engineers take pride in repeating inefficient processes or working with obsolete tech.

    Alleviating Technical Debt: Be Intentional

    Similar to financial debt, technical debt comes with compounding interest. This interest could grow exponentially if left unchecked. So, what steps can organizations take to reduce their technical debt?

    To help alleviate the problem, the report recommends reversing the top two causes of technical debt by stemming turnover in development teams and limiting the number of new programming languages and frameworks you adopt.

    Other methods involve taking stock of your holdings to understand the presence and impact of legacy technologies. Next, rethink and redirect your strategy from simply maintaining legacy dependencies to addressing them and replacing them with modern styles.

    “A lot of bad tech debt comes from building too much and getting stuck spending more time on maintenance and bug fixes than expected,” said Jon Thornton on the Squarespace blog. ”The key is to be intentional about what you invest time in and aware of the costs you’re taking on.”

    Of course, enterprise IT must take on some form of technical debt to function—it’s futile to get rid of it entirely. Therefore, as Thornton advises, be intentional about it and stay aware of the costs you take on. When adopting new technologies, it’s best to consider maintenance implications and plan with longevity in mind.

    For more insights, download “The Growing Threat of Technical Debt” report in full here.

  • Languages and DevOps: Recommendations

    Languages and DevOps: Recommendations

    In light of the points brought up in these articles, what is my advice for which language to use on a given project? The same advice I have always given development teams: Use the right tool for the job. My father was a woodworker, and drilled that concept into me. I brought it to development, and it is true. The difference is that “the right tool for the job” is a much more complex question in an existing IT environment than it is in woodworking. Whether you need a chisel or a screwdriver is immediately obvious. Whether Python or Go is the right tool … not so much. Things to consider:

    Does the tool have a broad developer base?

    This is the most straightforward question on this list. Can you get people to work in the language? I worked at a place that still had RPG III code running on a mainframe. We used to joke that those two retired developers in Australia were getting rich from maintaining it – and we still did some new development in the language. It was a bad choice that we moved away from. Maintaining the old while developing a new platform made sense. Packing any new functionality into a tool about which few knew the ins-and-outs, and even fewer were being trained for? Made no sense.

    Does the tool specialize in, or have modules/add-ons that customize it for your target?

    While at the 50,000-foot level, you can theoretically do any computing job in any language, that doesn’t make your preferred language a wise choice. Making certain the tool supports what you need to do is paramount. This is the closest to “right tool” thinking – does it do the job?

    Is the developer base growing or shrinking?

    While this is more important for longer-lived projects, you do want that developer base mentioned in the first point, above, to still be around. This extends to add-ons, also. If you choose ASP.NET today, will it be a solid choice tomorrow? (I’m not saying it won’t, here, just picked one framework to illustrate the point with).

    Does the tool do what you want, or will you be working around faults to get there?

    Honestly, you can – and people have done it – write websites in C. That doesn’t make it the right choice. You’ll end up spending more time getting around the fact that C is ill-suited to this task than you will developing the actual site. Assess the language with regard to how well it actually does the job you need to do. This is a different take than the second point, above – this is the “just because you can, doesn’t mean you should” part.

    Does the tool fit in your environment?

    This is the one that far too many struggle with. New development teams want to bring the tool they’re most comfortable with, because it reduces development cycles in the short term. The issue here is simple. It is far easier to manage an environment that makes a conscious effort to keep our burgeoning number of tools, languages and libraries as controlled as possible. Introducing Go to develop servers, just because someone is excited about it, makes no sense if the entire environment is Node on the server side. Use the environment you have so you can maintain things more easily. Everything is more thoroughly vetted – from which add-ons to include through security – with the language an organization uses the most; take advantage of that. Start with, “We use Java in 70% of applications,” and then deviate from there only if you are moving toward a goal of moving off of Java (again, not saying you should, just an example).

    As a New DevOps Person, Which Should I Learn?

    Not so long ago, the ubiquitous advice to new developers was, “Learn Java!” It was everywhere, doing everything, even when it wasn’t the best tool for the job.

    Similarly, that answer is now “Learn Python!” Of all the languages out there, it is the one used the most. I do not have data to back the following statement up, but I will bet most Dev people have used Python on one or more projects already, and a fair number of Ops people have, too. If Java is the past, Python is the future.

    That said, check out companies where you would really enjoy working and see what they’re doing. Generally speaking, they’re not looking to hire Python developers if they are doing 70% of their coding in Go. I can’t recommend tailoring your learning to one or two organizations’ environment(s) (unless you already work at one of them), but consider the popular languages that have been listed in this series and learn the ones your target organizations use first.

    All of these languages have free/cheap options for learning them. No one is stopping you from learning Go; indeed, there are websites whose purpose is to help you learn by doing. The same type of learning is available for most languages, with implementation details varying a bit. There are a wealth of great books available for all of them, also, if that is your preferred method of learning a new language.

    In the end, learning a new language will never be a negative. It will help you be aware of the list above, and provide meaningful input in the inevitable “Is this the right tool?” conversations.

    So, start with Python and then work through others. With one side note: if you lean toward the Ops side, know what different Ops tools require, and consider learning some of those, also. There is one prominent Ops platform that still uses TCL, for example, and we all know about CICS. So be aware of what might be needed, and at least be familiar with that.

    And Keep Rocking It

    Modern IT environments are unbelievably complex. From rights management to storage, to data gravity, to a wide array of languages and appliances – you and your teammates are keeping it all humming. Keep doing it. Learn new languages before they become necessary to your job, but never think you’re falling behind. If the company is still clipping along, you are the right person for the job.

  • Languages and DevOps: Embedded

    Languages and DevOps: Embedded

    Every once in a while, it is a good idea to take stock of the environment and the market around us to determine if what we are doing is what we should be doing. I’m a developer, not a prognosticator, so these observations are simply based on my experience in the development world, along with a frank assessment of what’s changing, to try and offer some advice to my fellow developers. This week I’ll talk about embedded, but we’ll hit a bunch of application targets over the coming weeks.

    Embedded development is, generally speaking, more low-level than most other modern programming practices. Considering the goal of embedded is to interface with the hardware, this is no surprise.

    C/C++

    And that brings us to the king(s) of the embedded hill. C, and to a lesser extent, C++ rule this roost. You will see a lot of talk about Python, and we’ll get to that in a minute, but for historical and performance reasons, C is still your best bet. If your DevOps tools support your Make variant – Ant, Maven, or whatever – it can be plugged directly into the DevOps process. Testing will still take extra steps. Since deployment is most often handled directly, that does not generally need extra steps, but, in some cases, it might. A lot of general guides claim C/C++ is “easy” to learn. I disagree with this assessment; newer languages tend to be more intuitive while retaining some of C’s better features, but it is, at this time, necessary to embedded development.

    There’s a Reason (or Many) for That …

    There are a lot of conflicting factors going into where embedded is headed in the future, so we’ll try to address them here.

    Historically speaking, C/C++ have had better performance and smaller footprints than interpreted (even bytecode) languages. They are easier to code in than Assembly and supported by a ton of libraries to get work done; they struck the right balance for embedded. The weight of these developers and the legacy source code they created are part of the reason C/C++ are still on top.

    But three things have caused a shift that will open up room for other languages to make headway into this space. Embedded devices are getting faster, and storage is getting both smaller and cheaper. That means that a less-efficient means is more viable. Arduino and other hobbyist embedded platforms have also come of age. It is now viable to pick up an embedded board and start prototyping over the weekend. These embedded environments are well-supported by newer languages, and, historically speaking, today’s hobby builders are tomorrow’s startups. This is pulling other languages into the mix far more frequently, particularly our next entry.

    Python

    Python is popular in almost every category of programming. It has been around long enough to lose the mantle of “language du jour,” and should be considered based on its strengths and weaknesses. Given that the newer wave of prototype systems is well-supported by Python, it is easy to maintain, and has a broad selection of libraries (often, ironically, written in C), it has gained clout in the embedded space. It doesn’t perform as well as C/C++, but modern embedded devices are of a class that this may not be as important (early embedded devices were high-performance tools, while IoT often has devices that don’t require anything like near-real-time), and hardware improvements make this less of a concern. Python’s popularity makes it relatively easy to work in to your DevOps toolchain, with targeting of embedded devices making deploy and test require extra steps … but that’s true for all of these languages, as it is a targeting feature, not a language issue.

    Assembler/Assembly

    In the end, we need machine code. Even bytecode (or p-code, if you prefer) interpreted languages execute their instructions in hardware, eventually. Because performance and space have long been issues in embedded development, assembly language has been a preferred tool for pieces of the development pie. While few developers use assembly language for everything, most embedded developers use it, at some point, to modify libraries or create targeted subroutines. Certainly not a “popular” language among developers, most of us buckle down and just do what we need to. Like C, assembly is normally built using a Make variant. These are easily integrated into DevOps toolchains to get reporting and results up to those dashboards that run a company’s agile efforts.

    Others

    There are a wealth of other languages in use on embedded platforms, most notably C#, but also newer languages like Rust. The environment is changing, and as the ramifications of terabyte SD cards and multi-core embedded boards start to sink in, they are worth watching. We are not that far off from having a desktop-quality computer in a board only a little larger than a credit card. That changes a lot of things. More room for data storage and processing, and the need for tools that are easier to use in these contexts.

    Libraries

    All languages use libraries to make development easier. We are past the days when coders wrote all of the functionality of their project. The tools that bring libraries into a project need to be incorporated into the DevOps toolchain. For C/C++, the mechanism is largely manual, and can be automated with scripts or with the build tool. For newer languages, tools like NPM will need to be hooked into the toolchain. The ease of library dependency management is one of the appealing aspects of newer languages, and making it easier for a developer to hook in libraries also makes it easier for DevOps tools to make use of library management functionality.

    You. Rock.

    Whatever your language of choice, in the end it will likely be your build tool that links it to DevOps. Maybe we should do a series on those, too; comparing when to use Gradle versus Ant, for example. Until then, keep rocking it. All development depends upon embedded in the end, so you’re holding up the foundation.

  • Camunda Extends Reach of BPM Platform

    Camunda Extends Reach of BPM Platform

    Camunda, a provider of a business process management (BPM) platform written in Java, this week added support for an open application programming interface (API) to make it easier to integrate its namesake software with applications written in Javascript/Node.js, Python and C#.

    Company CTO Daniel Mayer said at a time when many organizations are investing in digital business transformation initiatives, the latest updates to the Camunda BPM platform adds support for an OpenAPI standard advanced by The Linux Foundation to enable IT organizations to integrate business processes spanning modules created using different programming languages. In the case of Camunda, IT organizations will be able to generate a REST API client using their preferred coding language that can be integrated with the core Camunda BPM platform, he said.

    In addition, Camunda announced that version 7.13 of the Camunda BPM platform will be available in the form of a lightweight distribution, dubbed Camunda BPM Run, that can be deployed as a Docker container to create a standalone engine with no Java or application server knowledge required.

    Camunda has also added support for Camunda’s Optimize 3.0 to provide a unified view of real-time process insights from any data source and the ability to visually track changes across different versions of process models using its Cawemo tool.

    Finally, Camunda has added support for version 1.3 of the Decision Model and Notation (DMN) specification as well as version 1.2 of the Friendly Enough Expression Language (FEEL) defined by The Object Management Group.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, many organizations are looking to reduce costs by streamlining business processes. The decision many of them need to make is determining to what degree they want to rely on packaged applications to achieve that goal versus a platform that enables them to create custom business processes. While many rote processes can be automated using packaged applications, Mayer said the Camunda platform makes it possible to create business processes that truly differentiate organizations from rivals. Packaged applications, in contrast, drive organizations to employ the same business processes in the same way.

    Of course, organizations can customize packaged applications. However, at that point, most of them will have embarked on an application development project that would be easier to complete using a platform designed for that purpose, he noted.

    Naturally, there are other platforms for integrating business processes that revolve around graphical user interfaces. Camunda has been making the case for an open source Java-based platform that enables developers to create and deploy custom business processes using best DevOps practices at a much lower total cost. The company also commercially makes available an enterprise edition of its platform. In total, Camunda claims there are now than 100,000 developers participating in the Camunda community.

    It’s too early to determine to what degree organizations will rely on packaged applications versus BPM platforms to drive digital business transformation initiatives. However, given the current economic climate, it’s apparent these projects have never been more urgent.