Some ineffective development practices have been chosen so often, by so many people, with such predictable, bad results that they deserve to be called "classic mistakes."

A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: "Does this add real VALUE to the system?" If the answer is "no", don't do it. All other principles support this one.

Recently we have heard a lot about Linux. Several discussions have been held in the professional circles, and the media is getting the message to the general public. It can be considered the major open source product, and the responsible for this public awareness. However, the concepts behind open source must also be explained, and - beyond this - the existence of open standards and protocols shall be understood. The comparison between "open" and proprietary software should not be limited to the cost, neither be influenced by the impression that open means free. What is the importance of this understanding for multimedia project managers?

The developer world is divided into two camps. Language mavens wax rhapsodic about the power of higher-level programming — first-class functions, staged programming, AOP, MOPs, and reflection. Tool mavens are skilled at the use of integrated build and debug tools, integrated documentation, code completion, refactoring, and code comprehension. This article provides interesting thinkings on how tools and languages interract.

A successful implementation of a commercial off-the-shelf-intensive software system can save programs money if you have the right solution and understand the potential risks involved.

Determining what architecture products are needed to support software development within a larger systems engineering process is a challenge. Existing documents such as the Department of Defense Architecture Framework provide some guidance, but no defined product identification process. The method proposed in this article provides a repeatable process for selecting the architecture products required to support a larger systems engineering effort, defines the content of each product, and identifies each product’s customer.

Despite an exponential increase in the demand for and dependence on software, many software manufacturers exhibit unpredictable behavior. It is sometimes difficult to determine, for example, a software product’s release date, its features, the associated development costs, or the resulting product quality. This article presents a methodology to support software release decisions.

Traditional software estimating is effort-based and follows a bottom-up approach. This approach does not show the impact of different team sizes or the impact of schedule, cost, and quality constraints. The authors propose a method that decomposes programming artifacts into elementary units of work that form the size used for model-based estimating. The process is simple to implement, flexible, can be tuned with actual project performance data, and fosters developer buy-in by involving them in the estimating process.

For large projects, automated estimates are more successful than manual estimates in terms of accuracy and usefulness. In descending order, the costs of large projects include defect removal, production of paper documents, coding, project management, and dealing with new requirements that appear during the development cycle. In addition, successful estimates for large projects must be adjusted to match specific development processes, to match the experience of the development team, and to match the results of the programming languages and tool sets that are to be utilized. Simple manual estimates cannot encompass all of the adjustments associated with large projects.

This article is an introduction of MoMELib J2ME library and sharing of some my ideas about simplifying of development of business (not games) J2ME applications. Especially implementing multithreading in J2ME applications.