Web applications provide many benefits. Most organizations seek to improve the efficiency and effectiveness of business processes through the use of software.
The benefits of web applications include:
- Simple distribution model for end users (e.g. no installation required)
- Instant propagation of changes
- Unified code base to support many platforms (desktop, tablet, mobile, etc.)
- Easy piloting of new features with a subset of users
- Lower total cost of ownership
- Well-established scalability models as user-base grows
Over the past few years, building the client-side portion of web applications has changed significantly. Web application development, while arguably better than any other platform available today, is not without its challenges. We categorize these issues as coming from three sources: technology, process, and people.
We thought it was a good opportunity to take a step back and look first at the challenges, and then the solutions for building modern web applications, and to share some of the strategies and techniques we use at SitePen to improve our approach.
In this installment, we’ll begin by looking at the challenges currently faced when building web applications.
There are a number of technology challenges with the current web stack that occur when building ambitious applications.
Evolution and change
Developers are now faced with the constant battle of staying current with these changes, and managing an environment where the foundation is moving underneath them. At times, it’s exhilarating, to see so much progress happening so quickly, whereas at other times, it’s frustrating as things you might assume are finished may still change.
The capabilities of web applications used to be fairly simple, but today a web application can be composed of hundreds of different technologies and approaches, and developers of large-scale, full stack applications need to understand far more than ever before. Beyond just understanding the programming language and available APIs, an understanding of network performance, rendering engines, and a wide range of new and emerging technologies and techniques is generally more than any one person can keep in their head at a given time.
Application source code is difficult to test if sections of the application are not easily separable. Code that is easy to test separately is also more likely to be easy to maintain and reuse.
Furthermore, with so many different platforms and devices, the ease of automated testing is increasingly important.
There are many different ways to measure quality of a codebase. These include but are not limited to code standards, performance, consistency, documentation, test coverage, efficiency, and comprehension. The challenge that faces many organizations is agreeing on a set of metrics and then sticking with them, and applying those standards as new engineers join the organization. The value of measuring quality is to gain confidence that what you’ve created will work as expected and be easy to maintain over time.
Tool selection: Marketing vs. quality
With a robust and growing ecosystem, there are lots of solutions to lots of problems. The challenge is determining if a solution can actually deliver. Often, the examples and demos of a technology over-simplify the use case and don’t really answer the critical questions. It’s far more challenging to measure how well an underlying technology will actually do under the constraints of your requirements, and assuming you have spent the time to learn how to use it effectively. Most proof of concepts stop short of this, and favor what a current group of engineers is most comfortable with or what is easiest to use, rather than what might be best for their long term goals and objectives.
Organization and process challenges
Beyond the technology decision-making process, organizations face a number of challenges related to process and methodology.
Many organizations have moved to more modern, engineering-led, development techniques like Agile, TDD/BDD, XP, Kanban, etc. This is in direct response to the waterfall method, which had the challenge of trying to solve every question in advance of development, leaving insufficient time to complete development, or resulting in development of features that did not meet the users’ needs once built. But the biggest challenge we find with agile is that many organizations eliminate most or all upfront thinking. And while agile can work with an environment where key decisions are made late in the development process, it can be difficult to leave enough time to refactor and improve the codebase to ensure it has a solid architecture.
Substantial changes to functionality may necessitate very different approaches to architecture. A typical agile methodology can lead to high levels of technical debt. It can also lead to rewriting the same feature many many times because the requirements and use cases were not sufficiently understood up front. Furthermore, deadlines often lead engineers to take short cuts at inopportune times, costing the organization even more in the long term through fixing more bugs and maintaining poor quality code over time.
In other words, teams often struggle to balance the need to be agile in response to short-term business objectives with the need to develop stable, maintainable and scalable applications that support longer-term requirements.
Simplicity and death by a million paper cuts
Simplicity does not precede complexity, but follows it. Alan Perlis
We are often asked why it is so difficult to build a web application that feels simple. One factor is what we describe as “death by a million paper cuts”. It’s rarely one insurmountable problem that makes web application development challenging. Rather, as our expectations continue to grow with application development, we find that the sheer number of details to track and remember is ever-increasing.
Paradox of choice
With a sometimes dizzying array of choices for everything, no one wants to make the wrong choice and pick a technology that is not right, or is later abandoned. One of the things we’ve learned with Dojo over the past 12+ years is that a flexible architecture makes it possible to delay or change your mind later on key dependencies, without having to throw away an application and its architecture regularly. Designing a truly flexible architecture up front allows you to make a choice now, and change your mind later, with minimal impact on your development.
The team that creates any application will face many technology and process challenges, but there may also be challenges with the team itself.
Quality and continuity
What determines that something is good or bad? Even the best engineers have bad days, and it is near impossible have an entirely effective A-Team. As mentioned during our Caveman Coder talk at FullStack 2015, we believe that an emphasis on reviewing and guaranteeing code quality across a team is the only way to prevent bad engineering practices from entering a code base.
Furthermore, the rate of turnover at some organizations is very high. This prevents long-term consistency around the way software is built at many large enterprises. It can also lead to each new team member second-guessing the technology and architectural decisions made previously. This problem can be even worse when relying on offshore teams, where some countries have a typical employee turnover rate of over 100% per year.
Scaling and collaborating across large teams
It can be a significant challenge to scale code bases across multiple teams. Whether it’s simply shared code libraries, or larger applications, there are many technological and organizational blockers to efficiently building up both institutional knowledge and a shared approach for consistency.
While we’ve started with all of the challenges, it’s not all doom and gloom as there are proven ways to address these issues.
In the next installment, we’ll look at some solutions, so we may move beyond the challenges of technology, process, and people, and focus on the benefits of building web applications.