The Mythical Man-Month

Probably most of our readers have either already heard of this classical book by Frederick Brooks or even read it. However, since the goal of this blog never has been to provide up-to-date information but rather to provide a comprehensive list of important and influential literature and multimedia resources about Software Engineering in general, I want to use the time to present briefly this master-piece of SE to our readers who haven’t heard about it yet.

The Mythical Man-Month

Even though the initial version of this book dates back until 1975 and is therefore already 35 years old, it is still worth throwing a glance at it. The Mythical Man-Month has been republished once in 1995 [1] with additional four chapters, among others, his famous No Silver-Bullet essay and a critical review at his initial statements he made 20 years ago.

In the 2nd chapter that carries the same title as the book, Brooks argues that the man-month is a myth and that man-power cannot be directly interchanged for time as many managers in that time (and still today) assume. He thus states Brook’s Law, that adding manpower to a late software project makes it later.

In the following chapters Brooks further discusses the importance of the human factor in SW teams, the significance of good SW design and design reviews, the cost/effort of SW and the importance of good tools.

Astonishingly, many of his previsions, opinions and advices can be interpreted as some of the common (agile) practices and methodologies which represent nowadays quasi de-facto standards in the SE community. To give some examples:

• His advocacy for incremental development (in the No Silver Bullet chapter) fits very well into modern agile approaches such as e.g. SCRUM.
• Brooks also outlines (although not invented by himself and only introduced in the new chapters of the 1995 version) the use of continuous integration, which is nowadays a standard methodology of SE.
• The advocation of a good design and early design reviews adresses the consideration of fault costs and concepts like fault slip-through [2] which is very important in organizations that create critical SW.
• The chapter about project documentation reads like a manual on how to use a modern wiki for documentation in SW project management (which is very common nowadays).
• Similar to this, his chapter about bug tracking previews already some of the features of modern bug trackers.

Although some parts of the book are already out-dated (such as his debugging advices) due to the advances in technology and SE experience, the book is still worth reading and amazingly up-to-date in the rest of its chapters. Furthermore, as we always can learn from history, the book suits for learning the reasons that brought up some of today’s widely accepted SE standards. Additionally, it contains a lot of references to other interesting, classical SE literature.

Link to the book:
F. P. Brooks, The Mythical Man-Month : Essays on Software Engineering, 2nd ed. Addison-Wesley Pub. Co., August 1995. [Online]. Available: http://www.pearsonhighered.com/educator/product/Mythical-ManMonth-The-Essays-on-Software-Engineering-Anniversary-Edition/9780201835953.page

References:
[1] http://www.cs.unc.edu/~brooks/

[2] L. O. Damm and L. Lundberg, “Using fault slippage measurement for monitoring software process quality during development,” in WoSQ ’06: Proceedings of the 2006 international workshop on Software quality.    New York, NY, USA: ACM, 2006, pp. 15-20. [Online]. Available: http://dx.doi.org/10.1145/1137702.1137707

Software Engineering ≠ Computer Science

Today I came across a very interesting article (via the SE Radio podcast) at Dr. Dobb’s with the title Software Engineering ≠ Computer Science by Chuck Connell. As this is a discussion topic that happens to appear over and over again, I think it’s a very interesting article that I really recommend to read.

Chuck draws the line between Software Engineering and Computer Science where the human comes into play. Thus, everything that requires human intervention (like requirements engineering, maintainability, etc.) is part of Software Engineering. On the other hand, things like algorithms, machine learning, etc. do not require human intervention and therefore belong to the field of Computer Science.

Based on this observation, Chuck formulates the thesis Software engineering will never be a rigorous discipline with proven results, because it involves human activity.

Thus, he argues that we should not try to make software engineering into an extension of mathematically-based computer science, while simultaneously computer science will never be the whole story since software engineering also includes other facets such as creativity, vision, multi-disciplinary thinking, and humanity.

Links to the article:
Software Engineering ≠ Computer Science by Chuck Connell. June 2009.

