Skip to main content

Week 6 Lecture - Reflection of Fishman "They Write the Right Stuff" (1996) Reading


During the lecture, we reflected on the assigned reading: Fishman, "They Write the Right Stuff" (1996)

Summary of Paper


  • The NASA process stifles creativity but that is the point
  • People working at the company have to channel their creativity into changing the process not changing the software
  • 12 of 22 members are women
  • They work strictly 8-5 unlike coders unlike in companies such as Microsoft where late nights are common
  • Its all about the process that allows them to work normal hours, stay on budget and deliver on time

  1. The product is only as good as the plan for the product - plan the most minute detail before commencing writing the code - their requirements are almost " blueprint like detail
  2. The best teamwork is rivalry team work
  3. Have a database on why, how, when etc. code was changed and also a database describing every error dating back 20 years. They’ve accumulated so much data that they’ve been able to create software to predict future errors
  4. Don’t just fix the mistakes - fix whatever permitted the mistake in the first place





Discussion

  • The process at NASA stifles creativity but is there not still a degree of creativity? Is creativity not involved in anything that requires change?
  • Creativity just happens differently - locked in early on
  • Not a normal industry
  • This makes sense in high risk industries e.g. pacemakers, nuclear plants
  • Some forced by regulation
  • May not work in other industries which need to adapt quickly, need to experiment, fail fast etc
  • Engineer who left the org did not enjoy working in the jockey, pizza environment as he had become indoctrinated in this culture
  • Quality, Cost, Time, Scope
  • Where are we with the variables
  • This org is optimizing?
  • Quality is fixed
  • Cost is a variable
  • Scope - Fixed primarily, overall goal stays constant
  • Time: Variable if necessary- not a free variable, they don’t want to use it as a variable but if they identify a flaw they will pull release date


Comments

Post a Comment

Popular posts from this blog

Research Essay

A major assessment component for the Design, Development and Creativity module was conducting a research essay which involved working individually or in pairs. Myself and my partner, Beth conducted our research essay on updating a digital product, the UCD student portal through the introduction of a digital collaboration tool as a core offering for all students studying at the University. This essay involved conducting both primary and secondary research. In terms of primary research, we conducted a questionnaire, interviews and observational research to understand how students currently interact with the UCD student portal and how it can be improved. Once we understood the problems associated with blackboard and how it could be updated by making it a more engaging site, we conducted secondary research, studying existing literature and case studies on the topics of collaboration and utilising collaborative tools. Upon decision on the update required, a usability, requi...
Post a Comment
Read more

Week 4 Lecture

Introduction During this lecture, we discussed different methods for software development including waterfall and Agile. Waterfall is a rigid way to approach software development. It can be beneficial to projects where there are little to no unknown factors as it is a rigid, structured and organized process Releasing iteratively is a useful way to approach software development projects when there is an element of uncertainty. It allows for feedback and changes throughout the development lifecycle.  Required Readings During the lecture, we reflected in small groups on the readings. A reading which stood out for me this week was the Brooks "No Silver Bullet" paper. I enjoyed the metaphor of the werewolf which was used to describe the complexities associated with SDLC which teams don't envision from the onset of the project. The paper stresses that investing in good developers is far more important than attempting to find a solution or a "silver bu...
Post a Comment
Read more

Designing a Robot

In week 9, we worked in small groups to create a robot using an instruction manual and upon creating our robot, we were tasked with creating a "run" function so that our robot could drive around and "guard a base." (for the purpose of the class, the base was a large white box) This exercise was great fun, but at times stressful as we were required to create our robot within a short time constraint. To create our robot within the allotted time, my group divided the tasks amongst us. One individual called out the required materials needed and where they were to be placed, one found the necessary materials and two individuals put the robot together. As requested by our lecturer, we switched roles frequently so that each member got experience working on each of the tasks required. Dividing the roles out amongst ourselves enabled us to create our robot more quickly than if we had completed each of the tasks together as a group.
Post a Comment
Read more