post mortem @ 5th August

personal-postmortem.md

Things I've learnt after 1 year of working abroad, alone

Software development

• Dont expect new stuff to work on the 1st time

  • New tools, new technology, new process, anything that you never tried before, you should expect you will fail at the very first time
  • This means you should generally be conservative on first try, try to experiment in small bits before fully commit into the new endeavour you are looking into
  • It also means you should not dismissed the new stuff on first try, as you're more likely to do it wrong at first, as a side note, I think human have a tendency to dismiss new ideas if it does not work at the beginning, which is why many things get popular because of conveniency/usability, rather than quality.

• Software architecture is more important that code design

  • I'll define Architecture as defining what and where, so it involves naming high level construct, and determine the interactions between them, but leave out the detailed implementations bit, which is solved by Design
  • From my very limited experience, you should put more time into designing architecture than code design, because once you got your architecture right, it's much easier to produce nice code design, but the reverse is not true
  • Changing Design is normally cheaper than changing Architecture because the latter tends to be built tightly into your system, eg. you cannot change the concept of User in the whole system without affect everything
  • Lastly, decision on architecture is more difficult to reach as it affect different stakeholder, so it's much harder to iterate quickly on architecture to correct your mistake

• Which part of communication is hard?

  • I think it's widely accepted that the most challenging part in enterprise software development is communication, which reasonate well with my experience
  • One important aspect is how decisions are make, I personally think technology team should accept the fact that you can't always please everyone, more often than not, people will have conflicting opinions, and the team should be prepared with that and have a solution when such situation occurs

    • I am a big fan of Jeff Bezos' Disagree and commit philosophy, I think every fast moving team should employ this strategy with your own stop loss criteria, whenever you are not able to reach an agreement, the team should

      * commit to a decision
      * create a strategy if it fails (you should have one most of the time)
      * define a criteria that indicates the decision is not working out
      

      This way you will be able to move on, get things done, and still have chance to correct your mistake quickly, most of the time, people dont agree with each other because we dont have a common perspective that's based on fact, committing to a decision would solve it.

      Disclaimer: I am speculating here as I havent try it out

Greed and Fear