Additional links:
Podcast about the topic at the SE Radio with Chuck Connell

Scrum in under 10 Minutes

Scrum (or sometimes SCRUM) represents an agile development methodology. It works with a product backlog that contains all features that should be implemented for a product. This backlog is then partitioned into iterations, called sprints, which typically range from some days to about a month of work. The goal after each sprint is to have a working and hopefully bug-free increment of the product.

Image from wikipedia

Hamid Shojaee made an 8 minute video in which he explains the main concepts of Scrum. Although being a bit fast-paced, the video is quite interesting and also visually very enjoyable.

The video explains the different kinds of backlogs, the sprints, standup meetings, and burndown charts, which seem like a nice tool for visualizing the project progress and estimating the remaining effort.

Watch the video below or the HD version on youtube.

The Influence of Organizational Structure On Software Quality

One goal of software metrics is to estimate and forecast the quality of a software product. In recent years, a number of metrics for the software product as well as the process have been developed, which mostly deal with things such as code complexity, code churn or productivity of the process.

But while it is widely known that a software product is largely influenced by the structure of the developing organization, this fact has not been taken into account in existing quality examinations of software products. In their paper “The Influence of Organizational Structure On Software Quality: An Empirical Case Study“, Nagappan, Murphy (both Microsoft Research) and Basili develop a scheme of organizational metrics to evaluate the complexity of an organization.

They identified eight different metrics, among them:

Metric	Assertion
Number of Engineers (NOE)	The more people, who touch the code, the lower the quality
Number of Ex-Engineers (NOEE)	A large loss of team members affects the knowledge retention and thus quality
Edit Frequency (EF)	The more edits to components, the higher the instability and lower the quality
Depth of Master Ownership (DMO)	The lower level the ownership, the better the quality

They evaluated their metrics on the Codebase of Windows Vista (over 3400 Binaries, >50 Million Lines of Code, thousands of developers) with very astonishing results. They tried to estimate which binaries of Vista would have a fault in the field (are failure-prone) and which are not failure-prone. 86.2% of the predicted failure-prone binaries were actually failure-prone (precision) and 84% of all actual failure-prone binaries were correctly predicted (recall). They repeated their prediction with different metrics and compared the results:

Metric	Precision	Recall
Organizational Structure	86.2%	84.0%
Code Churn	78.6%	79.9%
Code Complexity	79.3%	66.0%
Dependencies	74.4%	69.9%
Code Coverage	83.8%	54.4%
Pre-Release Bugs	73.8%	62.9%

As it can be seen, the organizational structure metrics out-performed every other metric in terms of precision as well as recall!

One might argue that this might only be true for such big organizations, but the authors state that the results of a reduced study indicate that 30 developers and 3 levels of organizational depth are sufficient to draw reliable predictions.

The article is very interesting because organizational structure metrics are not widely known (the paper is of January 2008), not even to mention applied in quality estimations, yet. When I first heard about this, I was very suprised that they performed that well in comparison to other established metrics (some of them tens of years old). Even though it might of course be that the results of the authors are not generally applicable, the article is definitely worth reading and I’m sure that these metrics will in future be of great relevance in practice.

Links to the article:
The Influence of Organizational Structure On Software Quality: An Empirical Case Study. By Nachiappan Nagappan; Brendan Murphy; Victor Basili. January 2008

Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong

Agile development methodologies such as iterative development, pair programming or continuous integration have found their way out of small startups even into big firms. Their promise to better adapt to change fits well to the current reality of always changing businesses, which was also one main argument for employing SOA.

But unfortunately, the change from a waterfall development process to agile methodologies is not as easy as pushing a button. In his article “Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong“, Charlie Martin tells the story of a project that he did some years ago in a company. Disappointed from their past waterfall project, which was not really successful, he and his co-workers decided to drive their next project in an agile way. But mostly due to organizational difficulties, the project failed terribly. Their management wanted a commitment about budget and time up-front, which of course is not easily possible when going agile. So they started collecting all requirements and planned their whole project in a project management tool. Also, their plan to roll out small incremental releases in short cycles failed, because the rollout of these builds required effort in the rest of the organization and this effort had not been scheduled.

