Reflection of theme 5

The lectures this week contained talks about the importance of the problem area and it's implication on a research paper. In order to write a good paper, one must fully understand what one wants to achieve.

Reflecting back on the 'most academic' work I've written so far - my bachelor thesis - I kind of realize how it wasn't just a waste of time redefining and working on the actual problem area ("problemformulering"). Also, especially Haibo Li's notion of a more 'entreprenuerial' approach to argumenting/explaining results or facts in a research paper caught my attention, as I'm interested in entrepreneurship and start-ups in general.

Looking back on my entreprenurship course, I saw clear connections in how you are supposed to present a business idea to a possible investor in how Li explained the fine balance between just stating cold facts and selling a product. I will definitely keep this in mind when writing my master thesis next year.

Overall the theme this week was rather interesting because I've previously often approached prototype work as something more suitable for actual work projects, rather than research projects where the solution is not often considered a product that will be used. Research results of prototype work, or rather, evaluations of prototype work, is something that I feel is a bit difficult to reference or 'reuse' in future projects because the problem area or implementation so often is closely connected.

As I was thinking about prototypes I came to think about how the scrum software development method is gaining a following in software companies because of its flexible and easily manageable development cycle, as well as good results. Prototype work here is often minimal as the goal is to produce a working subsystem with each implementation cycle ("sprint"). This production code is then evaluated with feedback and extra features included in the next sprint. In other words, you have a "live" product that constantly evolves, rather than a number of prototypes before the actual product is developed.

Maybe research could be done similar to the scrum methodology in how you separate and limit the big, main problem into smaller subsets of problems that you target each sprint. This way a research paper would 'evolve' and be forced to consist of small 'sub-solutions', which could perhaps result in more generalized and less 'hardwired' solutions to the problem area, and as such could be referenced and 'reused' to a greater extent. Although this methodology might be hurtful in situations or projects where it's harder to divide and conquer a difficult academic question.