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.
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.
Breakdown of roles
ArchitectureColin says we need one person in-charge to coordinate the input of the other team members (e.g. technical proficiency).
ProgrammingThis 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.
DocumentationColin also emphasizes the importance of documentation. We are not likely to remember what we have programmed some time ago.
FeaturesIt 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 AssetsDesigners should consider expanding their skill set beyond Photoshop. For example, Illustrator.
DocumentationNon-programmers should still be familiar with the product and be able to write user guides at the minimum.
SalesConducting 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 marketingA 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.
LeaderThe 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 modelStep 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 modelThe 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 processThe 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 processThis 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
- Big dream
- But rank the features
- Look at your team (make use of their proficiency)
- 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
- Sub-systems (e.g. a system of micro-services communicating with each other)
- Layered hierarchy (e.g. inheritance, module imports)
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.
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.
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.
Roles in Scrum
Decides what will be included in each of the releases. Somewhat like a client and more of a requirements person.
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.
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.
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.
1 comments | Leave a comment
Monday, 14 August 2017
I hope to learn:
- Making something really useful and sufficiently complete, unlike my personal side projects
- Experience the whole process of design and implementation
- How to engineer a product in a team, instead of doing it alone
- Different perspectives from people about UIUX
- Discipline in creating quality products
- More about various frameworks and libraries, and the philosophies behind them
- More about Facebook API design and usage, never managed to understand such APIs (including Google's) back then
- To find and correctly implement or debug programs based on the answers from the internet