In the end, they ended up with an so called agile project which was in fact a waterfall project (with a “let’s pretend” schedule) with different terminologies.

Although being an easy read, the article is particularly interesting, because it shows the pitfalls which lie in establishing agile development in an existing organization. In the second part, the author also presents some counter-measures against the problems he faced in his story.

Link to the article:
Cargo Cult Methodology: How Agile Can Go Terribly, Terribly Wrong, Cio.com

Continuous integration

In this web article Martin Fowler, author of several popular books on topics such as refactoring and test-driven development, explains the agile practice of continuous integration (CI). CI is the process of committing and integrating frequently (at least once per day). This allows development teams to find bugs quickly and increase communication.

As Fowler points out, the basic idea is that team members divide their work into small chunks and commit them frequently, possibly every few hours. Developers do this by first checking out the current repository after they have finished their work chunk, then building and testing a local build and finally, if everything works fine, commiting the changes to the server. After commiting, the complete build is tested on the integration machine.

Obviously, CI requires a well-defined test suite, which is why CI works hand-in-hand with test-driven development methods. Additionally, very good automation mechanisms are necessary in order to avoid unnecessary maintenance overhead. Fowler devotes several sections to this topic.

Continuous integration has several advantages. Above all, it allows the development team to find bugs very quickly, as developers constantly test how their code interacts with the code from other developers.

As I have come across this topic recently in several presentations of different companies (among them Ericsson), who all name continuous integration as one of their major practices, I think this is a very interesting article with a huge relevance in the industry. It is definitly worth reading.

Link to the article:
Continuous integration

IT doesn’t matter

Although only 5 years old, the article “IT doesn’t matter” by Nicholas G. Carr is already a little classic. The author discusses the current and future role of IT within an enterprise and argues that the current strategic asset IT will soon become a commodity, like for example eletrical energy, which all companies have equal and virtually unlimited access to.

He draws the comparison to the buildout of railroadtracks in the 18th century. As long as only few companies had access to railroad tracks, they represented a valuable strategic advantage over competitors, which still used steamboats. But after the buildout was complete, everybody had access to it and railroads became a commodity. When IT was young, it also gave the managers that first understood it’s value and employed it in their companies, a radical advantage over customers. They therefore tried to exclude others from the use by employing proprietory technologies. But the buildout of the internet drove companies to the need of using more and more standardization to be able to communicate with others. This made it possible to be able to exchange soft- and hardware components more easily. Because of this and the increase of computing power by magnitudes while still being much cheaper, IT became ubiquitous. But it is scarce resources that make a strategic value, not ubiquitous ones to which everyone has virtually unlimited access.

IT being a commodity has some implications on managers. Their focus shifts to efficiency. Since everyone has equal access to IT, only the one with lowest cost has an advantage over the others. The other challenge for managers is to manage the risks that lie in IT. IT may be a commodity, but when it fails it has huge implications on every business, which can be seen similar to an electrical energy outage. Managers have to realize this and prepare for it.

Because of his controversial theses, Carr’s article was widely discussed and there are many people that disagree with him. Carr collected a huge number of responses on his homepage including critical ones.

Link to the article:
IT doesn’t matter (excerpt)

How we went digital without a strategy

During a research on wether a company needs a strategy or not to survive in the global market I came across this article in an issue of Harvard Business Review from October/September 2000. In this article Ricardo Semler, the CEO of the brazilian based company Semco, describes how his company runs already successfully for more than 20 years without having a strategy.
This article is rather interesting since you can find a lot of information on how to do and implement a business strategy and why it is good to have one, but very few article about why not to have one.

Link to the article:
How we went digital without a strategy (excerpt)

Additional links:
Semco website