This is a copy of a small rant I just posted on the ATG_Tech Google Group.

Please note that ATG isn't the only company doing this, Oracle does it, as do many others. I just think that it's wrong:)

If you draw a graph showing processing power against software license cost for the same software module, over time, you'd see a steady increase of processing power, a pretty flat cost line for years and years, and then once multi-core hit the server market, you'd see a huge jump in cost, without a significant change in the climb of performance.

--------
I think this licensing model is a huge mistake for the customers.

CPU manufacturers changed course from developing faster and faster chips, to developing more and more cores on a given chip at lower clock speeds. The reason is that it's easier, cost-wise and silicon
manufacturing yield-wise, to add cores, and rely on the OS and applications to make use of the multi-cores. So ideally, the end user sitting in front of their computer will see a similar level of
performance increase as chips go wider, as they would have had chip manufacturer continued the megahertz wars. While at the same time, the cost of that increased performance to the chip manufacturers is less. (also there was an approaching barrier of how low you can shrink the die size without moving to a whole other base material, and power dissipation issues).

Intel released their 2.2 GHz Pentium in January of 2002. Current Intel dual and quad core processors don't really exceed 3.0 GHz, and many new chips are still being released in 2.2, 2.4, 2.6 GHz core
speeds. So in 6 years, based on an 18-month Moore's Law cycle (yes, I know Moore's Law is about transistor density not computation speed, but for the sake of estimation, it's pretty close to how the industry was progressing with clock speed before the shift to multi-cores), in the alternate universe of single core chips, we'd expect to see 35.2 GHz chips. With a 24 months cycle it would be 17.6 GHz. At least I think that's how the math works. At any rate, our current multi-core processors don't provide any additional performance based on the performance per CPU we should expect at the current time, based on the history of CPU performance increases.

The problem here is that now ATG (and other per-core licensing products) customer are paying up to 2X more money in licensing cost for very similar (if not the same) levels of performance than if they CPUs had just gotten faster.

You could make the case that for the work of handing request threads, two 3.0 GHz cores perform a bit better than a single 6.0 GHz (or 17.4 GHz) core, but honestly it's really hard to say, since we don't have 6.0 GHz cores readily available to test ATG on. I'd be VERY surprised if the performance was more than 10% different. And yet we have to pay far more for it.

Customers of ATG/Oracle/etc... are being penalized for the (legitimate) decisions of Intel and AMD.
-------

Some ATG product licenses are bound to a specific list of IP addresses. However, it may validate that in a somewhat counter-intuitive manner, at least under Linux.

If, for example, you are running ATG within JBoss on a server with multiple IP addresses (or multiple NICs), you might expect that if you bind JBoss to a specific IP address, that will be the IP that is used in the license check, since clearly that is the real IP the server is listening on.

Not so. It appears that instead of checking the IP address(es) of the J2EE container, it looks at the machine's hostname. So if your hostname is configured to a name that is mapped to a different IP in your /etc/hosts file, your license will fail to validate.

The fix is relatively simple, just change the hostname of the server to match the name mapped to the licensed IP address in your /etc/hosts file, and start up JBoss again.

However, since this essentially alters the "identity" of your server it can have other repercussions on your server. So be warned. It may make more sense to get the licenses issued with IPs matching your hostname, not the actual IP you intend to run JBoss/ATG on.

I think this is a bit of a bug, in my opinion.

Let's define some roles for a full life-cycle ATG Development effort. Your company may not be arranged exactly like this, but it's a good baseline I think.

Client Representative
The single face of the client. The sole conduit to and from the client.

Project Manager/Dev Manager
The owner of the schedule, resources, project status, and interface between the project team and the rest of the company. The solver of problems, overcomer of obstacles.

Architect
ATG Architect. Responsible for application design and quality. Provides ATG knowledge and guidance to the team throughout the entire project lifecycle. Provides mentorship, documentation, and more.

Business Analyst
Responsible for documenting the business requirements and involved in the process of translating the business requirements to technical requirements and test scripts.

Tech Lead
Leader of the technical implementation team. Responsible for code quality, task distribution, and mentorship. Point person for reporting on development status

Tech Team
Team of JSP and Java developers. Responsible for the ATG implementation.

Creative Lead
Leader of the creative team. Point person for creative issues and direction.

Creative Team
Team of designers, and front end (html/css) developers.

Test Lead
Leader of the test team. Point person for ensuring test plans are created, and reporting on test pass status.

Test Team
Team of testers.

---- edit: added on 5/23/08 ------
DBA
Database Administrator to manage the database instances, and review SQL and table structures.

What do you think? What would you add or change?

We need to start with some basic assumptions to guide our solution.

Here is my initial list:

1. The applications being built will be important commerce or personalization sites, but will not be the sort of critical applications like nuclear plant software or air traffic controlling programs which require massive testing and documentation
2. The team may be geographically distributed
3. Time, Budget, Functionality, and Quality are all important, but we recognize the inherent truth of the saying: "you can have it: fast, cheap, good. pick two."
4. The application should be considered as being built for an external client. This may be because you work as an implementor, or simply that the "client" is your company's business team
5. You should be able to be proud of what you've build, the code, the look, all of it
6. You should be delivering something of value to the client, ideally something with measurable value
7. You need to be as flexible as you can regarding changes, without impacting the delivery quality of date
8. The process should be well documented, repeatable, etc...
9. Communication is king
10. We can always improve

In a series of blog postings, and hopefully with substantial input from the ATG community, I am going to try to define ATG development best practices. From how to run a development project, to coding standards, and more. I know it will be impossible to make a perfect set of practices for everyone, there is no one size fits all, but based on some basic assumptions, I will strive for a great starting point, instead of a perfect solution.

It will take time, but will be well worth it in the end.

This practice definition will be focused on delivering the highest quality ATG applications, on time, and on budget, while maximizing flexibility to accommodate the client’s changing needs.

More specifically the process needs to:

• Ensure there is a fixed baseline of requirements to build against
• Allow for accurate estimates, resourcing, budgeting, and scheduling
• Leverage ATG expertise at many steps of the process, including strategy, requirements gathering, and creative concepts in order to maximize the benefit of the platform and minimize development pain (defined as time/cost/stress/quality-impact)
• Support a geographically diverse team
• Define the steps, flow, entrance and exit criteria, and roles for the process
• Minimize time waste
• Maximize communication and documentation
• Be supported by a set of tools and practices to effectively enable the process
• Deliver high quality (low defect) applications, on time and on budget

And here are the things I will try to address:

• Project Roles
• Project Process
• Development Process
• Change Request Process
• Toolset to Support the Processes
• Hardware, Environments, Software
• Coding Standards and Best Practices
• Bug Severity Guidelines
• Test Phase Exit Criteria
• Source Code Tagging and Branching Strategy and Naming Conventions
• Versioning and Build Number Conventions and Tracking
• Project Naming Conventions
• Documentation Templates and Conventions