Response to the article: Sharing the knowledge – The role of communication across teams.

The following article is a response to the blog post: Sharing the knowledge – The role of communication across teams by Nick Kaltsas.

 

Introduction

In this post, the author described the importance of the communication and made the management of the cross team communication. When the project has a clear goal, enough experienced people and adequate resources, communication would become the determining factor in the large scale and long term projects. If projects benefit from the efficient communication and coordinating, it would boost the productivity, vice versa.

 

The importance of the communication

I agree with author’s view that communication is really significant in projects, especially in a single large project. This project cannot be independent and need organization to complete it. There are numerous relevant teams to address the problem together. If we ignore communication here, there will produce many drawbacks, such as functional defects and low quality buggy products. In the paper, the example of slow code illustrates that revising the problem result from lacking of communicating would be a waste of time. Author regards communication as a determined element to make or break the final projects in every large scale projects. It can promote the development of software depending on sharing knowledge and exchanging useful information.

 

However, I disagree that every team needs communication.  In some small teams, communications are carried out directly and regularly. They can learn from each other and solve the potential problems as early as possible. In the mean time, it will also lower the productivity of projects because of a waste of time in communicating. What’s more, when the team did not familiar with the project, they would ask two experienced people in charge of the same module so that we could compare the results to select the best one. According to this case, when the individual team organizes the team communication, it will stiff the creativity in this kind of module since they share their ideas.

 

Organizing cross team communication

Managing cross team communication needs to show many details of projects. Nevertheless, different teams often locate in different sites.  They cannot organize face to face communication all the time. When they use other informal communication (e.g. emails, video, conferencing), it would make a contribution to low confidence, delay, and communication failures. As author’s instance of Nokia and Microsoft, which minimize the need of the communication, there is another example to prove that communication cannot apply to every large scale and long term projects.

 

When a company divides a big software development project into many parts. Different parts are in the charge of different teams. The company gives every team a clear goal and standard documents of the module they are responsible for. The tasks need every module has its independent feature; it could be used in different situations and would not be affected by other modules. The only thing need to communicate is that how to connect all the modules. It should focus on the interface at the end of the project. In case of this, if different teams communicate a lot, it would lead to loss the ability of software module independence.

 

Communication in global software development

Global software development (GSD) is a unique case of distributed software development that the teams across national boundaries. Communication plays a dominant role in GSD teams, but most of them are informal communication. This project was cooperated by two companies: Radiante Corporation and Tekelec. During the time of completing the project, the process of coordination, communication and collaboration is key reasons of successfully developing software. However, this project relies heavy on communication, there are many elements from communication reduce the productivity.

 

Initially, there are numerous differences in culture and language. Communication between the two companies should focus more on requirements definition, negotiation and project management. When they cannot understand each other entirely, it would make the project fail. For example, “ Overlooking the development of the future “ can be explained as overseeing its development or forgetting its development. Also, remote sites multicultural communication would lead to time delays, and failure to understand and explain clearly the required system standard. It would cause conflicts of budget and schedule overruns. In the end, members of the project will lose trust of each other.

 

In order to remove the barriers of communication in different cultures and languages, managers come up with some methods to solve the cross cultural issues. Such as cultural liaisons, bridgehead teams, rotation of management. Although it could address the issues, in the meantime, it will decrease efficiency and take the risk of failing in this project.

 

Conclusion

Communication of large projects has an inherent advantage of sharing knowledge to improve the process of projects and addressing the potential issues earlier. It is essential that communication should play a critical role in many large projects. However, when it comes to creativity, the ability of independent, geographical, temporal, linguistic hurdles, we should consider the styles and situations of communication, which could boost the projects’ productivity. Communication cannot apply to every large project. We need to consider about the different environments and conditions of the project.

Reference

[1] Layman L, Williams L, Damian D, et al. Essential communication practices for Extreme Programming in a global software development team[J]. Information and software technology, 2006, 48(9): 781-794.

[2] Brooks Jr, Frederick P. The Mythical Man-Month, Anniversary Edition: Essays on Software Engineering. Pearson Education (1995): 73-83.

[3] Cusumano, Michael A. “How Microsoft makes large teams work like small teams.” Sloan Management Review 39 (1997): 9-20.

[4] Andres, Hayward P. “A comparison of face-to-face and virtual software development teams.” Team Performance Management 8.1/2 (2002): 39-48.

[5] Lindvall, Mikael, et al. “Agile software development in large organizations.” Computer 37.12 (2004): 26-34.

Test-Driven Development – How Applicable is it?

Test-driven development (TDD) is a development process for software that attempts to simplify designs through the writing of tests.

It involves the developer writing tests with an improvement or new functionality in mind and then writing code so this test can be passed. This forces the developer to concentrate on the requirements of the software before writing code, as they need to know what functionality to test. Once this simple code passes the test, it can be refactored to reach the standards acceptable to the development team.

However, how applicable is this developmental process? Can it really be applied to every development situation?

I will be exploring these questions in my post, looking at the benefits of a TDD and problems experienced when dealing with legacy code, small projects and also at how much testing really should be done under a TDD.

What is TDD?

Firstly, in order to be analysed, TDD needs to be correctly specified.

Defined by Kent Beck in 2003, [1] TDD is built upon the concepts of TFD (Test-First development), and can be described simply as:

“TDD = Refactoring + TFD” [2]

A developer who is programming under the TDD approach never writes a new feature or functionality, until there exists a test that will fail because of a lack of implementation.

After the test is passed, the programmer will refactor this simple code to bring it up to the quality of the team standards (this step turns TFD into TDD).

Simply it can be summarised in the following cycle: [See diagram below]

  1. Add a test.
  2. Run all tests and see if the new one fails.
  3. Write some code (causing the test to pass).
  4. Run tests again.
  5. Refactor code.

