Segmentation Fault: Core dumped..;-)

Does bleeding-edge web application development matter?

Posted : June 15, 2004 at 1:59 pm [America/Los_Angeles]

A day of perusing through the most popular entries on Java.blogs or Erik’s linkblog or your own RSS feeds of the crème de la crème tech bloggers, and you will most likely walk away with the i-need-to-learn-so-many-things-it’s-not-even-funny type feeling.

However, too often I see perfectly capable web application developers building perfectly functioning web-based business applications using Struts 1.0 (for example) and being fairly content about it. Yes, they use MVC or at least they think they do. The M is almost always the place where you see folks being really creative (or not). Forget “always code to interfaces and not to classes“. Here, classes are written with nothing but a slew of static methods. These methods are in turn called from Struts Actions and that’s it. That’s your M. Yes, they know and use connection pooling. Yes, they hide their DB calls (so to speak) by putting these in a separate static method of a different class. Frankly, you could call this layer N or an O and they could care less. As for using O/R mapping apis like Hibernate or iBatis, well, the argument seems to be something like “What’s wrong with my static methods (and my own wrapper APIs hiding DB details) calling Oracle procedures. It’s fast and it works. And I can use tools like sqlplus to figure out issues much faster”. As for the V, don’t even start with Velocity Vs. JSP or SiteMesh vs. Tiles. As far as they are concerned, they could care less.

Which brings me to this:

1. How important is it to be on the bleeding edge of web application development? Let’s break this question down a bit further:

• You can be on the bleeding edge in making your web application development be more streamlined and productive. TDD, XP programming and things along these lines come to mind

• You can be on the bleeding edge in making your web application be more stable, reliable, and maintainable. New Frameworks and APIs, Design Patterns, AOP, and IoC are some of the things that come to mind

From a developer’s perspective, the need to be on top of both of these makes sense. It’s fun, makes you more productive (theoretically, at least) and more importantly, it keeps you marketable. What’s in it for the guy who is paying for it?

2. Let’s say you work in an organization in an IT team comprising of 5 developers, a PM and the rest of the chain that goes way up. Your friend works in a different IT silo, perhaps under the same organizational unit. Your organization has a slew of web apps that your team maintains. Your friend has a slightly different slice of apps to digest. Needless to say, chances of flexing your bleeding edge muscles under these circumstances is pretty much out of question. Any attempts to refactor or rewrite these will probably be met with: “Why should we? If it ain’t broken, why fix it?”. Ok, fair enough. A few new projects come along. Your team gets a crack at one. Your friend’s team is given some as well.

You’ve been waiting to unleash your cool geeko ideas upon applications. Let’s assume that you’re lucky and your other team members let you drive the show. You finally get to do it your way, the RIGHT way, of course . Your friend is a bit unlucky. He has to follow along as per the directions of his tech lead. Things are not as hip in his backyard, so to speak. You both finish, in time and on budget. Is there any reason why you should be awarded more for taking the pains to implement all this bleeding-edge stuff? I mean, assuming that the other team built the application using the same level of competency, how does it matter that you used WebWork 2.x with Spring and Hibernate while your friend used Struts 1.0 with loads of JDBC calls hidden behind the tech lead’s own pet DB API. Are you serving your company’s business needs and ROI any more than the other tech lead. Is their a way to tangibly measure the benefit your efforts and initiative brought to your company?

Frankly, if you really ask me, here’s what I would probably do if I had a shot at running my own IT development team within an organization:

Form a virtual team of tech lead(s), preferably across our entire organizational unit. Encourage them to come up with our very own avataar of Appfuse or .APPfuse (if we were a .NET shop) with our own GUIs and any other nuances that is specific to our organization. Give these folks a charter whereby:

1. They would be responsible for socializing their Appfuse. Basically, go out there and have brown-bags with the various development groups/silos within your organizational unit. Share and learn.

2. Make minor updates and fixes throughout the year (hopefully using up less than 25% of their time) and perform major architectural updates to this framework no sooner than a year (or year-and-a-half from the day we started).

It might be a very simplistic view of the world and I might be way off. But the idea here is simple: There really is nothing called “Best Practices”. It’s all best in your own context (in this case, your organization). Using the least common denominator approach, assimilate your findings into an “application”, and not some stupid “Best Practices” MS Word document. This way, you can make the developers (off or onshore) focus on understanding and implementing the business functionality, and not fight the battle that has been won over many many times.

What do you think? In case you totally disagree, no worries. May be that’s why I don’t get to run my own IT development team after all . At least, not yet.

- Anand

Category: Application Development