SE News

On many application development teams, the ongoing choices, actions, and practices of team members can have a negative impact on code maintainability and hence overall code quality. Until these issues are discerned and tended to, they will become more and more costly, in terms of increasing the time required to perform changes and in ongoing developer resource cost. Further, risk of regression defects increases when code maintainability is compromised, because code that is not properly maintained is inherently more brittle.

This article underscores the importance of code maintainability for application owners and development teams, describes the future impacts of neglecting code maintainability problems, attempts to impart an appropriate sense of urgency for resolving such problems where they are found, and presents some proven solutions.

John Elm

http://www.ibm.com/developerworks/rational/library/edge/09/jun09/designdebteconomics/index.html

Agile development methods and CMMI (Capability Maturity Model Integration) best practices are often perceived to be at odds with each other. This report clarifies why the discord need not exist and proposes that CMMI and Agile champions work toward deriving benefit from using both and exploit synergies that have the potential to dramatically improve business performance.

Hillel Glazer
Jeff Dalton
David Anderson
Mike Konrad
Sandy Shrum

http://www.sei.cmu.edu/publications/documents/08.reports/08tn003.html

Anyone reading or watching the news these days knows that IT project budgets will be tightening further than you may already be experiencing. Although proponents of some languages and platforms claim to provide lower development costs, many others firmly believe that it is the habits of the developers who prefer those environments (more than the environment itself) that leads to rapid results. One of these habits is the proper use of method stubs. By proper, let me define that as stubs that facilitate the development process first, and checking off done on a project plan second.

Scott Nelson

http://www.developer.com/java/article.php/3779616

It is my privilege to congratulate CrossTalk on 20 years of publishing articles for and by the defense software community. Longevity in any field is not easy, but longevity in the fast-paced world of software is indeed a notable accomplishment. The occurring changes during the past 20 years are far too countless to mention, yet they have all contributed to the present state of defense software today. Likewise, those of us currently involved with CrossTalk stand on the shoulders of the authors, editors, sponsors, and publishers who went before us, all of whom significantly contributed in assisting CrossTalk in fulfilling its mission of informing readers of new industry trends, proven methodologies, cutting-edge technologies, innovative practices, and, of
course, lessons learned.

In this special 20th anniversary issue, Gerald M. Weinberg takes a bi-directional view of where defense software had been and where it is going in his article What Have 20 Years Accomplished and What Is Left to Accomplish in the Next 20 Years?, while Dr. Linda Ibrahim provides insightful thoughts about the progress of the industry as a whole in A Process Improvement Commentary.

Watts S. Humphrey cautions readers in his article, The Process Revolution, not to repeat mistakes and to build reliability and consistency into your processes by consistently recording and learning from history. In the same vein, Paul Kimmerly’s article, Heroes: Carrying a Double-Edged Sword, discusses the benefits and limitations of heroes in process improvement efforts.

You may have heard the saying the more things change the more they stay the same. Interestingly, Dr. Alistair Cockburn explores the merits of this platitude in a software sense by reviewing Agile practices in his article Good Old Advice, and focuses on Agile’s applicability in today’s world.

Conversely, Jamie Hohman and Dr. Hossein Saiedian provide guidance in their article, Wiki Customization to Resolve Management Issues in Distributed Software Projects. This article adds new dimensions to the dynamics of traditional project management and provides methods of easing the stresses brought on by trying to manage distributed projects.

Lastly, don’t miss Gary A. Petersen’s witty walk down CrossTalk’s memory lane in his article, CrossTalk: The Long and Winding Road, as he examines the maturity and growth of the magazine as it developed from a diminutively distributed black-and-white copy to its current form and shape.

Karl Rogers

http://www.stsc.hill.af.mil/crosstalk/2008/08/index.html

Today’s enterprises know that continuous improvement of quality and productivity is a prerequisite for survival. Ever-changing market circumstances place a strong demand on agility and flexibility. Now that an increase in labor productivity has caught people’s attention again and off shoring has become the de facto mode of operation, Industrialization and Global Sourcing are key elements in the present-day IT strategy of organizations. Transforming the IT operations from a project mode to a factory mode is part of this strategy.

