Is a Driver’s License a Unit Test?

Posted: September 25th, 2012 | Author: | Filed under: Verification | No Comments »

Is it appropriate to call a driver’s license a unit test? Would that be consistent with unit testing best practices? That was part of the discussion that erupted on our internal Yammer network after someone posted a link to coding by numbers. I argued that a driver’s license was not properly a unit test but an acceptance test of an incoming delivery. When you read the following, bear in mind that software development is a design activity. The context here is a company that needs help to design a solution for transporting people “from A to B”. This was the argument I made against saying that it is best practice to call a driver’s license a unit test in accordance with unit testing best practice.

System Boundary

The driver is a unit in the final system just as the car is. Read the rest of this entry »


Agile Configuration Management

Posted: September 18th, 2012 | Author: | Filed under: Professionalism, Software Engineering | No Comments »

I love configuration management! “But”, you ask, “isn’t configuration management boring?” Well, configuration management can be boring and tedious if you do it manually. With modern tools it is not all that bad. Even if it is boring, that is out-weighed by the sheer importance of proper agile configuration management for a successful software development team.
Read the rest of this entry »


Agile Offshoring in Practice

Posted: March 23rd, 2012 | Author: | Filed under: Project Management, Software Engineering | Tags: , , , , | No Comments »

How is Agile offshoring done in practice? Julian Bass studied seven different companies doing off-shoring London-Bengaluru. He had expected that the companies would have adapted a continuum of practices from Scrum and XP.

Findings about Agile Offshoring

A picture of a team of Indian engineers.

A stereotypical view of a team of Indian agile offshoring engineers. By C. Frank Starmer. Used under a creative commons license. Click image for details.

To his surprise he found that this was not true. Instead, all of the companies had adopted scrum with the exception of iteration demos. All companies did enforce coding standards. This was not really related to agile practices. It was a corporate standard enforced regardless of agile. All companies also claimed that they had collective ownership of code. There were two projects which did pair programming and TDD; none of the others did. Finally, only one project / company had implemented any other XP practices, most notably Continuous Integration. So, is the cost of continuous integration too high for your agile offshoring project?

Continuous Integration for Agile Offshoring

There were two agile practices that I missed most. Only few of the agile offshoring project did iteration demos or continuous integration. Continuous integration requires a lot of work to setup and maintain. But the alternative, late and manual integration is so risky and complicated. Agile software development methods are very much about avoiding building up a debt of unfinished work. It is also about doing the most risky things first. Extreme programming has the right attitude about continuous integration. Regardless if you are in an agile offshoring project or not you should always do continuous integration. You do not need to do test driven development (TDD) to do CI. Just having a build running is enough to catch many errors.

Iteration Demos

Why did so few agile offshoring projects perform iteration demos? I have always found that iteration demos are really useful. They provide an opportunity to interact with the users. To gather feedback from the users. To make sure that they actually look at it before it is to late. This should be more, not less important in agile offshoring. When you are far from the user you should spend more time on iteration demos, not less. Be extreme, try doing it twice per iteration. I have tried and it really worked.

