SE News

The all-volunteer Apache Software Foundation (ASF) develops, stewards, and incubates nearly 150 Open Source projects and initiatives, many of which power mission-critical applications in financial services, aerospace, publishing, government, healthcare, research, infrastructure, and more. Did you know that 50% of the Top 10 downloaded Open Source products are Apache projects? Did you know that most Enterprise Java solutions are built using Apache? We are pleased to showcase Apache Pivot, the full-featured, professional-grade Java development platform for Rich Internet Applications (RIAs).

https://blogs.apache.org/foundation/entry/the_asf_asks_have_you

Getting a project’s requirements right from the start can speed development and ward off problems. Investing the time to create better requirements for a software project takes a major leap of faith, since people tend to think the extra up-front work will just delay development. That’s generally true, but getting requirements right also prevents problems later that can not only delay projects but lead to their failure.

Karl Wiegers

http://www.drdobbs.com/architecture-and-design/225702520

Blaming bad code (or bad code monkeys) won’t help you find performance bottlenecks and improve the speed of your Java applications, and neither will guessing. Ted Neward directs your attention to tools for Java performance monitoring, starting with five tips for using Java 5’s built-in profiler, JConsole, to collect and analyze performance data.

Ted Neward

http://www.ibm.com/developerworks/java/library/j-5things7.html

With the latest statistics claiming that 15- 50% of projects are cancelled before they deliver anything, perhaps what we have always gotten is not what we have always wanted. Intentionality is a property of a decision. A decision that is the result of explicit examination of relevant factors is an intentional decision. It takes longer to make an intentional decision so many managers don’t make the effort. They go with the default, business as usual, and they get what they have always gotten.

John McGregor

http://www.jot.fm/issues/issue_2010_01/column1/index.html

Join the next wave of Web 2.0 software development in the cloud! Cloud applications are the next big shift in application development: instead of building single-user applications to run on a personal computer, new applications are being built as multi-user services that run in data centers around the world. One of the most exciting new environments for building services in the cloud is Google’s AppEngine. AppEngine is a powerful, easy-to-use framework for developing cloud-based services. This book will teach you what you need to make the shift to cloud development using AppEngine.

Mark C. Chu-Carroll.

http://www.pragprog.com/titles/mcappe/code-in-the-cloud

Configuration management is crucial to the smooth development of a product; the time you spend setting configuration management up properly is time you will save later. Sound configuration management is fundamental to delivering a capable product: How can you evaluate what you have if you don’t know what you have?

Kim Pries,
Jon Quigley.

http://www.softwaremag.com/L.cfm?Doc=1251-12/2009

What, specifically, is it about software that causes large software projects to go wrong more often than with other kinds of engineering? This question has been examined before, including in Dreaming in Code, Patterns in Failure, and Why Software Is So Bad. Some of the proposed answers are poor requirements documentation, and that software is just plain harder than other kinds of engineering. I believe there is another answer, however, which has not been stated clearly.

The problem is not the nature of software; software is just a type of machine and is amenable to known methods for good machine design and project management. The problem is the way we approach software projects and our expectations for their outcomes.

In short, we expect too much.

Chuck Connell

http://www.drdobbs.com/tools/223700002;jsessionid=EUEWUHHZT1D2TQE1GHPSKH4ATMY32JVN

Let us begin with a simple statement: All things being equal, the choice should be to reuse, buy, and then build components and services in order to deliver the required solution to the business. But not all things are equal, and that is the purpose of this article: to highlight and discuss the considerations that are required to make the appropriate choice.

Simon Thurman,
Phil Rowland.

http://msdn.microsoft.com/en-us/architecture/aa699448.aspx

In software development, like many other areas of life, we need to decide when some item of work is done. The decision of “doneness” has wide impacts as under-done creates creates defects, downstream rework, and lost opportunity costs while over-done wastes time and resource and incurs its own lost opportunities.

To be even more critical, in my review of documents from hundreds of clients I find that work items are often under-done in important areas and over-done in trivial ones. That is, the document cover, table of contents, document purpose statement, and sign-off areas have been vetted to precision. However, the requirement, design, test plan, or code contained within has defects both minor and major.

[…] I have four criteria I use to help me decide if the work artifact is done to a level that is good enough for what the project needs to do.

Earl Beede

http://forums.construx.com/blogs/earl/archive/2008/09/08/defining-quot-done-quot.aspx

A two-ton granite boulder is massive but not particularly complex; a delicate strand of DNA, although tiny, is incredibly complex. Similarly, a software-intensive system consisting of 15 million SLOC might actually be architecturally simple; a storage- and powerlimited hard-real-time embedded system might involve only a few thousand lines of code yet be so tightly crafted as to be very complex. How do we measure architectural complexity? How do we judge that one system is “more complex” than another?

Grady Booch

http://www.computer.org/portal/cms_docs_software/software/homepage/2008/s4arc.pdf

Value may accure by accident but not often. Professionals must intentionally seek to create value. Its easy for this pursuit to get lost in the day-to-day effort to meet deadlines and resolve issues. It is not an attribute that jumps out at you during development. It isn’t usually visible of its own accord until the product is completed and the absence of value becomes all too apparent and all too difficult to to fix.

John McGregor

http://www.jot.fm/issues/issue_2008_03/column1/index.html

If we have several agile development teams working on the same codebase, how do we minimize the risk of stumbling over each other? How do we ensure that there always is a clean, releasable version at the end of each iteration? This paper describes an example of how to handle version control in an agile environment with multiple teams - it is the scheme that we migrated to at the company described in “Scrum and XP from the Trenches”.

This paper is not primarily targeted for version control experts, in fact such experts probably won’t find anything new here. This paper is aimed at the rest of us, those of us that just want to learn simple and useful ways to collaborate. It may be of interest to anyone directly involved in agile software development, regardless of role - branching and merging is everybody’s business, not just the configuration manager.

Henrik Kniberg

http://www.infoq.com/articles/agile-version-control

Developing software in a team is much like playing an instrument in a band. Both require a balance of collaboration and virtuosity. Jazz defines a vision for the way products can integrate to support this kind of collaborative work, and a technology platform to deliver on this vision.

Jazz is an IBM Rational project to build a scalable, extensible team collaboration platform for integrating work across the phases of the development lifecycle. We believe Jazz will help teams build software more effectively while making the software development activity more productive and enjoyable.

http://www.jazz.net/