Hence, the Software Factory becomes more than just a metaphor, both during times of economic recession when companies wish to minimize their costs, and during periods of economic boom, when short time-to-market is essential to increase market share. From the twelve years of practical experience it has become apparent that the productivity and predictability of software solutions through a Software Factory approach have improved drastically.

The book “Managing a Software Factory” provides a complete and integral view of all aspects of a software factory. Catch words are predictability, reliability, quality and high productivity focusing on cost reduction and short time-to-market. Managing a Software Factory can be used as a guide to professionalize your ICT organization and provides a manual for setting up software factories.

Kees Kranenburg (author)

http://www.sdu.nl/catalogus/9789012128261

A switch to agile often conflicts with personal career goals such as maintaining the status quo and working no harder than necessary. These twenty guidelines will help you sabotage your agile project, helping you fail quickly and spectacularly.

Clinton Keith,
Mike Cohn

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea

There is interest in what happens if development methods based on different ideologies are combined. Most recently there has been interest in “agile product line engineering.” Boehm has placed agile development and product line engineering at opposite ends of a continuum. Combining two development methods has elements of genetic engineering and diplomacy and some other disciplines as well. Development involves technologies which behave predictably and developers who don’t. There are many questions about different means of combining and the results of those combinations. Method engineering may have some of the answers.

John McGregor

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

People still get wrapped around the axle trying to understand the difference between incremental and iterative development. The Unified Process authors in the 1990s didn’t help by indiscriminately calling everything iterative development. The two are different and must be managed differently. Successful teams do both at the same time, usually without thinking about it. Then someone starts thinking about it and does one without the other. Bad news follows.

Alistair Cockburn

http://www.stickyminds.com/BetterSoftware/magazine.asp?fn=cifea

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

Some have said that 2007 was the year that Agile arrived, with agile development best practices such as automated builds, test automation, and continuous integration finally beginning to reach critical mass among Java developers. While this is true in theory, the fact is that most Java enterprise projects are still based on more traditional development methods, such as the Waterfall model. In this article, ShriKant Vashishtha explores some of the “pain points” of traditional Java EE development, from both a developer and a build manager’s perspective. He then shows us how certain agile best practices can easily and naturally resolve these problems — without altering the flow of a Waterfall project.

ShriKant Vashishtha

http://www.javaworld.com/javaworld/jw-03-2008/jw-03-agile-practice.html

Software Teamwork is a compelling, innovative, intensely practical guide to improving the human dynamics that are crucial to building great software.

Drawing on years of work with a wide range of teams, Jim Brosseau shows how to drive powerful improvements through small, focused changes that deliver results. These changes are designed to work for the whole team and respect existing organizational culture. Better yet, Brosseau identifies solutions you can start implementing right now, as an individual, without waiting for executive buy-in.

Whatever your methodology, technology, or organization, Software Teamwork demonstrates how to apply solutions to realistic development challenges involving complex sets of stakeholders. Along the way, Brosseau shares important new insights into the attitudes, motives, and personal relationships that project management software just can’t track.

Jim Brosseau

http://www.pearsoned.co.uk/Bookshop/detail.asp?item=100000000246021

Twenty-five years ago, computer programmers often wrote code in environments reminiscent of the cells of cloistered monks. But now that software development has become highly collaborative, developers tend to spend more time interacting with their colleagues than stringing together lines of code.

In the past, software collaborative efforts were more ad hoc than formal. So, collaboration strategies sometimes created more problems than they solved. In a typical workday, the need to respond to emails, attend meetings, participate in group discussions, and manage source control could take up so much time that little time was left to do any coding.

To improve collaboration in software development teams, IBM Research and IBM Rational software engineers have been working on the Jazz project.

Randall Frost

http://www.computer.org/portal/cms_docs_software/software/homepage/2007/s607/Jazz-Eclipse.pdf

OpenUP is a lean Unified Process that applies iterative and incremental approaches within a structured lifecycle. OpenUP embraces a pragmatic, agile philosophy that focuses on the collaborative nature of software development. It is a tools-agnostic, low-ceremony process that can be extended to address a broad variety of project types.

Per Kroll

http://www.ibm.com/developerworks/rational/library/sep07/kroll/