Developer Productivity and Web Development

Programmer productivity or developer productivity is a concern for everyone in web development projects regardless if you believe it or not. You have to take productivity into consideration in the modern software engineering world. Significant productivity gains were made in the 1980s (i.e. Turbo Pascal, SmallTalk) and in the 1990s (i.e. Delphi, Visual Basic) that permitted developers to produce decent applications faster without compromising quality too much. In most cases, there is a trade off between speed and quality. The faster you develop the lower your code quality becomes. This can mitigated by employing refactoring techniques as part of your development process. The speed and quality of development was greatly reduced when the internet and web development turned the world upside down in the late 1990s.

I remember when web development meant getting things done as quickly as you could with the trade off in design, reuse, and quality. Basically quality suffered. I have seen enough disasterous code in ASP, VBScript, JavaScript, PHP, JSPs, and all the flavors of web development where reuse, separation of concerns, encapsulation and good design were not even considered as long as the code worked. Well this has gotten a lot of products and projects in trouble. A lot of this code is now considered legacy code and it quite a mess from a quality perspective.

In the past few years, there is a movement to get back to quality without sacrificing speed of web development. You can see this with the newer Java frameworks (i.e. Spring) and dynamic object-oriented scripting languages (i.e. Ruby on Rails, PHP Framework). I think the complexity and depth of web services implementations has necessitated this resurgence.

The Java web stack in my opinion can be productive as long as you properly choose the right frameworks and tools. As a Java developer and comparing my experiences in other languages, Java requires that you make framework good decisions all the time. You have to become skilled at adaptable design and framework integration to be a good Java developer. This requires quite a bit of research time and places a high premium on the skills of the developer. You have to be a Java practitioner and technologist to become "productive" in Java. It is attainable but requires a higher level developer to realize this goal. Java solutions tend to be verbose coding and XML configuration intensive so many of the frameworks and tools address the automation of the coding and configuration process.

Comparing Java developer productivity to a developer using Borland Delphi is like comparing apples to oranges. In Delphi, an average to mediocre developer can become productive in a relatively short period of time due to the Delphi RAD component-based development paradigm, "The Delphi Way". The downside to the Delphi paradigm is that upfront skills required to become productive are not as high thus limiting the skills growth of the developer over the long run. In other words, this style of developer never really needs to assimilate object-orientation or other higher level design and refactoring skills if this is not deemed important by the developer. This can create a developer skills plateau which is can dangerous to your software engineering team in the long run.

A similar scenario has occured with web development where loose scripting solutions (i.e. ASP, PHP) are as pervasive as good sold robust designs (i.e. Java). Well now that web development is at a point where both the clean/robust approach (Java) and quick (PHP,ASP) have been explored, a clean/robust and quick methodology is ready for prime time. This is where I believe Ruby on Rails has the advantage. I know it has been getting a lot of hype lately, however, from what I have seen I think it represents the future of web development.

At RootPrompt.org, I found yet another excellent review of migrating from Java to Ruby that is well written. "Evaluation: Migrating from Java to Ruby on Rails". The actual evaluation describes from a web development perspective how Ruby On Rails compares to Java web application development. These are the same web development issues I am dealing with in a similar software engineering research & development environment.

Many of the key points in the evaluation addressed all relate to Java productivity compared to Ruby on Rails productivity. Areas of concern for my research work is the increasing complexity of the Java web stack (frameworks integration; Velocity, Struts, Spring, Hibernate, DWR, Axis, etc..) involved in creating Java web applications using AJAX, web services against very large datasets. This appears to be the exact problem domain that Ruby On Rails tends to address. Based on the evaluation article, a productivity ratio of 10-20x is possible. If this is the case, then it makes web development on par with the developer productivity gains attained in the 1990s (ala Delphi) using RAD client/server tools. Kind of a "RAD for the Web" toolset.

I understand that reading an evaluation, researching a new technology like Ruby On Rails will not automatically make you more productive. However, it does address a personal sore issue of web developer productivity without sacrificing quality and robustness. Given the recent hype, maybe there will be a "Java on Rails" in the near future. That would be nice however, from what I have seen, it may not quite possible using Java due to the loosely typed dynamic nature of Ruby compared to Java.

Web development needs to become more productive without sacrificing the quality. The best of both worlds seems to be pointing towards a Ruby On Rails paradigm. I've said this in prevous postings to this blog. Ruby On Rails is definitely on the agenda in the near future for me. Sometime in 2006 with success, I should be able to have a much better perspective on this topic. Your mileage may vary.