I try do be a software engineering researcher. If I scrutinise myself I am an engineer, not a researcher, and a systems engineer on top of that (but with a clear focus on software-intensive systems).
While trying to finish my thesis I often question if I investigate relevant problems from an industrial perspective, which I believe is the only valid perspective in software engineering, everything else is just playing around. Since software development is a completely artificial activity there are not natural phenomena to study, everything is the result of human activity (and ingenuity).
After attending my latest conference, which had a mix of industrial presenters (probably not peer reviewed) and academic presenters (peer-reviewed, of which I was one) I discussed with a colleague. The conclusion we reached was that the academic researchers had a lot of substance in their presentations, but lacked relevance, while the industry presenters had relevant topics, but lacked substance. The latter seemed in many cases more like a sales pitch.
I have also heard in panel debates at other conferences that software research are diverging from industry needs. This is serious! But what is the problem? Are researchers really addressing the wrong thing (I have already complained about formal methods research)? Or is the step from a published research paper to implement it beyond a simplified academic setting too large for practitioners to take? Or are there so many conflicting research "results" that it is impossible to draw any conclusions as a practitioner beyond personal heuristics? In structural mechanics there are the laws of physics that constrain what is working or not, in software there is no clear boundary like that.
Personally I believe it is the gap, it is just not possible for practitioners to grasp how the results are relevant in their context since research is trying to be as general as possible, i.e. trying to cover as many contexts as possible and in the end not being relevant for any context. Resarch results only valid in a specific context (e.g. a deep case study) are considered second-rate by the research community and often does not pass through the eye of the needle.
There are many different views on the relevance, for example read this report on the future of software engineering research.
What can be copyrighted?
Tuesday, June 5, 2012 at 12:36 AM
Since taking the course on Ethics and Intellectual Property at Chalmers I have become increasinlgy interested in how copyright and patent laws affect software development. United States of America have different patent laws compared to western Europe, usually more obliging of what can be patented, but the legal rulings in the former concern also software used in the latter.
Just a few days ago the verdict in the case of Oracle v. Google regarding copyright infringement on Java API was determined with the concölusion that it is not possible to copyrigth an API, but certainly the implementation of it. A summary of the verdict was written by the judge, William H. Alsup, and is most interesting to read. I think it shows a great understanding of the context of software development from a legal perspective.
Watch an interesting film about the american patent system and software patents: Patent absurdity.
Just a few days ago the verdict in the case of Oracle v. Google regarding copyright infringement on Java API was determined with the concölusion that it is not possible to copyrigth an API, but certainly the implementation of it. A summary of the verdict was written by the judge, William H. Alsup, and is most interesting to read. I think it shows a great understanding of the context of software development from a legal perspective.
Watch an interesting film about the american patent system and software patents: Patent absurdity.
XP 2012
Friday, May 25, 2012 at 6:00 AM
Here are some random notes taken during the 13th International Conference on Agile Software Development in Malmö, Sweden.
This conference has a heavier presence of professionals compared to many academic conferences. To simplify I would say that presentations in academic conferences are heavy with content, but on irrelevant topics, while presentations form professional are on relevant topics but are lacking in substance.
Best quote today, from Jutta Eckstein: “A sign of lack of trust is formalism”. In organisations where trust is completely pervasive they tend to rely on formalism, i.e. meeting protocols, process documentation, etc.
Clarke Ching's TDD Test Drive
Tankesaft, a blog about innovation, inspiration and development by Karl-Magnus Möller – only in Swedish.
So far there have been some highlights: Jan Boris-Möller talked about making food from an engineering perspective. He specialises in catering for events, which is quite different form working at a restaurant. It isn’t very agile in the sense that the prerequisites change once the event takes place, but is is very agile since he does not want to keep notes/plans/… from one event to the next avoiding pushing any preconceived solutions to the client. He talked about the order to implement things as a professional chef (colour->…->amount->texture->taste, and not taste first which is the amateur's starting point). He also talked about balancing quality attributes; the client can only have two of fast, cheap and good, but never all three (if you you want it fast and cheap it can never taste good).
Later in the evening he mingled and talked about the necessity of having both experience and knowledge (and they not being the same), and the necessity to educate the client/customer about the consequences of what they order in order to meet their expectations. Her also wants to inform the guests before eating of the thinking about designing the dishes which he thought enhanced the experience. a lot of developers could learn from this. And yeah, the food was excellent, traditional Swedish resources and flavours in new ways. Definitely the best conference dinner I have had.
One of the most interesting presentations was from Lars Arrhed, a lawyer, talking about contracts regulating agile development. It contained too much information to convey but some a points was: Suppliers (developers) and clients talk different languages. Clients often have a vision of what the resulting product/system should be, which may be very vaguely described in the contract (“Fully integrated system” and “functional administrative system” were two examples from real contracts in court cases). Therefore a supplier should show progress instead of telling about techniques and methods.
I attended some workshops and tutorials on testing and test-driven design. It felt good I could reason about how to refactor a program in a programming language I don't know (Python). On the other hand I was completely stumped when trying to do "wolf-pack programming" in Smalltalk. I could reason about the program in general terms, but it was very hard to write working lines of code.
In test-driven-design I understand the value of producing high-quality code, but the very small loop increments seem almost to hinder elegant designs that are easy to understand.
This conference has a heavier presence of professionals compared to many academic conferences. To simplify I would say that presentations in academic conferences are heavy with content, but on irrelevant topics, while presentations form professional are on relevant topics but are lacking in substance.
Best quote today, from Jutta Eckstein: “A sign of lack of trust is formalism”. In organisations where trust is completely pervasive they tend to rely on formalism, i.e. meeting protocols, process documentation, etc.
Clarke Ching's TDD Test Drive
Tankesaft, a blog about innovation, inspiration and development by Karl-Magnus Möller – only in Swedish.
So far there have been some highlights: Jan Boris-Möller talked about making food from an engineering perspective. He specialises in catering for events, which is quite different form working at a restaurant. It isn’t very agile in the sense that the prerequisites change once the event takes place, but is is very agile since he does not want to keep notes/plans/… from one event to the next avoiding pushing any preconceived solutions to the client. He talked about the order to implement things as a professional chef (colour->…->amount->texture->taste, and not taste first which is the amateur's starting point). He also talked about balancing quality attributes; the client can only have two of fast, cheap and good, but never all three (if you you want it fast and cheap it can never taste good).
Later in the evening he mingled and talked about the necessity of having both experience and knowledge (and they not being the same), and the necessity to educate the client/customer about the consequences of what they order in order to meet their expectations. Her also wants to inform the guests before eating of the thinking about designing the dishes which he thought enhanced the experience. a lot of developers could learn from this. And yeah, the food was excellent, traditional Swedish resources and flavours in new ways. Definitely the best conference dinner I have had.
One of the most interesting presentations was from Lars Arrhed, a lawyer, talking about contracts regulating agile development. It contained too much information to convey but some a points was: Suppliers (developers) and clients talk different languages. Clients often have a vision of what the resulting product/system should be, which may be very vaguely described in the contract (“Fully integrated system” and “functional administrative system” were two examples from real contracts in court cases). Therefore a supplier should show progress instead of telling about techniques and methods.
I attended some workshops and tutorials on testing and test-driven design. It felt good I could reason about how to refactor a program in a programming language I don't know (Python). On the other hand I was completely stumped when trying to do "wolf-pack programming" in Smalltalk. I could reason about the program in general terms, but it was very hard to write working lines of code.
In test-driven-design I understand the value of producing high-quality code, but the very small loop increments seem almost to hinder elegant designs that are easy to understand.
Subscribe to:
Posts (Atom)
