Struts => Spring; Angular => React. Why hasn’t web developers’ productivity increased much over the last two decades?
Real productivity gain is from a real Continuous Testing (executing automated End-to-End UI tests) process.
I started developing web apps 22 years ago (in 2000), and the first web framework I used was Struts (Java). Since then, I have coded in the following web frameworks as well for different projects:
Webwork
Spring
.NET MVC
Ruby on Rails
In 2010, I switched my career to test automation and Continuous Testing. I was no longer coding for others but have been developing my own apps. I still got involved in many other projects as a test automation engineer or coach. Over the last decades, I observed that the developers have been using different languages (C#, Java, JS, PHP, Ruby) and frameworks (such as Angular.js, Ember.js, Django, and React). However, the development productivities were poor (I will show my stats shortly).
It seems that JavaScript-based web framework is the favourite one now, such as
Angular.js (hugely popular a few years ago, now deprecated)
React
Today, a thought came to my mind: Suppose the productivity of the old Java Struts is 1, what is for Angular or React? Let me be more specific, suppose a software team took 100 days to develop a medium-complex web app in Struts. How long will this team take if they use React.js? For JavaScript programmers who did not know the old Struts, you may compare Angular (or others) against React.
I bet many haven’t thought about this comparison. I am sure you all have heard of the heated debates over programming language/framework among programmers. However, the customers (or the software company) only care about the end product, i.e. product quality, development efficiency and maintainability.
Programmers, please think beyond an individual web framework’s features. Try to think from the perspective of software product development. Suppose you are the CEO of a small software company, and you are bidding for a government contract that has a requirement: “implemented in Java Struts”. The best bid your team can come up with is $1 million. Suddenly, the government removed that restriction, i.e., you can use any established framework in any programming language. What is your new bid now? $500K (twice more productive), or $100,000 (10 times more productive)?
It won’t be an easy question to answer as not many programmers implemented the same system twice in different frameworks (I did). If you are honest with yourself, you will know that the overall productivity gain by switching to a cool (your favourite) web framework is very minor.
While you might still be pondering, I can tell you a story. Trains were invented in the 18th century. In 2013, our family travelled from New York to Buffalo (both cities in NY State) by train (Amtrak), and the trip took over 8 hours. The distance was 471 km. Therefore, the average speed of this Amtrak was 59km/h, similar to the first train I boarded in the 1970s in China. Apparently, it was faster than those trains 200 years ago. But I would say it was not much faster than the train 100 years ago.
The first high-speed rail began operations in Japan in 1964, known as Shinkansen, or “bullet train.” As we know, its speed transformed Japan’s transport (and the whole world as well).
According to Wikipedia, “the first Shinkansen trains, the 0 series, ran at speeds of up to 210 km/h, later increased to 220 km/h.” Compared to the Amtrak train I boarded 50 years later, it was 3x faster.
My point here is: 3X efficiency is already a game-changer. However, there is no clear game-changer (at least not widely witnessed) in the software industry, in terms of coding language/framework. Despite all the advancements in hardware (much faster) and software methodologies/practices, quotes for a relatively simple web app from software companies are usually quite long (6 months+). The improvement in development efficiency from toggling web frameworks/languages proved to be minor, the situation is a bit like changes in trains from 1837 to 1964. We want a revolution like Shinkansen.
In the software industry, at the individual level, there is the term “10X” software developer.
The 10x developer who is 10 times more productive than others has been a concept up for debate in the technology industry for decades. It remains an unproven concept with many claiming to have worked with one, to be one or are seeking to hire one. — “The 10X devleoper truth”
In theory, if the programmers in a team are all 10Xers, then 6-month development time will be reduced to three weeks. (I have seen and done it)
I (and some colleagues I worked with, too) consider myself a 10X developer. It is not a brag, nor marketing myself, as I no longer write code for others since 2010. I have developed TestWise, BuildWise, ClinicWise, SiteWise and WhenWise all in my spare time, and more importantly, able to maintain all of them. The reason for my high development productivity: Test Automation and Continuous Testing.
Take ClinicWise alone, one former colleague (software architect), who worked with this kind of system before, told me this system with the complexity would require a team of 10+ contract programmers alone. He was shocked ClinicWise was just one of my five spare time projects.
How did I achieve it? Because I spend >70% of my time on test automation and continuous testing, hands-on literally. The best programmers I know of all do spend more time on testing than coding. A good example is Kent Beck, Father of Agile, who also created JUnit and started Test-Driven Development.
“It is really important at Facebook I will never, as a developer, write code and toss over the fence and for someone else to write test for it. It is my job as a developer at Facebook to write tests for my code, and my reviewers make sure I do”. — “Continuous Integration at Facebook” presentation
Many junior and mediocre programmers do not understand that test automation is far beyond functional checks, such as
detection of regression errors
(a lot, I only know after mastering CT)prevent defects and technical debts
(run automated tests on local machines first)forming simple and better software design
(Test Automation helps software design, heard of TDD or BDD?)high productivity (navigating app quicker and getting test data)
satisfaction and pride
Check out my article series: Benefits of Continuous Testing. If you are motivated and want to start test automation today, check out the resources links below.
If you are an ambitious CIO/CTO or senior IT executive who wants to achieve something real (before retiring), start introducing automated end-to-end (via UI) regression testing to the organization as LinkedIn CEO did: The Software Revolution Behind LinkedIn’s Gushing Profits.
My answer to web frameworks (or language)? It really does not matter much, as the main work is on testing anyway. If you want my recommendation on one: Ruby on Rails. You might have heard of some negative rumours about Ruby, such as “Ruby is slow” and “Ruby on Rails is not scalable”. These are totally wrong! Many large and famous websites are built with Ruby on Rails, just to name a few: Github, BaseCamp, Airbnb, Hulu, …, etc. I rest my case.
Further reading: