Should we throw away our front-end apps and re-do them?
There are a lot of things that we admire from books and academia, but they just don’t seem to work in the real world. Architectural plans for software and web apps seem to fall into this category quite often.
We can all see the logical connections between the lack of planning and messy code, and between messy code and maintenance/update nightmares. But we can also agree that planning, depending on how it is done, can get in the way of changes. And since adaptation is key for survival, dropping architectural work is usually the chosen solution.
Why would we spend time and energy with something that will not actually happen? When change requests arrive, it feels that we only have two options: a) To accept the change and break the plan; or b) To reject the change and reduce the business relevance of the application. However, there is actually a third option: c) To find better ways to plan and manage applications, not only to accept changes but to welcome them.
In other words, an ideal architecture methodology wouldn’t be like a stiff box, non-malleable, making the life of Managers, UX teams and developers harder. A better imagery would be to see architecture as a wedding planner, who is constantly finding solutions and working hard so the whole event can continuously steer towards success, independent of the surprises and changes that may become necessary. The point is not to perfectly avoid surprises, but to make sure that the event will satisfy the goals and expectations of the stakeholders: bride, groom, mother of the bride, guests, and so on.
You might be thinking: “Is that really possible with front-end architecture?” Maybe you have tried so many “solutions” already, and none of them worked. That is the experience of many, where not even Agile plus the best practices of Software Engineering were able to guarantee anything. That, combined with the fact that front-end technologies change so fast, leads many people to a simple realization: “It is better to just code fast and dirty… and when the time comes, throw all the code away and start from scratch. This will also open a space for the absorption of new technologies that might be available at that time”.
That reasoning makes a lot of sense… but is dangerously faulty!
If you already know the reasons why front-end apps can’t just simply be thrown away, this article will sound too obvious to you. However, I have encountered a lot of people, online and in person, presenting arguments pro throwing away existing applications, or as they like to call it: old applications. They can be quite persuasive.
It is my personal observation that the “throw-away team” is almost always composed of programmers. People with more managerial positions usually know that creating an application goes way beyond coding it. But when confronted with the fact that maintaining a given app has turned too difficult and time-consuming, even they can be convinced to throw it away. In all honesty, managers can also use the same arguments to convince their supervisors, in case they want to create a new system which will carry their name.
As architects, we might have ways of assisting the betterment of a poorly done application, but in general, our shining spot is to prevent that from happening to begin with. The point I am trying to make here is not that apps can’t ever be thrown away, but that through proper architecture we can help them survive (and thrive) for many years. New technologies might be interesting for programmers, but from the users’ perspective, that is irrelevant.
One good argument pro throwing away front-end systems is that, once a technology starts to become old, it might also start to become too difficult to find developers to work with it, especially good ones, who are always trying to keep themselves up-to-date. However, even in that case, we are still talking about a four or five-year span. It is already 2018, and I can still find a great number of developers in the market who are able and willing to work with AngularJS and with React 0.14.x, which have already been around for almost a decade.
So what is this mythical methodology, Fabio? Well, the answer is not simple. Think about a Harvard MBA course. I would suppose that most of us would agree that it can add a lot to our ability to make a company successful. However, it will not give us a formula or a step-by-step guide. What it does is to create in us a mindset, expose scenarios and thought-provoking cases, show several possible things that can be done for different cases, and so on. It is not a well-defined answer that solves the problem, but the build-up of a sharp mentality that leads us to pay attention to certain things, to identify risks, to decide what to focus on, and what we should take in consideration while taking a decision.
So while many people don’t even consider it to be possible for us to find a strategy to govern front-end efforts, I really think there is. My proposal comes from the combination of successful lessons from Software Architecture, Strategic Thinking and Planning, Business Administration, Human Resource Management, and even Psychology, all adapted to the front-end development universe. I have been testing and experiencing it in my own professional life, with great feedback from my managers and their managers. However, you don’t need to take my word for it. Let’s think about it together.
First, let’s remember that advances in methodologies, like in technologies, are not made by people who gave up, but by those who continued to press on into research and experimentation, even when everybody said it would not be possible. Indeed, to stop this investigation based on the assumption that front-end development will never find a robust methodology for its planning and management is illogical since we can’t make categorical conclusions based on the absence of evidence. Whatever broke peoples’ hearts in the past, does not make it so that good methodological processes can’t be found in the future. The real questions are: Can we find it? And when we find it, how can we adapt and apply it to our own reality? And when we apply it, how can we measure its efficacy? That is what the book I wrote is about.
Front-end code does not need to be fated to low quality and to be thrown away every other year. We know that large companies, such as Amazon and eBay, don’t throw away their system every time they need to modify it, whether its a big or a small change. We can’t conceive Google Maps, Pinterest, LucidChart, or any other complex application being re-written every time a new module or change comes in. But how can they continuously deliver changes to their front-end development pipeline when so many other organizations resort to re-creating their apps?
Well, the first distinction we need to make is that many of these systems are supported by permanent teams. Also, most of them already went through full re-writes, with the benefit that both programmers and managers already have a good understanding of the system, its functionalities, the coming changes, etc. Also, since they are so important, those applications almost always set the tone for the other apps and for the other parts of the IT system within the organization, and not the other way around. Finally, the golden goose usually receives more attention, which leads to reasonable levels of system design (architectural plans) by default.
In other words, systems like Gmail, Facebook, and Twitter already have the attention, the authority and the planning necessary to help them reach their expected quality attributes. Also, they usually count with a highly qualified workforce. So even though they can also benefit from a Professional Front-End Architecture methodology, it will certainly become more relevant and evidently beneficial to the numerous other cases, such as: a) secondary applications within the company; b) when teams are not so incredibly highly qualified; and c) when the systems can’t count on dedicated teams working on them continuously.
If you have experience with big organizations outside of the tech business, this can become even more clear. Think about airlines, banks, retail, insurance, and service companies. They tend to have dozens or even hundreds of internal applications. Development teams keep jumping from one project to another as needed. Many times these developers will leave the company before ever touching those projects again. In that way, without proper front-end architecture, the natural tendency is for the next teams touching the “old systems” to find them confusing and request to recreate them.
Developers can be very convincing when it comes to arguing pro new technologies. They have the vocabulary, the arguments, and can even appeal to fear as a tool to convince upper management that a re-write is necessary, Who would argue otherwise?
If there is a crazy cool new technology out there and the investment (in time and money) of maintaining the current app is similar to the one necessary for creating a new app, why wouldn’t the company do that? It would not only add the new requested features but also become more modern and “future proof”. They might even promise that this time they will follow all of the best practices and write all of the necessary documentation. However, as it usually goes, without proper architectural work it starts losing its “neatness” as new requirements arrive or are rediscovered, and in two years, yet another team will ask to re-create the system.
Front-end architecture involves many things beyond requirements’ gathering. But let’s use it as an example. After talking with many people at conferences, reading blog posts, and checking open source projects, I am convinced that it is usually not properly done. However, even when that is done right, developers fail to capture the changes that come later on, especially when deadlines are drawing close or when issues are found during nightly or weekend launches. That makes it so that creating new systems can be dangerous, opening space for the introduction of new and even old bugs.
Besides that, a new project implies new business meetings, new bureaucracy, new approvals, new test suites, etc. Ideally, there would be incremental changes, constant and without too big disruptions of user experience. The fact is that the majority of the users don’t really enjoy big modifications of the user interface. So, frequent and incremental changes are not only good for freeing our time to work on what matters most and will add business value, but also is in line with the natural inclination of our human psyche.
In my book, Professional Front-end Architecture, I mention the so-called “software crises.” It has to do with the fact that until the early 90’s the cost of maintaining a software could be multiple times the value spent on creating it. Things were not moving forward as they should, new releases took forever to come up, and maintenance was very troublesome. A lot of people tried to put their trust in Software Engineering best practices and recommendations. It helped, obviously, but did not solve the problem. The crises were apparently overcome when Software Architecture emerged as a field that would contemplate software development from a higher level of abstraction.
Maybe you once thought that Agile would fix everything, and it didn’t. Maybe you though more engineering best practices would free you from maintenance traps, and it didn’t. Maybe you even thought that a new front-end framework or library would finally make your development clean and easy to support, but it only helped a little. So what can we do? Well, I believe that our web apps are, for all purposes, browser-based software. And like the software crises was greatly averted with proper architectural work, I am sure that through proper front-end architecture we can make front-end development reach its full potential.
We could try to just extend Software Architecture and find a way to use it to make front-end development better. But as anyone can see, it became too big of a field, and it fails to consider the countless unique characteristics of front-end development. As you know probably very well, front-end development is a universe in itself. It is actually very complex, operates over an unstable and ever-changing environment, might be expected to run in numerous platforms and their versions, and all using very simple languages that were not initially designed for what we are doing with it now.
That is why I couldn’t possibly give you all the answers here or anywhere else. Like in an MBA course, front-end architecture is a multidisciplinary science with a vast amount of considerations and perspectives. However, even though it cannot be perfectly systematized, it still is of great importance. I wouldn’t open a business without studying it, no matter how vague business administration books are. In the same way, the very nature of Software (and Front-end) Architecture is in this weird limbo, too technical for managers, and too abstract for programmers. That’s just how it is.
My goal with this article is to bring to your attention that we do not need to throw away our front-end projects every other year. Throwing it away might sound simple, but actually means losing numerous requirements that were not properly documented, creates opportunity for the introduction of new and old bugs, requires new efforts with testing and approvals, and would reduce the time that your team could be spending with new features and other things that could add real business value!
That is why I always hit the same key: Proper front-end architecture can help us break free from maintenance traps and lead us to Continuous Innovation!
Ps.: Here is an interesting complementary read. It presents a personal analysis of a programmer about their work environment and the series of misfortuned steps that led to full applications’ re-write.