Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
Continuous software engineering
Bosch J., Springer Publishing Company, Incorporated, New York, NY, 2014. 226 pp. Type: Book (978-3-319112-82-4)
Date Reviewed: May 14 2015

I really like the concept of this book, as defined by the quote from the book’s back cover (below). I also somewhat know and like the editor and a few of the authors of the book’s chapters. Given all of that, can I give an honest evaluation of this book? (The answer to that question had better be “yes”; otherwise, what good is this review?!)

Here’s that quote from the back cover:

This book provides essential insights on the adaptation of modern software engineering practices at large companies producing software-intensive systems, where hundreds or even thousands of engineers collaborate to deliver new systems and new versions of already deployed ones. It is based on the findings collected and lessons learned at the Software Center (SC), a unique collaboration between research and industry with Chalmers University of Technology, Gothenburg University, and Malmo University as academic partners, and Ericsson, AB Volvo, Volvo Car Corporation, Saab Electronic Defense Systems, Grundfos, Axis Communications, Jeppesen (Boeing), and Sony Mobile as industrial partners.

Given that the SC is a mixed academic and industry center, how does it come down on the mixture of these two environments? It confronts the matter head-on: “very few major, industry-changing new innovations have originated in academia. Instead, industry has taken over the role of introducing and driving large-scale adoption of new innovations.”

Then, the book goes on to ask why that is:

1. Academic researchers have difficulty getting access to where real problems are being solved, so they resort instead to studying small-scale, student-sized projects.

2. The research community’s demand for empirical data causes it to focus on existing projects where data is easily obtained rather than innovative projects where progress is more likely being made.

3. Since academe tends to ignore market factors, it tends to focus instead on detail, specific process steps, and documentation rather than progress-accelerating steps so necessary in industry.

And then it elaborates: “This leads to a lack of understanding by researchers, and a resulting arrogance towards practitioners. Collaboration, as a result, is notoriously difficult.”

The SC, the book goes on to say, was founded to overcome these difficulties. To do that, it encompasses, at the time of the book’s writing, eight companies, three universities, five research projects, and dozens of researchers.

It also has specific ways of doing what it does:

1. Research is performed in six-month sprints, after which a decision is made on whether to continue.

2. Industry technical experts make the continuation decision.

3. If the study approaches are successful, they are deployed among the participating companies where their effects may be studied.

So much for the intentions of the book and the SC. What about its achievements?

First of all, the book. It’s an edited collection of individually written chapters, surprisingly well integrated in spite of what this kind of approach sometimes produces. Probably, that’s because the editor of the book has participated in writing most of the chapters! (It is also worth noting that one of the authors died while the book was being finalized.)

The book is essentially a progress report after three years of the SC’s existence. Because of that, some of the book’s thoughts are perhaps premature; they describe practices that the participating companies are still evaluating. But at other times, the book is exciting, especially in one of its latter parts, where the authors talk about “industry best practices” they’ve identified.

There are unsatisfying oddments, however:

1. The book defines an era it calls “the Web 2.0 and software-as-a-service (SaaS) world,” but it never gets around to providing a satisfactory definition of that world.

2. It defines something it calls the “Stairway to Heaven” approach for evolving an organization from its traditional way of doing business to the one it advocates. This approach involves steps it calls (a) traditional development, (b) R&D organization--all agile (the agile approaches are key to what the book proposes), (c) continuous integration, (d) continuous deployment, and (e) R&D as an innovation system.

But then, interestingly, although it spends a bit of space on each of those steps, it deliberately avoids any lengthy discussion of step d, on the grounds that “it [continuous deployment] is an extension of continuous integration.”

In the trivia category, the text in one of its figures does not match the text in the description of the figure (Figure 8.1, where, for example, “new functionality” becomes “required functionality”).

But there are also moments of the book’s brilliance:

1. It uses as an example the software development for a model car that has self-parking capabilities (talk about being up to date!).

2. It describes the testing of a program that uses a graphical user interface (GUI) for input, noting that (a) this topic area is poorly covered elsewhere in the literature, and (b) clearly distinguishing the application in question from one where the GUI itself is to be tested.

One more thing. The title of the book is Continuous software engineering, which means that the title word “continuous” is what the book is about. Note, of course, that that word shows up in two of the “Stairway to Heaven” steps. In the book’s concept, continuous is a way of accelerating system development progress by making sure that key players interact continuously and productively, and its interpretation relies heavily on agile approaches to software development, even for large-scale systems.

Now, to that bottom line: Can I give an honest recommendation that one should buy or at least read the book?

1. The answer is “yes” for practitioners. It not only contains and explains lots of ideas that may be immediately useful, but it also describes how the software field’s practice may be moved forward.

2. The answer is “yes” for academics, but for an entirely different reason. It is all too seldom that academics are exposed to what they do wrong, and this book forces them to a level of awareness that may be totally new. Academic research seldom moves the software engineering field forward, as it stands, and this book confronts academics regarding that failure and describes a process they might use to overcome their weaknesses.

Reviewer:  R. L. Glass Review #: CR143440 (1508-0655)
Bookmark and Share
  Featured Reviewer  
 
Distribution, Maintenance, and Enhancement (D.2.7 )
 
 
Management (D.2.9 )
 
 
Software Management (K.6.3 )
 
Would you recommend this review?
yes
no
Other reviews under "Distribution, Maintenance, and Enhancement": Date
A program design language based software maintenance tool
Ince D. (ed) Software--Practice & Experience 15(6): 583-594, 1985. Type: Article
Mar 1 1986
The complete computer maintenance handbook
Bellin D. (ed), Harper&Row Publishers, Inc., New York, NY, 1986. Type: Book (9789780060406189)
Jul 1 1986
Building custom software tools and libraries
Stitt M., John Wiley & Sons, Inc., New York, NY, 1993. Type: Book (9780471579144)
Nov 1 1993
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy