Alvin Ng alvinncx

If you happen to be reading the 20th anniversary edition of The Mythical Man-month, you can skip right to Chapter 18 for an outline of the entire book. Why this was added later is anyone's guess...

Chapter 2

Adding more people into a project that is overdue, makes it even later.
Throwing people at project without consideration of training, reallocation and communication is a disaster.

I used to apply the naive way of calculating time for a project. I was often wrong.
Eventually I found that using 4x the time of the initial estimates works well.
This is based on the assumption of degrees of freedom. If only developer is estimating, it is 2x original estimate. If requirements are incertain, then add additional 2x. This amounts to 4x.
Time for administration and ramp-up is often underestimated.

My thoughts on Sandi Metz's presentation on better OOP Design

Youtube Link

How to write better Object Oriented code. The central claim is that OO is not a problem, but many teams are not utilising the features of OO to design better code. Her other point is also that design becomes more important late stage as code bases becomes bigger.

Takeaway points

Premature design is bad. Does not really add value. However when design is required later, it is too late and most people don't know how to do it properly.
Code that is properly abstracted should be easier to change than complex routines. However, wrongly abstracted code can also make it as difficult at complex code.

Design in construction

Software’s Primary Technical Imperative is managing complexity. This is greatly aided by a design focus on simplicity.
Simplicity is achieved in two general ways: minimizing the amount of essential complexity that anyone’s brain has to deal with at any one time, and keeping accidental complexity from proliferating needlessly.
Design is heuristic. Dogmatic adherence to any single methodology hurts cre- ativity and hurts your programs.

Information Hiding

Foundation of OOP and structured design
Thinking in objects vs thinking in information hiding
- Hiding abstracts complexity and delays lock in; thinking in OOP locks you into smaller set of decisions
e.g. Should something be declared as a new class

Principles in Refactoring

Purpose of refactoring

Make the software easier to understand
Does not change observable behavior

Difficult to change

Programs that are hard to read are hard to modify.
Programs that have duplicated logic are hard to modify.
Programs that require additional behavior that requires you to change running code are hard to modify.

Sprint is a cycle lasts 4 weeks

Don't like the name, not sustainable
2 weeks more common
No gap or delay between sprints

Stages

Plan

Sprint goal

Valuable, clear, realistic, won't change

	# Configures the endpoint
	config :example, Example.Endpoint,
	...
	pubsub: [name: Example.PubSub, adapter: Phoenix.PubSub.PG2],
	...

	defmodule Parser do
	@moduledoc """
	Sample parser for data from DBS. It is annoying that there isn't a csv from DBS bank

	Sample data:

	18 Mar 2019 GRAB *16236905-9-139 S$23.00
	18 Mar 2019 GRAB *2B3B63422351042EE S$10.00
	18 Mar 2019 GRAB *1391705-9-138 S$15.00
	19 Mar 2019 2C2P - ZARA.COM SG S$29.90 cr

	import Browser
	import Html exposing (..)
	import Html.Attributes exposing (..)
	import Html.Events exposing (..)

	-- Main
	main =
	Browser.sandbox {init = init, update = update, view = view}

	-- Model

	class Price
	def price_code; end
	def charge; end
	def frequent_renter_points
	1
	end

	class Childrens
	def price_code; Movie::CHILDRENS; end
	def charge(days_rented)

	@mail_regex ~r/^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,4}$/
	@username_regex ~r/^(?=.{8,20}$)(?![_.])(?!.*[_.]{2})[a-zA-Z0-9._]+(?<![_.])$/