Nism Unit 4

Seminar 2

For the seminar, I worked with Hendrik on preparing slides. Inside the slides, we added the outputs of our website scans, and also included our thoughts on TCP/IP vs ISO/OSI standards. We had an informal discussion about our finding, and it was interesting to see the difference in thought processes for answering the question.

No, as it may not have been as open as advertised. OSI had too many political and organizational influences that struggled to agree with one another and that may have hampered development of a truly open network. An example is how IBM tried to align OSIs development to align with their own business interests. You cannot build a corporate network out of TCP/IP” -IBM, 1992. Another is how federal agencies were required to procure GOSIP-compliant products (A version of OSI). While on the other side TCP/IP was already developed by the Department of Defence (DoD), tested and being used. Furthermore the Internet Engineering Task Force (IETF) had a different approach to making decisions in the form of rough consensus which ties back into the philosophical comment from David Clarke We reject: kings, presidents, and voting. This is not rejecting the OSI model, but more about comparing progress made from then till now trying to imagine a what if scenario of the internet if it was OSI based from the 90s till now

He also sent me an article written by Russell (2013) for further reading. All the above work and food for thought brought something interesting to my attention- the concept of structure and standards compared to creating something that works. Although not yet directly applicable to the module, this is something that I do think about when working. Apart from TCP/IP vs ISO/OSI, I also think of standards that could apply to written code- I am aware of ISO standards that exist for code as a former employer of mine began exploring the idea of applying those standards to our software. It’s not a practice that is widely adopted, thus it’s hard to find details about its adoption rate, but it usually entails writing some specific, restricted dialect of a particular programming language, like C or Ruby (Mittag, 2014). In my research, I also found one academic piece of work arguing that ISO C reduces the expressiveness of the language, making it much harder to use in a case like programming an operating system (Yodaiken, 2021). This is something I’d like to investigate further, when I have time- when are standards more harmful than beneficial, and why?

Team Collaboration

This week, Sharon was unavailable, and so was Wimal (as he mentioned in last week’s meeting), thus I made the decision to cancel the meeting as it would not be productive with only two people. As a result, I had to come up with an alternative. My chosen alternative was to post, on Discord, what our tasks for the week are. To do this, I first discussed the context of our tasks, by mentioning the feedback received from the professor. I then discussed subtasks which would be necessary to complete the assignment and refine the work already done. I lastly requested feedback by Monday, to ensure that the team does not lose time for work.

This was an approach I decided on after cancelling the meeting, and thus, there are ways of improving it because I didn’t have time to think of alternatives. In my personal reading, I’ve come across the concept of “asynchronous meetings”- that is, meetings which are not held in real-time, instead, participants discuss meeting topics at their own pace (Himin, 2020). This meeting is effectively an asynchronous one, however, I am concerned about the nature of feedback- since the meeting is asynchronous, discussions would only continue when everyone provides feedback. This is a problem because productivity blockers (such as technical or practical limitations) cannot be discussed and resolved as soon as they are brought up, instead it would take more time to resolve. This lowers the rate of work while everyone creates responses.

Although this is a niche scenario, I have found some academic insight into various aspects of this situation. Lelis (2020) introduces the concept of “research limescale”, which refers to factors which inhibit progress as they cause students to become less productive. These factors range from becoming stuck on simple questions with easy answers, to anxiety and fear over progression. After reading that, I realised my fears are rooted in concerns over research limescale, because it’s not easy to address them, or mention them during an asynchronous meeting, making me think that the appropriate response is to limit discussion and encourage giving tasks. This, however, can be fixed through other means. The author addressed the problem of research limescale through giving detailed briefs on preassigned milestones, after which, students gave presentations to demonstrate how the set milestones have been achieved. This could be applicable to how I keep asynchronous teams productive and how I approach asynchronous meetings. If I were to set milestones instead of give tasks, and provide detailed briefs, this could eliminate research limescale that teammates might experience even if we need to hold asynchronous meetings. Due to my focus on tasks, I have not been able to do this, but in the upcoming week, I will attempt to find a way of interpreting the upcoming assignment through the lens of milestones, and then asking my teammates to briefly present their work on milestones at the next major meeting.

I will also use this knowledge for improving productivity when I start work on my dissertation because this specific article suggests a specific approach for carrying out research while obtaining optimal feedback. It may be useful to discuss it with my supervisor.

Document Links

Initial Post
Seminar 2 Slideshow
Discord post in lieu of meeting

References

Himin, A. (2020) Not In Real Time: How To Run An Asynchronous Meeting. Available from: https://blog.trello.com/how-to-run-an-asynchronous-meeting [Accessed 5 December 2021].
Lelis, C. (2020) It’s Milestone, not Limescale! Milestoned group supervision as an approach to descale postgraduate projects. New Vistas 6(1):26-31. DOI: https://doi.org/10.36828/newvistas.109
Mittag, J. (2014) Why would programmers ignore ISO standards? Available from:a https://softwareengineering.stackexchange.com/questions/251110/why-would-programmers-ignore-iso-standards [Accessed 10 February 2022].
Russell, A. (2013) OSI: The Internet that wasn’t. Available from: https://spectrum.ieee.org/osi-the-internet-that-wasnt [Accessed 10 February 2022].
Yodaiken, V. (2021) ‘How ISO C became unusable for operating systems development’, Proceedings of the 11th Workshop on Programming Languages and Operating Systems (PLOS ‘21). Online, 25 October. New York, Association for Computing Machinery. 84–90.