GlacieReiN

Tuesday, 29 August 2017

This week, we had Prof Damith and TA Su Yuen for our lesson. Prof Damith taught us how we can prepare for our presentations next week (the app seminar), while TA Su Yuen taught us what to consider when building our product.

Prof Damith mentioned a couple of acronyms. PUMA, WIIFY, and so on. However, the only things I can remember right now are do-believe-know, WIIFY, benefits instead of features, and finishing strong. Prof Damith used Apple's product launches as a case study. The launches often involve telling the users what they can do with Apple's products (watch videos for long hours, for example), instead of overly technical descriptions that are measured by bits or bytes. I guess this means that people are unable to translate the features into benefits in such a short time.

For do-believe-know, Prof Damith mentioned lectures as an example of "know". It is thus crucial that our presentations motivate people to do something about the apps we are presenting. Doing that would also catch the audience's attention, as they will need to listen to know what to do.

Finally, the most important point of Prof Damith's presentation, in my opinion, is WIIFY. I always switch off when I feel like there's "nothing in it for me", so I understand how important it is to hang that bait in front of the audience.

The only problem is, the only reason why people should listen to us in the app seminar would be the 1/9 chance of them having to critique us.

TA Su Yuen discussed about things to consider when designing an app, and, of course, how important designing is. She proposed several versions of mock-ups, which I think is agreeable. However, I feel that designing in digital form is really not my cup of tea. Plus I will end up spending more time learning about the prototyping software itself too. I usually stop and move on to programming after drawing a few versions of pen and paper designs.

Su Yuen also discussed about empathizing with the user. Her talk really came in too late. Would have been nice if she came to speak on our very first lesson. All these design thinking skills, we always "learn" and then forget to put them to real practice.

In my opinion, the most important thing I learnt from Su Yuen today was the number 3. The maximum of 3 things to do per screen. I was using oBike phone app (without unlocking anything of course) for the very first time today. There were so many tiny buttons that do pretty important things. There was a "!" button that was for reporting faulty bikes. However, "!" also means "info". And that was just the beginning of some huge confusion with the oBike UI...

I look forward to building minimalistic but powerful apps in this module.

Labels: ,

3 comments | Leave a comment



Monday, 21 August 2017

Principles of Software Engineering (Colin)

The main takeaways: Design is very important, no need to use fabulous frameworks, start everything early and stay early, learn to prioritize, users are (almost) king. Most of what Colin said was a refresher to me because it is really high-level understanding. Really eager to hear something more specific and technical. E.g. Walking us through the process of designing a specific type of (simple) app or API as a case study. Or conduct a comparison or evaluation between frameworks or libraries with similar goals.

Lecture notes:

Breakdown of roles

Programmers

Architecture

Colin says we need one person in-charge to coordinate the input of the other team members (e.g. technical proficiency).

Programming

This is a very small part of software engineering. As the projects in CS3216 are non-trivial (must be production-ready), we should not jump into programming right away. We should first design and plan our application. This reduces the number of times we create breaking and expensive changes along the way.

Documentation

Colin also emphasizes the importance of documentation. We are not likely to remember what we have programmed some time ago.

Non-programmers

Features

It does not matter what your technology stack is. Create something which solves somebody's current needs (more people if possible, for a user base and potential business model). We must empathize with our target audience.

Graphic Assets

Designers should consider expanding their skill set beyond Photoshop. For example, Illustrator.

Documentation

Non-programmers should still be familiar with the product and be able to write user guides at the minimum.

Sales

Conducting sales and branding will not only help increase and diversify user base where possible, but also curate more customer feedback and experiencing general responses.

Two non-programming roles

Designer and/or marketing

A person who plans the brand and design of the app is essential in bringing in users and feedback from the perspective of a potential user.

Leader

The leader is in charge of dividing the work, follow-up with every assignee, and conduct user testing on the product.

Different software development life cycle (SLDC)

The waterfall model

Step 1: Requirements analysis (produces a requirements document book)

The business analysts will gather all the needs and requirements from their clients and document their findings and possible designs.

Step 2: Design

Based on the requirements, plan the system architecture and tools to use.

Step 3: Coding

The plan in Step 2 is implemented. User tests are implemented here as well. The code base is rectified accordingly.

Step 4: Testing

This is where the user acceptance testing (UAT) happens. The client will test the product and provide feedback. If the client is unhappy with our product, we will not get paid. The vendors (which is us) will then return to Step 3 to work on the client's feedback.

Step 5: Maintenance

Produce any other relevant programs, scripts, or documentation which aid maintenance.

After a few years, the product becomes obsolete, and the whole cycle repeats.

Disadvantages of the waterfall model

The only constant is change. The client might have changed his requirements, or insisted that we got his requirements wrong (perhaps we were really wrong). Within our "company", the waterfall model causes us to suffer from late integration and late testing because we do complex things one-by-one, and there is a lot of idleness.

Agile process

The agile process consists of stage-by-stage development, ranked by importance. The more important and core features are implemented first. With each iteration, more features are added. However, every iteration produces at least an MVP.

The agile process is an extremely rapid switch between the stages of the waterfall model, except that the amount of requirements, design, and code increment gradually.

This process is not just rushing. It teaches us to prioritize features while remaining flexible to changes.

Disadvantages of the agile process

This process might not be thorough and thus not fast enough to create highly scalable applications as there is a lot of communication involved between people in the team. I.e. Agile is very difficult to execute in a very large organization where there are a lot of communication barriers (many people in between).

