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



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


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.


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



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.


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


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.


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.


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.


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.


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.


Task cards

Estimate the time taken for each feature and put them into 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



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


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

The Hacks


    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

Contact Me


BiZiT Society
NUS Wind Symphony


NUS Computing Club
NUS Hackers


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