{"title":"Introduction to the panel session Lehman's laws of software evolution, in context","authors":"N. Madhavji","doi":"10.1109/ICSM.2002.1167748","DOIUrl":null,"url":null,"abstract":"If there is anyone in our community who has been driving with the “high beams” on, right from the start of the journey of software engineering, then in my mind this is, unquestionably, Professor Manny Lehman. While most of us were either in our infancy or fire-fighting software problems, Lehman had his sight set far ahead –on the programming process, as evidenced by a seminal paper published in 1969 [1]. For about thirty-five years now, Lehman has been concerned about, amongst other issues, software’s longterm health, in effect, beyond the next release, while most others – in practice and in research – have had “low beams” on as if the next release is the final release of the software product or system. It needs no further explanation as to why we encounter surprises when we drive in the pitch-dark roads of software engineering. While it mattered little to the society at large in those early years that software systems were not so reliable and were of very limited use, this is not the case today with our society’s already heavy and ever increasing dependence on software. There is no turning back, however, and we must search for ways to create, and evolve, software systems that will provide sustained quality service over long periods in our dynamic environments. Fortunately, many in practice and in research have begun to realise the importance of software evolution and that short-term thinking has an enormous economic and service quality price-tag on it. This panel session isn’t about software evolution in general, although I have no doubts that some discussion might drift that way. It is about Lehman’s laws of software evolution, in the context of the others’ experiences. Lehman has empirically studied the evolution of a number of actual software systems over the years: OS/360-70 and other systems between 1968 [1] and 1985 [2], and more recently in the FEAST (Feedback, Evolution And Software Technology) projects (19962001) [3, 4] (in collaboration with ICL, Logica, MoDDERA, Matra-BAe Dynamics, Lucent Technologies, BT Labs, and with associates, notably Turski, Perry and Ramil [5,6]), he has been able to confirm, refine and extend the earlier results. It is through these relentless efforts, over a long period, that Lehman has formulated and refined eight laws of software evolution (see Table – reproduced from [7]). Slowly, but surely, over the years these laws have gained recognition to varying degrees in pedagogy, industrial circles and in research. It is not my intention to discuss these laws here although I have no doubt that they will be addressed by the panelists, but it is interesting to note that the term law was selected because [7]:","PeriodicalId":385190,"journal":{"name":"International Conference on Software Maintenance, 2002. Proceedings.","volume":null,"pages":null},"PeriodicalIF":0.0000,"publicationDate":"2002-10-03","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":"6","resultStr":null,"platform":"Semanticscholar","paperid":null,"PeriodicalName":"International Conference on Software Maintenance, 2002. Proceedings.","FirstCategoryId":"1085","ListUrlMain":"https://doi.org/10.1109/ICSM.2002.1167748","RegionNum":0,"RegionCategory":null,"ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":null,"EPubDate":"","PubModel":"","JCR":"","JCRName":"","Score":null,"Total":0}
引用次数: 6
Abstract
If there is anyone in our community who has been driving with the “high beams” on, right from the start of the journey of software engineering, then in my mind this is, unquestionably, Professor Manny Lehman. While most of us were either in our infancy or fire-fighting software problems, Lehman had his sight set far ahead –on the programming process, as evidenced by a seminal paper published in 1969 [1]. For about thirty-five years now, Lehman has been concerned about, amongst other issues, software’s longterm health, in effect, beyond the next release, while most others – in practice and in research – have had “low beams” on as if the next release is the final release of the software product or system. It needs no further explanation as to why we encounter surprises when we drive in the pitch-dark roads of software engineering. While it mattered little to the society at large in those early years that software systems were not so reliable and were of very limited use, this is not the case today with our society’s already heavy and ever increasing dependence on software. There is no turning back, however, and we must search for ways to create, and evolve, software systems that will provide sustained quality service over long periods in our dynamic environments. Fortunately, many in practice and in research have begun to realise the importance of software evolution and that short-term thinking has an enormous economic and service quality price-tag on it. This panel session isn’t about software evolution in general, although I have no doubts that some discussion might drift that way. It is about Lehman’s laws of software evolution, in the context of the others’ experiences. Lehman has empirically studied the evolution of a number of actual software systems over the years: OS/360-70 and other systems between 1968 [1] and 1985 [2], and more recently in the FEAST (Feedback, Evolution And Software Technology) projects (19962001) [3, 4] (in collaboration with ICL, Logica, MoDDERA, Matra-BAe Dynamics, Lucent Technologies, BT Labs, and with associates, notably Turski, Perry and Ramil [5,6]), he has been able to confirm, refine and extend the earlier results. It is through these relentless efforts, over a long period, that Lehman has formulated and refined eight laws of software evolution (see Table – reproduced from [7]). Slowly, but surely, over the years these laws have gained recognition to varying degrees in pedagogy, industrial circles and in research. It is not my intention to discuss these laws here although I have no doubt that they will be addressed by the panelists, but it is interesting to note that the term law was selected because [7]: