Developing in a large team environment

Our development team at the County spent the last month researching and discussing which development environment(s) to standardize on, particularly with server side languages. All of this started after I requested some funding for an Enterprise upgrade of ColdFusion. Of course, this raised the question of whether or not we really needed ColdFusion. Did we need to have yet another language in use, requiring resources that need to be familiar with it? I thought the decision was interesting because we had to choose based on what would work best for teamwork, a trait often overlooked when evaluating IT products.

We also had some other criteria:

1. Long-term cost
2. Support from the vendors themselves
3. Direction taking place in the industry
4. Ease of use in a team environment
5. Ability to call legacy COBOL processes

Sure, the criteria set forth screamed “conservative.” But that is the environment here, so it was best to not to fight that. Based on that criteria, I knew that it wasn’t even worthwhile to mention newer fad environments like Ruby on Rails.

Developing as a team

Being a web developer at heart, I find myself having discussions with colleagues about what language x can do over language y. I hear a lot about performance strengths of using one language over another. Oftentimes, I have these conversations with developers who work independently. They own their own freelance operations or are the lone web people in their organizations. They do both the programming and the graphic design. Hey, I’ve been there myself.

But how do the mainstream products work with a team environment where not everyone is necessarily a programmer? Which products allow for different roles and at the same time allow for collaboration between team members? It’s been interesting to be able to evaluate products like .NET, J2EE, ColdFusion, and PHP from this perspective. So what did we come up with?

Developing for the enterprise

Probably the best thing you can do for your large team environment is learn best practices in data abstraction. This maximizes code reuse and lets team members use others’ code without knowing exactly how it was written. My division’s discussion ultimately lead to the realization that we needed this sort of methodology.

I have discovered the basic workflow I am about to described based on talks with colleagues and trusted consultants out in the field. For sake of (over)simplicity in describing this workflow, I will call team members that are more experienced with interface issues “designers,” and I will call those that are familiar with programming and databases issues “programmers.” I will focus on web-based applications because that is my forté.

1. Designers rapidly design user interfaces and graphics used in the user interfaces.
2. Designers use the designs to elaborate requirements with the customer.
3. Designers perform user studies with the designs.
4. Designers cut the designs into HTML and CSS. The designs demonstrate the different “states” of what the HTML and CSS will look like throughout the application’s different functions. The markup should ensure accessibility, search engine optimization, cross-browser compatibility, and any other business needs related to the presentation tier.
5. Programmers write includable JavaScript and other client-side processing.
6. Programmers write or reuse database queries, perhaps using stored procedures.
7. Programmers write or reuse a service layer that handles business logic. There may be a reusable object model layer underneath this service layer.
8. Programmers write tags that call these service layers and perform different kinds of presentation. The tags are more understandable to designers than strange dot and function notation that is required for most data abstraction.
9. Designers or programmers use the tag libraries created to build the actual working interface.

With this model, all presentation uses tags. HTML is tag-based, is it not? What about other presentation tier technologies like Flex and OpenLaszlo? Yup. Whatever happens behind those tags is none of the designers’ business, as long as the program performs well and produces the correct markup. And the vast number of designers using HTML out there proves that designers are capable of thinking about development based on tags.

I like this workflow because of the interaction amongst the team members that has to take place in steps 4, 5, 8, and 9. A smart team would document at least the tags and data services extensively so that others could use those assets. We all hate documentation but also realize how important it is at the same time.

I also like the chance of eliminating the “waterfall effect” we often see in development methodologies. The interface is very important to an application’s users, and a development team’s customers often don’t know what they want until they see it. If the team can get part of the application built rapidly for the sake of helping the customer define what it is exactly that they want, then everyone’s a winner. Also, while the designers are working on interface and requirements issues, the programmers can worry about the risky stuff. “Can we integrate with this other system?” “Does this third party product work well for this requirement?” Blah, blah, blah.

PHP does not have the ability to create intuitive presentation tier modules

I’ve mentioned how crucial it is for a language to have the ability to produce and invoke tag libraries. That knocks PHP out immediately. PHP is not a good team language. PHP is designed for programmers that are familiar with procedural and object oriented programming methods, but PHP does not favor those who are only good with HTML. .NET, Java, and ColdFusion all have the ability to create and use custom tags. (I believe these tags are called “Web Controls” in .NETese. Correct me if I’m wrong.) But when discussing ColdFusion, let’s leave out the fact that most ColdFusion development is done using tag-based syntax. Let’s focus on the fact that ColdFusion developers can create custom and it can invoke Java custom tag libraries as well.

.NET and Java are necessary for the enterprise

Of all of the modern development environments, .NET and/or Java are necessary when considering development for a large user base. They perform better for transactional business logic. They come with top-notch development tools that let programmers easily manage their code assets. Sure, you could write spaghetti code or pseudo-objects in ColdFusion or PHP, but have fun hacking together your code to get those environments to perform well under load. And have fun managing your millions of lines of code in those environments.

It is my opinion that .NET and Java are not best suited for web development, but your web development tool should be able to call on assets developed in those frameworks. .NET and Java are not rapid enough; the interface seems to be so disposible these days. Why sweat on working with a strongly-typed presentation language if you’re going to be changing your interface soon to keep up with change anyway. ASP.NET and JSP are popular presentation-tier options from their respective frameworks, but I’d only consider using them in conjunction with tag library concepts I mentioned earlier.

ColdFusion and Flex give the best set of tools to meet users’ interface requirements. They streamline development and provide some nice interface elements. But you should evaluate whether or not you really need what these products offer. ColdFusion in particular has the potential of creating too many “gray areas” of overlap where it’s hard to decide whether to develop a piece of your application in ColdFusion or Java/.NET.

Regardless, ASP.NET or JSP may give you all that you need to meet your requirements. But be wary of ASP.NET’s desire to create a “Microsoft Web” with its out-of-the-box Web Controls. You may end up providing a poor experience for your applications’ visitors who don’t choose to use Internet Explorer.

Our choice was Java

We did make a choice. We chose Java, plain and simple. It does have a lot to do with our investment in IBM iSeries hardware and training on using the J2EE platform. It does have a lot to do with avoiding the headache of training resources in PHP or ColdFusion, although the products are easy to learn (of which I’ve experienced firsthand). The decision does have its downsides, but it is doable and very practical. Especially if we use the methods I mentioned earlier.

I hope to share our progress in uniting everyone into a team environment. I know it won’t come without its travails. Nonetheless, I am excited about the opportunities it presents!

Technorati Tags:
java, .net, coldfusion, it, web design, web development, web, programming

This entry is filed under Design & CSS, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.