Guidelines for our assignments

  1. Big dream
  2. But rank the features
  3. Look at your team (make use of their proficiency)
  4. Look at the clock

Designing an app

We need to decompose the app into several components.This reduces complexity, as we may not understand immediately how to solve the problem, but we can make use of abstractions.

We also need to divide the work, and use each other's code just by knowing the interface or specification.

Typical levels of decomposition

  1. Sub-systems (e.g. a system of micro-services communicating with each other)
  2. Layered hierarchy (e.g. inheritance, module imports)

Low coupling

Modules should not make assumptions about other modules. Some ways to maintain low coupling include no global variables, no mode variables to change the behavior of the method.

Phased deployment

Colin emphasizes the need to validate the produce live constantly. In my experience, deployment can be a pain (different server, different environment, etc.). This causes me to look through all sorts of error logs ranging from bash, Nginx to the web framework itself.

Deploy early.

MVC architecture

Colin pointed out that the change of the model is very likely to cause breaking changes on the controller and view.

Database schema design

In NoSQL, there are no relationships. This means the tables are de-normalized (add redundant copies of data since there are no relationships). For non-trivial applications, the redundancy is significant and confusing, disorganized.

Tips

Resist feature bloat

We can rank the features, but keep the core feature ranking at the top consistently. This ensures we actually complete the core features. The "new" features may be helpful, but they should still be ranked below.

Testing

Consider a separate alpha deployment. Ensure nothing breaks.

Respond to user feedback

Respond selectively. If no other users care about this feature, perhaps we should implement the other more important features.

Backup user data

User data is priceless. If time permits, we should take a look at one-step restoration methods (in addition to AWS snapshots) like Ansible.

Start with pen and paper

While prototyping tools create beautiful and professional mock-ups, we might get distracted by learning the prototyping tool itself (i.e. where to change this part, that part, etc.).




Hi I'm Chris and I'm here to talk about Scrum (Chris)

Chris clarified some of doubts regarding product owner. I had the misconception that both the product owner and the scrum master are the leaders of the team. The backlog concept is new to me, but I cannot appreciate such overly-elaborate planning. I can at most look forward by 1 or 2 releases, not a whole product backlog. My previous company does weekly Scrum but without organizing sprints. Maybe that was why I got blocked for way too damn long. And... a sprint of 3 days sounds inhumane to me. I prefer having all 5 working days and grabbing stuff over from the next sprint if need be. Feelings do not matter, but they still affect us.

Lecture notes:

Roles in Scrum

Product owner

Decides what will be included in each of the releases. Somewhat like a client and more of a requirements person.

Scrum master

Ensures progress and does the communications to meet the product owner's expectations. Could be part of the team as a developer or designer. Somewhat like a project manager.

Team

Developers and designers who also play a part in the design and features. They are the main implementer the actual product.

Epic (or user story)

As a (role), I want (feature), so that I can (benefit). From this statement, you know who wants this feature. You have a name for this feature, and finally, you know that this feature has a purpose.

Product backlog

A list of features and what ought to be inside for all versions, including future ones. Rank features by must-have (high), nice-to-have (medium), bells and whistles (low). Release backlog is for past and current releases.

Time

Task cards

Estimate the time taken for each feature and put them into sprints.

Sprints

3 days to 1 week. The frequent checkpoints ensure progress is made and resolve blocked tasks as a team.

Daily scrum: Stand up meeting (15 minutes)

At the start of the day, everyone answers 3 questions: What I have done last week, where am I blocked at or need help with, what do I plan to do this week. This is what I did at my previous company. The meeting usually lasts for 30 minutes because there are more than 10 people.

Labels: ,

1 comments | Leave a comment



Monday, 14 August 2017

I hope to learn:

  1. Fast
  2. Making something really useful and sufficiently complete, unlike my personal side projects
  3. Experience the whole process of design and implementation
  4. How to engineer a product in a team, instead of doing it alone
  5. Different perspectives from people about UIUX
  6. Discipline in creating quality products
  7. More about various frameworks and libraries, and the philosophies behind them
  8. More about Facebook API design and usage, never managed to understand such APIs (including Google's) back then
  9. To find and correctly implement or debug programs based on the answers from the internet

Labels: ,

0 comments | Leave a comment



GlacieReiN

2015/10/10

About Blog

Anything geeky or nerdy shall be here!

About Me

Currently at a loss for words

My LinkedIn

Programming Languages

(in descending order)
  1. Python
  2. Ruby
  3. Java
  4. JavaScript
  5. C#
  6. Everything Else

Web Development

(in arbitrary order)
  1. HTML
  2. CSS
  3. jQuery
  4. Bootstrap, Materialize
  5. Hugo
  6. Flask
  7. Ruby on Rails

Others

  1. Elasticsearch
  2. MongoDB
  3. Chef
  4. Ansible

The Hacks

2015

    January to June

  • DSO: Defusing the Binary Bomb
  • DSO: Dynamic Malware Analysis
  • NUS AY15/16 Semester 1

  • CS1101S Programming Methodology
  • CS1231 Discrete Structures
  • MA1101R Linear Algebra I
  • MA1521 Calculus for Computing
  • December

  • GitHub
  • NUSComputing.com
  • NUSBiZiT.org
2016


Contact Me



Affiliates

GlacieRaiN
ZongLong
BiZiT Society
NUS Wind Symphony

Organisations

NUS Computing Club
NUS Hackers


Archives

October 2015
November 2015
December 2015
January 2016
February 2016
March 2016
April 2016
May 2016
June 2016
August 2017
September 2017
October 2017
November 2017


Advertisement



Credits