A Myth or Reality?
Several days ago a topic with the title "Software Reusability: Myth Or Reality?" was posted on Artima. Following the comments on this post since the first publishing I think you should take a look there too. Developing SW for 6 Years now (by far not that long as the poster) I have to agree with him. The problem with reusability is that there are several issues that must be fulfilled that libraries objects .... can be reused.
Several days ago a topic with the title "Software Reusability: Myth Or Reality?" was posted on Artima. Following the comments on this post since the first publishing I think you should take a look there too. Developing SW for 6 Years now (by far not that long as the poster) I have to agree with him. The problem with reusability is that there are several issues that must be fulfilled that libraries objects .... can be reused.
1) Clean self speaking code
This is one of the biggest challenges in SW projects. You need seasoned developers with a passion for SW development and time to write code in that way. Today commercial projects first off all don't have time to do this. Time is a big factor in this game. On the other hand teams in companies have developers with different levels of expert knowledge and it's very difficult to teach "junior" developers until normal working time.
2) Documentation
From my point of view, documentation is important but not as important as the first point I mentioned. We have to differ between 3 kinds of documentation:
a) Tests: they are the best documentation of a program because their actual status (which is documentation) can be verified easily by executing them.
b) Code Documentation: all the xDoc stuff developers write over methods classes and even in code to explain the behavior of the code they have written. The problem with it is that they are getting useless as far as they are not updated with code changes (which is often the case). In difference to Tests they can be just verified if someone reads them and expects something that is not fulfilled.
c) Diagrams: all the UML Stuff which in my opinion is even more difficult to hold up to date.
Answers?
I would answer the question raised in the article as follows:
1) Is reusability something that can be trained for?
I don't think that schools/universities can train developers to program with reusability in mind. Only persons that had to use libraries or old implementation in a project now how it feels not being able to use 1000LOC that where written for a similar domain and can't be reused for the new project. This feeling makes most of them think about possibilities to write code in a other way.
2) Should reusability be a requirement?
It depends on the project. There are projects where it definitely should be a requirement. The interesting question here is how we will measure it? I would say there is no metric that can describe how reusable code is - except for the first two points tests and code documentation I mentioned above. In my opinion it is not enough to say we have 89,9% test coverage and 70% in code documentation. These two values just say nothing about code reusability.
6 comments:
Maybe the question boils down to the point that is discussed in the model driven architecture vs. whatever discussion.
From my point of view, we would have to answer initially what scope (in time and importance) the current development efforts do have.
Sometimes this question is easily answered: when you develop, say a prototype that tests a specific assumption like: will this and that type of query be performant enough or, do the customers like this type of GUI, the answer is clear: reusability does not matter: you will hopefully throw that code away after all. Hence also documentation, tests, UML etc. are irrelevant.
Ok; if you develop a credticard check system for a bank, this is a core system and reusability needs, and importance are probably high.
But what to do with all the other projects? It always boils down to: "how much effort is justifiable during the coding phase, that pays off only after considerable time and reuse activity of the software."
Right?
as the discussion in the original forum post goes on it shows that the software industry actually managed to create much more reusable artefacts than a few years ago: we're not writing webserverver from scratch any more, we normally don't invent message exchange formats all over again, and even hand written hibernate clones are getting less and less popular.
so what aren't we already reusing to a certain degree? mostely business objects - and this is not a bad thing in my opinion. our domain model (and the implementation of it) changes the better we understand the domain. reuse of old domain models might not be a good idea at all, because the old model might not reflect what's needed in the current project anymore.
And how do we write reusable code at all? Don't fall into the pittfall of mistaking flexiblity for reusability.
Well, I think, that there is oftentimes a connection between flexibility and reusability! Actually flexibility is in many cases the foundation for reuse. Don't you think?
A lifecycle traceability through integrated automation cuts across
system requirements, architecture, design, source code and test
cases to improve the quality and effectiveness of the estimation
process, thus better predictability
Thanks for these great tips! Very helpful and very informative.
Please refer to below post for my thoughts on generic software reusability
http://rajnishkasat.blogspot.com/2009/05/software-reusability-how-to-get-ahead.html
Post a Comment