May 2004 Archives
"Why the little fish eat the big fish". - Motivation
Posted by malcolmdavis on May 05, 2004 at 06:36 AM | Permalink
| Comments (1)
With the right incentive, the unattainable can be attained
While fighting the Germans during WW II, General Patton's Army ran out of fuel and came to a halt. With no fuel to advance against the enemy, as a joke, Patton told his Army that they could have a pass (time off). The next day, a portion of Patton's Army was several hundred miles away in Paris. Somehow the soldiers had found fuel.
Proper requirements generate proper results
During the 80's a quality and cost study was conducted comparing military, commercial, and civilian avionics. Commercial avionics had the highest reliability, followed by civilian, then military. The military had the highest cost, followed by commercial then civilian. The military systems were the most expensive to produce, and had the highest failure rate.
Under further investigation, it was determined that the problem with the military avionics revolved around the issue of requirements. The military requirements went into how the system should be constructed, by stating specific components in the design. On the other hand, commercial requirements focused on the consequences of failure. If equipment failed during flight, the vendors are required to reimburse airlines for any cost attributable to the failure. For instance, the additional fuel cost as a result of a missed landing opportunity.
In both cases, it was the customer's requirement model that eventually determined the quality and cost of the product.
Service for fee or ASP
In the IT world, I have worked on projects enormously over-staffed, and which abide by every anti pattern process available. Why does this occur? Simple, the firm makes money by charging people. The more people the firm charges, the more the firm makes. If the people are too productive, there is less need for people on the project. Therefore, the firm makes less money.
What happens if someone would to walk into a corporate IT and offer to do the project for free? Everything would be provided including hardware, software, and support. There would also be a guarantee of quality of service. Instead of a 'flat fee' or 'fee for service', the customer would pay based on usage.
In the ASP model everybody wins; the customer pays less up front, the vendor receives a constant revenue stream. Since the ASP focus is on quality, cost and time to market, the manner in which software is developed is drastically different. This is why small commercial companies can run circles around large clunky IT shops. [Little fish eating the big fish].
Personal drive
My father was a big on incentives. While in high school, I was allowed to stay out all night, weekends, what ever, as long as I maintained all A's and B's. Once a C showed up, I was grounded. The rewards were obvious and making the grades was up to me.
Final thoughts
Motivation comes in many forms, and I don't blame managers or contract firms for looking offshore. The problem with corporate IT is an incentive model that breeds bad behavior. If the model is changed, management's behavior will change, and we will all be better off.
I want to thank Terry James for sharing his philosophy on the subject matter. I have spent many years in both the commercial and IT world; Terry helped me understand why the mindsets are so different. Thanks TJ.
Feature Oriented Programming and Design
Posted by malcolmdavis on May 04, 2004 at 09:32 AM | Permalink
| Comments (5)
I recently attended a talk by Dr. Don Batory, on Generative and Component-Based Software Engineering. The goal of generative is to increase the productivity, quality, and reduce time-to-market in software development. [ Who's not trying to do this? Isn't this why Java was invented?]
The part I found most interesting was the discussion on Feature Oriented Programming. For Generative design to work properly, requirements must focus on 'what not how'. 'How' things are to be implemented is a task for design. Requirements should be thought of as a set of features that provide benefit to the consumer.
Dr. Batory mentioned that requirements are a big problem in software engineering. Anyone who has dealt with a government or big IT shops can comment on the problem. Even techniques like Use Cases can contribute to the problem when it drives requirements to individual function points.
FOP is strangely familiarly to the quote made by General George S Patton Jr. "Never tell people how to do things. Tell them what to do and they will surprise you with their ingenuity."
On the flip side, many managers just want the work done, and complain that developers commonly over engineer problems. However, I see this as a management problem and not a developer problem. Many managers don't understand how to set boundaries, or set evaluations that compare performance versus quality of work, but that is a discussion for another BLOG.
Clear the CLASSPATH
Posted by malcolmdavis on May 03, 2004 at 10:26 AM | Permalink
| Comments (4)
One developer, 2 modifications
A developer has made 2 modifications, one to a client class, and a second to component classes. The client and component classes are packaged separately, but deployed together. When the developer tries to run the application, a "NoSuchMethodError" exception is thrown.
The "NoSuchMethodError" problem is a common one seen by developers new to Java. The exception is difficult to track down. Everything compiles and works on the developers box, but the error occurs when the application is deployed. Generally, "NoSuchMethodError" is caused with when the method signature of a class has changed. So why is the problem only showing up when the application is deployed? The CLASSPATH variable is the first place I look.
When the virtual machine starts up, the VM searches for and loads classes in the following order:
- Bootstrap classes - Classes that comprise the Java platform.
- Extension classes - Classes that use the Java Extension mechanism and are located in the extensions directory.
- User classes - These are classes located by the -classpath option on the command line (the preferred method) or by using the CLASSPATH environment variable.
The VM searches for user classes in the global and an application classpath. The global provides default values set at the system level. In NT this is the User or System environment variables. The application classpath is the one set on the load of the application with the -classpath option.
The preferred method
The preferred method is to use the application -classpath and NOT the global environment CLASSPATH variable.
- The JVM I've worked with, if a class shows up multiple times in the classpath, the first class is used and the second occurrence is ignored. Therefore, it cannot be expected to override the default global class with an updated jar on the java command line.
- Most likely a variety of applications will be running on a server. Different apps may/will require different versions of the same component. With the proliferation of open source, it is not uncommon to see multiple versions of Log4j or ORO on a box. Requiring all the Java applications to use a single version Log4j will eventually lead to problems.
- Pollution of the JVM space. A simple application may not require any supporting jars, but placing classes in the global classpath forces the JVM to deal with a support package each time an application is started. [Yes, the JVM has gotten much smarter about this problem, but I wouldn't expect every JVM to work the same, or handle the problem 100% perfectly.]
The nightmare begins
In IT environments with servers configured by an administrator, things get crazy. Some admins place common JARS in the java\lib directory; others have complex login scripts that dynamically change the environmental variables. Understanding the classpath in these settings becomes a nightmare. It only gets worse with different versions of J2EE environments. Some J2EE engines have started to use more and more open source components. If an application and a J2EE container are using the same open source component, with a different method signature, BOOM. Even if the application is J2EE compliant, that doesnt necessarily mean the app will run correctly on all application servers.
NoSuchMethodError
At least the "NoSuchMethodError" indicates that there is a problem, and gives a clue of where to look. Many times the method has changed, but the method signature has not. These problems are much more difficult to track down. Clearing the CLASSPATH will require a little more work on initial configuration of each application, but it will save a host of problems.
|