CSE 110 midterm

Only _ percent for SE to code

50%

Defintion of SE

Software Enignner is the role to work in the team and find scientific, effectient ways to design, build, and maintain applications for customers

The ___ effect, which will affect SE’s from market, political and rate of change

auteur effect

Enumerate 3 - 5 artifacts beyond the source code that is part of software. Besides listing the artifacts explain why it is important and/or how it is used.

Creating an initutive and user friendly ui can mean more than having good code. If the user having bad experience on navigating your application, users will not like your program even though you have great functionality.

Creating a good operating logic will help the user to correctly use your product and do what they want. For bad logic, the user might get confuse and can’t find what they looking for

What’s good about having a 10x developer

Can boost the productivity for whole team if he/she be able to cooperate with the team, Can introduce better tools for the team to use, can help debug complex problem. Can carry the team.

What’s bad about having a 10x developer

If he/she is not cooperating or bring bad attitude with the team because they used to do it on their ways, he/she can lower the team productives because the different tools they use or insights.

SE is a team sport, if he or she wants to go on their pace, others might not be able to keep up. Eventually lead to a greater problem

Postel's Law of SE Professionals

Be conservative in what you send, be liberal in what you accept

Some people deeply wish that tools and technology will solve developer productivity issues. Data and history doesn’t seem to suggest that is a good bet. If that is the case why do you think people keep pushing the tool over people idea?

Sometimes it’s hard to change people or fix their mentality to increase team’s productivity. However, sometime swapping into a new tool might can instantly increase the performance of the team. On the other hand, swapping tool is often easier than swapping people. If swapping tool is making the team in a good enough shape, people just leave it. Enignnering have the bias that trust tools over people becuase tools are usually more controllable than people.

What does it mean to be a “T” Shaped engineer?

A t-shaped enginneers have deep knowledge of one area and a working knowledge of other areas their team needs

Why team are required?

Sometimes solo can only produce so much. If customer need a complex software, solo can take monthes to reach making a good product. On the other hand, people can make better product when their ideas combine since they are able to get more perspective when they working on the product togher. People usually good at differnet things, a team can take care other’s weakness.

Team formation step

Forming, storming, norming, performaing, adjouring

Forming

coming together as a group and introductions. Make sure we know who is on our team.

Storming

team member starts to work on warm ups tasks and figure out what’s the idea for projects

Norming

Team try to figure out a team coding procedure, like what programming language the team will use in the project, what’s the step/rule for code reviews. What framework that the team should use. Bascially a stage to find a way/tools that works for everyone. Solving conflict from storming. People start to settle their role.

performing

when the team be able to start run smoothly and all aiming for the commited goal. The team will not care personal agendas and start to deeply trust on each other. The team is commit to do real work and outputing the proejct

Adjourning

the team is done on making the project, and start planing for receiving new memebers or move to different team. The team start to warp up what they did and reflect on what they did well and what’s not.

Psychological safety

people are free to speak their conceren, disagree and question

organization structure in 3 types

pathologoical(power oriented), bureaucratic(tule oriented), generative(performance).

SOLO

avoid complex work and keep task simple. Do one thing at a time until finished the task. The task should be small and focused.

Pairing

Define role of driver/observer. The driver writes the code and the observer comments on it or guides. The observer is learning and improving the code. Common usage when Senior CE working with junior ce, to spreads information and gets people to beginner mind. Increase the bus factor

Mobbing

the entire team works together on code. It will make a single driver and many observers, researchers, editor, etc. Good start for the project and the team can set agreement on coding styles/rules. It’s also useful when there’s emergency siuations.

Apply The Play Styles:Imagine if we give you scenarios, pros, cons and descriptions can you match them up to the play styles? For example, what would be appropriate in a crisis situation?

In the crisis siuation, a common way to cause this to happen is when the team need to turn in a working product while having very limited time for them to do extra tests. In this case mopping will be the choice since the team can select an experience drivers, and the rest of the member can do research providing necssary data/tools, and others as oberservers to guide the driver and catching potential bugs.

Why is it essential to have a definition of done?

The essential of done for the code should be able to pass unit tests, having good documenataiton, code review, linting, etc. It should be able to pass those checklist that set by the team.

What is the concept of promiscuous pairing? What are good aspects about it? What are bad aspects about it?

It means to rotate partner oftenly in teams. A good aspect of this is being able to spread knowledge and kill while reducing the bus factor. A bad aspect of this can cause fatigue communication by emotionally and mental draining since people need to figure out differnet ways to communicate well. It could cause some people to burn out. Some people who need some solo time might get upset by the unstopping pairing.