References for Agile Offshoring

  • [2012,article] bibtex Go to document
    J. M. Bass, "Influences on Agile Practice Tailoring in Enterprise Software Development," Agile India, pp. 1-9, 2012.
    @article{citeulike:10477962, abstract = {Agile development projects have become a reality in large enterprises using offshore development models. A case study involving seven international companies with offices in Bangalore, India, and London, {UK} was conducted, including interviews with 19 practitioners. The contribution of this paper is to illustrate the reasons for tailoring Agile practices within the context of large enterprises. The findings show that scrum roles and practices did not conflict with enterprise policies or processes and were thought to improve product quality and productivity. However, agile practices from the {XP} tradition were not so widely adopted. Test driven development did not integrate well within enterprises where independent quality assurance teams were constituted as separate departments. Continuous integration was found to be challenging where enterprise software products required time consuming regression testing and elaborate code release processes. While adoption of coding standards and collective code ownership are necessary to facilitate interaction between disparate stakeholder groups.},
      address = {Los Alamitos, CA, USA},
      author = {Bass, Julian M.},
      citeulike-article-id = {10477962},
      citeulike-linkout-0 = {http://doi.ieeecomputersociety.org/10.1109/AgileIndia.2012.15},
      citeulike-linkout-1 = {http://dx.doi.org/10.1109/agileindia.2012.15},
      doi = {10.1109/agileindia.2012.15},
      isbn = {978-0-7695-4657-5},
      journal = {Agile India},
      keywords = {20120320c},
      pages = {1--9},
      posted-date = {2012-03-20 05:31:50},
      priority = {2},
      publisher = {IEEE Computer Society},
      title = {Influences on Agile Practice Tailoring in Enterprise Software Development},
      url = {http://dx.doi.org/10.1109/agileindia.2012.15},
      volume = {0},
      year = {2012}
    }

Evidence for XP Practices

Posted: March 20th, 2012 | Author: | Filed under: Software Engineering | Tags: , | No Comments »

In a small study, three different projects were examined with respect to the degree that they used eXtreme Programming practices and what the code looked like in terms of size, complexity and coupling. The conclusion was that more agile practices used in a project lead to lower size, complexity and coupling in the product. The study is too small for any definitive conclusions but it is evidence pointing in the right direction.

References

  • [,inproceedings] bibtex Go to document
    G. S. P. de Moreira, R. P. Mellado, R. L. M. Junior, L. A. V. Dias, and A. M. da Cunha, "An Empirical Analysis of eXtreme Programming Practices and its Impact on Software Quality Metrics | ResearchGate," in Workshop Brasileiro de Métodos Ágeis – WBMA.
    @inproceedings{citeulike:10477919, abstract = {This work presents an investigation of three different industrial projects of software development by a Brazilian enterprise. During projects' execution, the company has changed its approach on software processes from {RUP} based process to agile like processes. To assess software product quality metrics evolution, an investigation of product metrics history was conducted in those three projects. This paper characterizes the use of {eXtreme} Programming practices within the analyzed projects and the observed measures of quality metrics in the developed software products.},
      author = {Gabriel de Souza Pereira Moreira and Mellado, Roberto P. and Robson Luis Monteiro Junior and Luiz Alberto Vieira Dias and da Cunha, Adilson M.},
      booktitle = {Workshop Brasileiro de M\'{e}todos \'{A}geis - WBMA},
      citeulike-article-id = {10477919},
      citeulike-linkout-0 = {http://www.researchgate.net/publication/220039429_An_Empirical_Analysis_of_eXtreme_Programming_Practices_and_its_Impact_on_Software_Quality_Metrics},
      citeulike-linkout-1 = {http://www.researchgate.net/publication/220039429_An_Empirical_Analysis_of_eXtreme_Programming_Practices_and_its_Impact_on_Software_Quality_Metrics},
      keywords = {20120320a},
      posted-date = {2012-03-20 04:23:15},
      priority = {0},
      title = {An Empirical Analysis of {eXtreme} Programming Practices and its Impact on Software Quality Metrics | {ResearchGate}},
      url = {http://www.researchgate.net/publication/220039429_An_Empirical_Analysis_of_eXtreme_Programming_Practices_and_its_Impact_on_Software_Quality_Metrics}
    }

Automated Bug Fixing, Innovation and the Small World of SE Research

Posted: March 8th, 2012 | Author: | Filed under: Software Engineering, Verification | Tags: , , , | No Comments »

With automated bug fixing, we can automatically fix 50% of all bugs at a cost of $8. A fantastic research result from the small world of Software Engineering research. But how can we turn these inventions into innovations?

References

  • [2012,article] bibtex Go to document
    C. Wohlin, A. Aurum, L. Angelis, L. Phillips, Y. Dittrich, T. Gorschek, H. Grahn, K. Henningsson, S. Kagstrom, G. Low, P. Rovegard, P. Tomaszewski, C. van Toorn, and J. Winter, "The Success Factors Powering Industry-Academia Collaboration," Software, IEEE, vol. 29, iss. 2, pp. 67-73, 2012.
    @article{citeulike:10454231, abstract = {Collaboration between industry and academia supports improvement and innovation in industry and helps to ensure industrial relevance in academic research. This article presents an exploratory study of the factors for successful collaboration between industry and academia in software research.},
      author = {Wohlin, C. and Aurum, A. and Angelis, L. and Phillips, L. and Dittrich, Y. and Gorschek, T. and Grahn, H. and Henningsson, K. and Kagstrom, S. and Low, G. and Rovegard, P. and Tomaszewski, P. and van Toorn, C. and Winter, J.},
      citeulike-article-id = {10454231},
      citeulike-linkout-0 = {http://dblp.uni-trier.de/rec/bibtex/journals/software/WohlinAAPDGGHKLRTTW12},
      citeulike-linkout-1 = {http://dx.doi.org/10.1109/ms.2011.92},
      citeulike-linkout-2 = {http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5963631},
      doi = {10.1109/ms.2011.92},
      issn = {0740-7459},
      journal = {Software, IEEE},
      keywords = {20120308, 20120315},
      month = mar, number = {2},
      pages = {67--73},
      posted-date = {2012-03-15 10:01:24},
      priority = {2},
      publisher = {IEEE},
      title = {The Success Factors Powering {Industry-Academia} Collaboration},
      url = {http://dx.doi.org/10.1109/ms.2011.92},
      volume = {29},
      year = {2012}
    }
  • [2012,inproceedings] bibtex Go to document
    L. C. Briand, "Research-based innovation in model-driven software engineering: lessons learned from high impact projects," in Proceedings of the 5th India Software Engineering Conference, New York, NY, USA, 2012, p. 147.
    @inproceedings{citeulike:10426858, abstract = {Engineering research needs to be informed by (or based on) industrial needs to have impact, and industrial innovation depends on research to fill the gaps in knowledge and to pave the way for better tools, technologies, and services. In the past few years, in the Certus center at Simula Research Laboratory, we have been exploring ways to foster a closer collaboration between research and industry both to align our research with practical needs, and to further increase awareness about the important role that software engineering research plays as an enabler for innovation. This paper outlines our experiences with recent and successful research projects conducted in collaboration with the maritime and energy industries. We take a retrospective approach to examine the way we collaborated with our industry partners and elaborate the decisions that we believe contributed to the effectiveness of the collaborations. We report the lessons learned from our experience and illustrate these lessons using examples from several projects. The lessons focus on the applications of {Model-Driven} Engineering ({MDE}), as all the projects we draw on here were {MDE} projects. {MDE} is a fast growing discipline and is thought to be a key component of any scalable solution to long-standing software engineering problems. Our goal from structuring and sharing our experience is to contribute to a better understanding of how researchers and practitioners can collaborate more effectively and to gain more value from their collaborations.},
      address = {New York, NY, USA},
      author = {Briand, Lionel C.},
      booktitle = {Proceedings of the 5th India Software Engineering Conference},
      citeulike-article-id = {10426858},
      citeulike-linkout-0 = {http://portal.acm.org/citation.cfm?id=2134280},
      citeulike-linkout-1 = {http://dx.doi.org/10.1145/2134254.2134280},
      doi = {10.1145/2134254.2134280},
      isbn = {978-1-4503-1142-7},
      keywords = {20120308},
      location = {Kanpur, India},
      pages = {147},
      posted-date = {2012-03-08 07:51:33},
      priority = {1},
      publisher = {ACM},
      series = {ISEC '12},
      title = {Research-based innovation in model-driven software engineering: lessons learned from high impact projects},
      url = {http://dx.doi.org/10.1145/2134254.2134280},
      year = {2012}
    }
  • [2012,inproceedings] bibtex Go to document
    S. Datta, N. Kumar, and S. Sarkar, "The social network of software engineering research," in Proceedings of the 5th India Software Engineering Conference, New York, NY, USA, 2012, pp. 61-70.
    @inproceedings{citeulike:10426814, abstract = {The social network perspective has served as a useful framework for studying scientific research collaboration in different disciplines. Although collaboration in computer science research has received some attention, software engineering research collaboration has remained unexplored to a large extent. In this paper, we examine the collaboration networks based on co-authorship information of papers from ten software engineering publication venues over the 1976-2010 time period. We compare time variations of certain parameters of these networks with corresponding parameters of collaboration networks from other disciplines. We also explore whether software engineering collaboration networks manifest symptoms of the small-world phenomenon, conform to the criteria of "social networks", and manifest increasing collaboration with time. In the light of these observations, we highlight some general characteristics of collaboration in software engineering research. The results presented in this paper facilitate understanding of the progression of software engineering from its infancy to maturity, and lay the foundation for developing theoretical models to explain the evolution of its research collaboration characteristics.},
      address = {New York, NY, USA},
      author = {Datta, Subhajit and Kumar, Nishant and Sarkar, Santonu},
      booktitle = {Proceedings of the 5th India Software Engineering Conference},
      citeulike-article-id = {10426814},
      citeulike-linkout-0 = {http://portal.acm.org/citation.cfm?id=2134265},
      citeulike-linkout-1 = {http://dx.doi.org/10.1145/2134254.2134265},
      doi = {10.1145/2134254.2134265},
      isbn = {978-1-4503-1142-7},
      keywords = {20120308},
      location = {Kanpur, India},
      pages = {61--70},
      posted-date = {2012-03-08 07:37:42},
      priority = {0},
      publisher = {ACM},
      series = {ISEC '12},
      title = {The social network of software engineering research},
      url = {http://dx.doi.org/10.1145/2134254.2134265},
      year = {2012}
    }

How to do Agile Version Control

Posted: March 7th, 2012 | Author: | Filed under: Software Engineering | Tags: , , | No Comments »
Oak branches in winter

Does your version tree look like oak branches in winter? By David Hawgood. Reused under a Creative Commons License. Click image for details.

A colleague asks on Yammer about how they should handle all their many branches and thousands of CI jobs. Here are some of the links that came up:


Do we Really Need to Know?

Posted: March 6th, 2012 | Author: | Filed under: Requirements Engineering | Tags: , , | No Comments »

A smiley

Just my musings. Image reused, click for licensing information.

Traditional agile user stories are on the form: “As a user I want to xxx so that I can yyy”. A simple example would be “as a mobile phone user I want to make a phone call to my mistress so that I can arrange our next meeting”. But hey, who cares why I am making the call? Who even cares whom I call? Can we have a little privacy here!


What is the ROI of Testing?

Posted: March 4th, 2012 | Author: | Filed under: Verification | Tags: , , | 1 Comment »

A question that pops up now and then is “What is the ROI of testing?” A Korean research paper from December 2011 tries to answer the question.


Agile is not About Laissez-Faire

Posted: February 21st, 2012 | Author: | Filed under: Project Management, Software Engineering | Tags: , , | 2 Comments »

Many people and companies think of Agile as some kind of Laissez-Faire approach to project management and software development. Agile is in fact a very rigid structure on how to do things so that there may be flexibility in what to do.

Agile project management is based on advanced project management concepts such as earned-value management (EVM) and phased rolling planning.

Agile software development is based on continuous quality control, other practices that are known to generate quality and a tight feedback loop with stakeholders.

An ant hill

Newton wood has some huge ant hills - this is one of them. © Copyright Brian Henley and licensed for reuse under a Creative Commons Licence, click image for details.


There is no grand master plan or architect for an ant hill. Ants simply follow simple behavioural rules. The ant hill emerges as a result of millions of ants mindlessly following these rules.


User Story Life Cycle is Not Enough

Posted: February 20th, 2012 | Author: | Filed under: Requirements Engineering | No Comments »

The usual agile requirements life cycle consists of three simple states: “not started”, “in progress” and “done”. This is not enough! These steps only cover the software development part of the requirements life cycle. Do not forget about the stages before and after. First requirements are new, then they are analyzed and estimated, then they are commited for delivery in a sprint. After that comes the states mentioned above. After that comes release, deployment, maintenance and eventually retirement. Have a look at the Requirements Abstraction Model.