Diagram 1

Benefits

But are what are the benefits of this practice?

Naturally, due to the nature of TDD, more code has to be written due to the extensive testing carried out.

A model (designed by Muller et al.) compares the development times of startup projects, one developed under conventional methods and one under TDD and the results show that the total code implementation time is, in fact, reduced. [3] (See Image below)

Development Time

Due to the extensive unit testing being carried out, there’s also a greater likelihood that defects are caught early in the development lifecycle, saving time and money had they not been found till later.

Lech Madeyski, showed the benefits of the practice empirically over a more traditional development approach where testing was left to the end of development.

He found that the quality of the unit tests created under TDD was greater, as they scored better on branch coverage and the mutation score indicator than the tests from the traditional approach. Branch coverage and mutation score indicator can be used to show the thoroughness and helpfulness of tests for detecting faults in the software. [4]

Silver bullet?

So we can see the benefits of the conceptually simple TDD in both the speed of development and quality of tests but can all software development projects really be developed under TDD?

Code that has already been developed from a different development style, called legacy code, can be brought up to the standard of TDD, in that small tests can be written to demonstrate the functionality of the program but for a large codebase this can prove tricky and begs the question: is it really worth it?

Having a consistent development process within a team is a reason for converting legacy code to TDD, as it would mean developers who were more comfortable developing under TDD wouldn’t have to switch to unfamiliar practices to work with the older code, likely resulting in less mistakes being made.

Nevertheless, repetition of test creation would almost certainly occur, as the legacy code would already have tests in it. These would either have to be redesigned or ignored in order to fit into the TDD style.

Shihab et al present an approach of such an adaptation, coining it “Test-Driven Maintenance”. It enables teams with limited resources to test legacy systems efficiently by producing a prioritised list of functions that updates as unit tests are written and passed. [5]

As there exists an approach to bring a legacy system under a TDD-like development process (TDM) and because of the positives of having a TDD, it’ll be worthwhile to convert legacy systems, regardless of the repetition that might occur.

The positives are even greater when you see that companies tend to spend over 90% of their total software cost in the maintenance and evolution phases and so making sure these stages are efficient and as well developed as possible will help to save a lot of money. [6]

We need it quick!

Some people argue that the upfront cost, in terms of time, of constructing tests is not worthwhile for a small prototype program rushed to market.

While this might make sense in concept, the consequences of not following TDD are not quite so obvious.

In reality, TDD tends to be very useful in smaller projects, rather than overkill. This is because on this smaller scale it’s easier to be disciplined enough to continue to write tests and follow the practices of TDD. Whereas, on larger projects, developers tend to get complacent due to time constraints and the complexity/number of features that need to be written.

If this small project were developed under TDD and proved to be successful, the extra time sacrificed to create tests would pay dividends in its future development. If, however, the system was developed under some other method it would probably continue with it and so we will end up with another legacy system. Converting this system to a TDM would take a lot of effort, much more than if TDD was followed from the start.

So, even for small projects, I think that TDD is a development style that should be practiced as even though the upfront costs of the tests may slow down progress at the start, time spent here will prove to be invaluable later on.

More tests?!

Many sceptics of TDD complain that while testing is useful for ensuring successful software, it spends far too much time concerned with testing very basic functionality, which they believe doesn’t need to be tested. Also while testing might ensure that the developers are confident that their code works, they don’t get paid to test, this is the job of the testers. [7]

However, redundant testing is just what non-practisers of TDD think it’s all about.

Here is what, Kent Beck, the father of TDD says:

“I get paid for code that works, not for tests, so my philosophy is to test as little as possible to reach a level of confidence… If I don’t typically make a kind of mistake… I don’t test for it”

This shows that even in TDD you don’t have to test every single function and that common sense should be applied.

If you’re concerned you might get it wrong, write a test for it.

In larger projects this philosophy will help keep the total number of tests down, which will mean less time spent maintaining them. It also means that developers won’t spend too long writing tests for the software, while still being able to reap the profits of the TDD development style.

Conclusion

Test-driven development is definitely a development process that needs to be seriously considered more by software development companies.

As we’ve seen it shines in a variety of situations, from legacy code to quick prototypes and even in large startup developments. The positives are shown through the overall shorter implementation times, better quality unit tests and greater chance of catching defects early in development.

The father of TDD, Kent Beck, also dispels some myths about TDD, revealing that tests only should be made when YOU think they should and until YOU are confident with your code.

For all these reasons I think that TDD needs to be something that development teams need to reconsider.

References

[1] – Kent Beck, “Test Driven Development: By Example”, Addison-Wesley, 2003.

[2] – Scott Wambler, “What is TDD?”, 2013, http://www.agiledata.org/essays/tdd.html#WhatIsTDD [Accessed on: 1st March 2014].

[3] – Matthias Muller & Frank Padberg, “About the Return on Investment of Test-Driven Development”, 2012, http://www.ipd.kit.edu/KarHPFn/papers/edser03.pdf [Accessed on: 1st March 2014].

[4] – Lech Madeyski, “Test-Driven Development – An Empirical Evaluation of Agile Practice”, Springer, 2010.

[5] – Shihab et al, “Prioritizing the Creation of Unit Tests in Legacy Software Systems”, 2010, http://sail.cs.queensu.ca/publications/pubs/shihab_spe2011.pdf [Accessed on: 1st March 2014].

[6] – Len Erlikh, “Leveraging legacy system dollars for e-business”, 2000, http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=846201 [Accessed on: 2nd March 2014].

[7] – Assaf Stone, “10 Reasons to Avoid Test Driven Development”, December 2011, http://www.softwareandi.com/2011/12/10-reasons-to-avoid-test-driven.html [Accessed on: 2nd March 2014].