Web Development and Design Tools: Does Your Enterprise Need the Latest and Greatest?
Are you in the cloud? Do your dev team rock containers and microservices? Or does your team - like many other IT teams - rely on technologies from the 1990s to deliver the company website and internal systems? Are you feeling the pressure to update?
Innovations in technology and process typically arise to overcome challenges and limitations in the existing technology stack. Adoption of new tools and languages can be a significant investment, particularly for shops with many lines of code in service and senior development staff with expertise in a given toolset.
So when is the right time to push your team to retool? Let’s review a few key benefits of some of these newer trends in the Web Development space and consider the questions we might ask when trying to make that decision.
Let’s start with containers! Containers have been around for at least six years, but have only recently hit their stride with mainstream development shops. Containers provide a layer of abstraction between the host system and the runtime environment. The key benefit of containers comes in a dev ops environment, where developers may or may not have access to the underlying server setup, but have a need to deploy a reliable server configuration. Have you ever tried to run a stable application on a Linux system when the developers did not have access to root privileges, and the system continually reset the file permissions on the web volume to a system account? Torture! A container provides a stable, pre-tested environment for code that abstracts the base system access requirement from the developer. This leads us to our first question:
Do you still have bugs in your software releases?
Bugs after release have always been the most expensive time to find exceptions, and always will be. If your team braces for a new set of bug reports with each release, adopting dev ops practices may be an opportunity to improve your developer culture and, consequently, your bug count.
What is culture, but a set of repeated behaviors? Dev ops practices include quality-focused features like automating as many processes as possible, including testing. Only by bringing the attention of your development team to process, and using that transition to adopt an “accident-free workplace” mentality can justify retooling. If your organization has already taken dev ops and is not seeing a reduction in reported bugs, they only aren’t doing it right.
As an additional benefit to dev ops, many copies of the containerized environment can be deployed quickly, providing the ability to scale to an extensive system with relative ease.
Were you around for that first tragedy at scale when myspace. com went up into the millions of users, and the site slowed to a crawl? That kind of level was unprecedented and was extremely difficult to accomplish with the original toolset - Adobe ColdFusion using a Fusebox framework. This was a clear cut case of needing the latest and greatest! This brings us to our second question:
Do you have or expect a massive scale?
Without adopting containers or learning Go or NodeJS, your site can handle a lot of visitors. The original application server of choice for myspace.com, ColdFusion, or its rapidly growing open-source flavor, Lucee, is compiled Java code. Php, the language that arguably dominated growth of quickly developed web applications due to its low cost and eases to implement, is compiled C. For applications serving 10,000 or so users, you won’t get much faster using newer languages, and you won’t find something more straightforward to deploy without adopting all the consequent dev ops processes. (Not to mention, have you tried to hire a Go programmer , lately?)
A little .02 from a long-time developer here if you have a web application that has a not-massive size user base but is running slowly, you probably don’t need a new set of tools, and maybe not even a rewrite. You need a performance tune. There are companies out there that do this, and it will cost your organization less than developer training in a new system plus time to learn a whole new way of doing things.
This brings us to our third question:
Would your developers have a hard time getting hired somewhere else?
As a leader of software developers for more than a decade, let me put this out there, this question has at least two interpretations. The first interpretation might be: is the organization providing value to the developers outside of the paycheck. While I believe this is important in an excellent place to work, that isn’t how the question is intended.
A second interpretation is: is your organization relying on something that carries unnecessary risk. There are good reasons to move away from some platforms - problems may be inherent to those systems, or may have developed around the culture of that platform. Both kinds of reasons are worth avoiding.
If your developer has a hard time getting hired, your organization may also have a hard time replacing them because they are an anachronism. For example, you can create a swift website using Perl. Perl fell out of favor, at least in part, because it is possible to create the same product in so many different ways using the same language that this became part of the culture of the word. A developer hierarchy of complexity formed, which produced inconsistent performance, translating into buggy applications. Read: expensive. Your Php developer could get a job tomorrow - whatever the faults with that language, it is widely used and performs well. It isn’t going away any time soon. This is a good barometer of risk for your technology selection.
If you answered yes to any of the three questions above, your team should be exploring new platforms and languages. Consider attending one of the many great conferences on the subject, such as one of the Qconn events or something local to your area. If you answered no to all three questions, evaluate the investment in new tools against your strategy and vision. Adopting new tools can be a daunting and expensive investment, but justifiable in many cases.