when can create bus factor

When we always assign the most important task to the same most knowledgeable/efficient coder. If he/she left no one know what’s going on that task.

When we never change pairs in pair programming, in the end, people know very limited about the whole appliction.

When people feel the code is self-documented and leave it, but in the end, if someone need details explication, the document is not there for he/she to be onboarding.

__ can’t be your designer

user

You can’t be everything to everyone, there will be no perfect ___, ___

usablity, ally

The 99& rule

people are mostly not consuming and using only the software we make.

what is rail

reponse in 100ms, animation 60fps, idle: 50ms, load 1ms

UCD is not ___, respect that there’s no such thing as absolute ___ -easy for one doens’t equal easy for all

absolute, usablity

user story

As a student,

I want to do better on exam,

so I use the flash card app

Core UCD

you are not the user, something make sense to you doens’t mean it will to your user. Validate with real users, not assumptions.

Don’t make them wait. User hate delay, optimize performance and responsiveness. Follow the RAIL rule

User can’t be your designer, avoid asking user what thye want, design and verify it

you can’t be everything to everyone, developer often facing the trade off to achieve optimal usablity and what is good enough

don’t shift/flash the screen, ensure perceived stablity

acknowelede the medium and context of consumption, design for many modes, consider users envirment and outside of software efect

UCD is not absolute, easy for one doesn’t equal easy for all

ilities

usablity - how easy and intutive the software is to use

accessiblity = how well the software works for user with disablity

relibality how often the system fial ro break

performance - how fast the system resposne to user actions

scalablity- how well the system handles growth in users or data

avaliity - of often the system is abvialabel and functions

software arcivites

requirment, design, development, testing, deployment, operation

top-down

start with high level and break down toward small pieces

bottom up

start with small pieces then combine into big map

middle out

start with your most comfortable chapter then go to other chapters, eventually building a book

Incremental solutions

focuse on doing pieces at a time, do whole thing in one go and release. In general, incremental soultions provide more saftey. tend to associate with iterative process. Safter since you see porgess and get feedback as oppose to do someting fo r a long time

for the iron triangle, low cost =

low quality

for the iron triangle, low scope=

higher cost and longer schedule = reduce quality

in performance vs security, high performance =

low security

security vs usability, more security

degrade ux

water fall process model

requirement, design, implementation, verificaiton, maintence

agile model

iterative and incremental, emphasize flexiblity, customer collaboration and rapid delivery

spiral model

combine itertative apporach with risk assessment

Daily stand up

A short meeting that discuess progress and challenges. It keep the team be informed, connected, and calibarted on the progreess.

Story point

a imaginary points that SEs use to mearsure the length of the project and effort they need to implement a user story or task.

backlog

an ordered list that tells what product should be delivered

Sprint

sprints

a type of development cycles that dieliver sotware incrementally and iteratively. It usualy break a big project into small taks and consistantly inprove base on feedback

Retrospective

A stage that happen at the end of sprint. At this point, the team will discuss what went well and what’s not. The propose is for the team to reflect, learn, and improve how they work togeer.

CRUD

Create, update, read, delete

local first

fast, ensure privacy, be able to work offline

Minimalism

SE focus on builidng simple, efficient, and easy-to-maintain system by using minimum of framwork/liberary. Keepoing only essential.

When should you use waterfall

when we have a stable requirnment and fix timeline and budget. When we need formal documentation for everthing. Avoid when requirment changing.

when shoul dyou use agile

when the requirment is uncertain, changing over time. You want frequently user feedback and value collaboration. Avoid when need rigid structure and solid doucmentation.

when shoul dyou use spiral model

the project is high-risk and requirment are not fully knon at the start. The risk analysis is importnat here. Avoid when project is simple or short term

when to use Incremental Model

when you need to deliver a chunck of functionality each time, and it requires the core system is table so that new feature can be added gradually. You want to reduce time to first release. Avoid when you need the entire system working at once

what is BDUF

big design updfron, a big think that plan things out over the project and set porper time for each task.

what is RDUF

plan enought to get going

when to use RAD

when you need to build a prototype quickly, and user are avaible for continuous feedback

Ad Hoc Methods

little design then start coidng

what is github issues in the agile process

track tasks and bugs, plan sprints, familiar with collaboartion by commenting others’ change, assign issue, and tag them for prioirity

Why might one find incremental PRs an important part of the development environment?

smaller focus pr are easier to review qucikly, reviewer can understand the changes qucikly and give better feedback