30 March 2017

Coolpointer.011 : Creativity in 5 simple steps by Joseph Shaffery

    

    Joseph Shaffery is a Creative Lead in Orbit team where I work. Few months back he wrote an interesting article about creativity "Creativity in 5 simple steps ". He talks about few steps in creativity ,but my favourite one is  Embrace learning. He ask also question: Do we feel it’s okay to fail sometimes? 
    We always afraid of failing at work. Let's face it everybody sometimes make mistake and important thing is to learn from not only own failures but others failures without blame. Why? It helps whole team to be better bonded and more effective. 
  Embrace learning and experimentation and encourage lots of  ideas. There is no such thing as failure, only learning."



CREATIVITY IN 5 SIMPLE STEPS by JOSEPH SHAFFERY 
http://blog.invisionapp.com/creativity-in-5-simple-steps/





25 March 2017

Coolpointer.010: Why chinese website are so busy ?



In article WHY DO CHINESE WEBSITES LOOK SO BUSY  by JEFF RAJECK explains why Chinese websites looks so different from western websites. He points out few things :


  • Language difference. Jeff said that Asian pages use flash animation a lot to catch attention to user as language itself do not have this ability( This is due monolithic representation of characters)
  • Another reason that author suggests is an internet speed. 
    • It was truth in the past ,but it is not anymore.  In my opinion main reason is that this "ux pattern" that people learnt as way to find information. They go to this massive welcome page and using search functionality in browser they find information they look for . It was widely used on western website in late 90' like Yahoo ) .


So if you are interested in this subject, link is below :)

WHY DO CHINESE WEBSITES LOOK SO BUSY 
by JEFF RAJECK

FOLLOW AUTHOR:




20 March 2017

Coolpointer.009 : About Blizzard




I recently read and watch few things about Blizzard and their games.  Two of them; talk  "How Blizzard stayed laser-focused on quality games for 25 years" by Dean Takahashi and GDC talk "Diablo: A Classic Game Postmortem" by David Brevik  are worth to read and watch, if you are interesting in history of Blizzard, a company that develop many great games like Diablo and Starcraft (that I played) and many more that I didn't play but I admire their quality. What was outstanding about this company that quality of their game was awesome , their interaction with community is worth copy it  . 
    I am passive fan of Blizzard .I like watch their games like Starcraft and Hearthstone but I am not playing these games because I get too addictive from games.

My favourite part was not strictly Blizzard related, when David Brevik talks about his worst business decision ever. Watch this : Worst business decision by David Brevik .This is most funny part ( you must hear how he told this story)

"He came with idea: "I am going to make e-mail over internet. I offer you 10% of my company for one room that you are not using anyway."
David responded: "Dude, that dumbest idea I ever heard! (...) e-mail on internet? It doesn't have any sense. I already have e-mail on the internet. Yeah. that company was Hotmail. 14 months later was sold for 400 millions dollars that 10% could be mine,""


HOW BLIZZARD STAYED LASER-FOCUSED ON QUALITY GAMES FOR 25 YEARS by DEAN TAKAHASHI

DIABLO: A CLASSIC GAME POSTMORTEM by David Brevik


17 March 2017

What I learn from 014 conference talk: Pair testing by Raji Bhamidipati


BDDX ’2016 in London PAIR TESTING



    Sometimes ago, I  managed to watch Pair testing by Raji Bhamidipati from #BDDx'2016 and it was great. It was about pair working (from tester point of view).
It was interesting talk about pair working with focus on pair testing.

What I took from this talk :
  • Different styles of pair testing
    • Expect-Expert like Exploring tester with Security tester, where instead of going back with feedback and forwards . Time saved on loop
      Expert-Novice
      Novice-Novice works because they have different strategies so while
      Driver-Navigator
      Ping-Pong Pairing swapping
      Mob popular in testing. Group of people testing at the same time.
    • Advantages
      • Team building and collaboration
      • Share knowledge
      • Mix of skill set based on requirement
    • Disadvantages of pair testing
      • work overload
      • conflicts when paired incorrectly due personality incompatibility
      • do not let pair testing create favouritism or elitism within your teams. let's opportunities to everybody not only one person.
    • When to pair
      • training newbies
      • coaching and mentioning other team members
      • when deadlines approaching (dev-test pairing)
    • Common problems with introduction of pair testing
      • fair of change
      • not time efficient as 2 people are  doing the same task

    In my person opinion pair working is great for many reason (some of them are mentioned above) . I think communication and argument skills are one of the most important to improve while doing pair working. Communication seems be obvious but why argument ? Well , you need to learn how to argue to get best output based on comprise of few opinions without hurting. From my experience using pair technique in valid context generated much better quality code , less buggy  and give higher confidence to all stakeholders. It doesn't need be applied all the time as some people suggest.
    Anyway, if you haven't see this talk. It is worth check it out if you are interesting in pair testing (it applies to pair programming too).


    Follow Raji Bhamidipati on:














    11 March 2017

    IT'funQ.032

    What is it'funq ?

    "The idea is that everything is serviceable over the internet now, so they can just "fix it later", except they never do.."
    Author and source: 
    UNKNOWN (Internet, on some page, I don't remember where I took this originally ,but there are many pages that use that quote without  mention a source :(

    Coolpointer.008 - Classic Games Postmortem - XCOM: UFO Defense by Julian Gollop

    What is Coolpointer ? Check this : http://dominiksymonowicz.blogspot.co.uk/2015/12/coolpointerintroduction.html


    UFO: Enemy Unknown knows as XCOM: UFO Defense is my favourite game of all times. It was addictive and spooky game which waste more than 1000 hours in the past. I know for today's kids it is near zero, but back in 90' it was a lot. Anyway , I discovered talk by Julian Gollop one of the creator of XCOM and it was super interesting for me as fan of XCOM.
    Funny, enough I always wanted to write game XCOM'like with more RPG elements (more story telling , so people can attach to people who they play. 



    Classic Games Postmortem - XCOM: UFO Defense by Julian Gollop 

    3 March 2017

    What I learn from 013 talk: Code Review Matters and Manners by Trisha Gee and Maria Khalusova

        I watched an very interesting talk "Code Review Matters and Manners" by Trisha Gee and Maria Khalusova.
        A code review is a  process of  source code verification to check is code does what is supposed to do and is it meet criteria set by rules (acceptance criteria, quality and so on)
    Code review is an important technique,because:

    1. It helps me as developer to :
    • write better code
    • verify did I understand acceptance criteria correctly. 
    2. It helps code base to:
    • have better quality
    • to be consistent and
    • to follow agreed  approach and practices
    • increase confidence to other stakeholders (other developers, QA  and so on ) that code does what is suppose to do .
        In my opinion code review is very useful for above reasons. From my experience there is only one problem. A human factor and way how feedback is given. In my little work experience, it happens once when when I was annoyed by given feedback. Problem was with feedback that was given by person who behave like princess Goggle, where they are maniac about give as much as negative feedback as possible. Even for a minor detail and pretend this is always better. In practice large amount of time on detail that ... does not matter from functionality point of view.

    This talks covers how to do code review and how to give feedback.

    From this talk I learn ( re-learn or remind myself) about code review that:

    I should focus on:
    • Functionality :
      • Is it doing what is suppose to do ?
      • Is meet acceptance criteria and non-functional  requirements ?
    • Code usability:
      • Readability
      • Maintainability
      • Extensibility
    We  should NOT focus on little annoying things that can be automated . Personally I found this kind of things annoy people rather than helps.

    Code review is too late for design discussion and suggestion like:
    • Is it in right place?
    • Is it use right data structure , pattern ?
    • is code is overly complex or over-engineered?
    • Is use existing library or introduce new dependencies ?
    About Give Feedback I learn that:

    • You should have some code review manners rules written somewhere, where you should include things like:
      • Discuss changes, not people
      • Be specific
      • Suggest alternatives.
      • Don't be rude and don't offend people (directly or indirectly).
        • Example of offend people indirectly is by using words like obviously ,simply.
        • Refer to code not person This code not your code.
      • and so on.
        I read somewhere recently that "Learning how to deliver negative feedback effectively is crucial." I think it is worth to add it is important to decode useful bits from feedback. As was told by Maria during talk we should "be grateful for it and try to decode what person mean as written words do not reflect real intention". I agree with this. It is specially visible when you working in international team where people come from different  work cultures and they may have a language barrier when communicate.

       It is important to give feedback that focus on improve code based on agreed standards without blame or attack directly or indirectly person, because in the end our goal is to deliver good enough code that deliver value to product.

        I have a lot to improve with my feedback . I need use better and more accurate vocabulary and reduce amount of sarcasm as I am very sarcastic person.

    On side note. In order to write better code I am trying do code review in few ways.
    • I use IDE  (IntelliJ IDEA has awesome inspector feature) , Sonar and  plugins like Checkstyle and Findbugs 
    • I ask my colleague to double check my code (walktrough style) 
    • At work we are doing code review in real time during pair programming.
    That's all.

    Trisha Gee presence on Internet Universe

    Maria Khalusova presence on Internet Universe

    You can watch this talk here:
    https://vimeo.com/182087729

    22 February 2017

    What I learn from 12 presentation : 10 Usability Heuristics explained

    I read slides from Jakob Nielsen  titled "10 Usability Heuristics explained", where he points out few very useful points about usability. It is worth to read for beginners as it show them basics elements to think about it when design system that will be easy to learn (and remember) and how to use quickly and efficiently to complete tasks. 

    Jakob Nielsen is:
    "A web usability consultant. He holds a Ph.D. in human–computer interaction from the Technical University of Denmark in Copenhagen."

    From Slides I learn:

    • Status and communication from system should be always visible to user and should use user's language using common standards, being consistent and without technical gibberish. [Rules: "I know what's going on","I know what are you talking about","Seems familiar ,makes sense"]
    • System guides user what to do next and what are consequences. For example. It  should prevent user from making mistakes or at least warn it about possible consequences of the action.  [Rules: "I know what's going on","Glad , I didn't do that"]
    • System should always help user to recover if shit happens, so If user made a mistake, then system should have an ability to emergency stop/exit from current state. It should explain error in plain language and provide possible solution to recover . [Rules: "Oops, let's me outta of here","Glad , I didn't do that","I know what went wrong and I can fix it"]

    10 usability heuristics according Jacob Nielson are:
    • Visibility of system status ["I know what's going on"] 
      • "The system should always keep user inform about what's going on through  feedback "
      • In software development The system should always keep user inform about what's going on through  feedback.
    • Match between system and the real world  ["I know what are you talking about"]
      • System should speak user's language with vocabulary and concepts that user are familiar with.
    • User control and freedom ["Oops, let's me outta of here"].
      • User should have ability to emergency stop or exit ,if he made a mistake.
      • This is reason why for example memento(known as undo/redo) pattern is important when we develop functionality as it helps undo problem.
    • Consistency and standards ["Seems familiar ,makes sense"]
      • Follow the convention ,so user doesn't need to figure out that different word ,actions does the same thing.
      • It is important ,because it helps user to learn to use system quickly and efficiently.
    • Error prevention ["Glad , I didn't do that"]
      • It is good to eliminate possible error condition in first place ,where this is not feasibility ,then at least user should be warn and ask to confirm before he commit actions.
    • Recognition instead of recall ["I know what I need to do here "]
      • Minimize user memory's load  , user should remember enough to complete current action without remember about previous steps
    • Flexibility and efficiency of use ["Allow me to do more or less "]
      • Allow novice user to see essential data to make decision but allow to advanced user for customisation.
    • Help user recognise,diagnose and recover from errors ["I know what went wrong and I can fix it "]
      • Error messages should express in plain language and indicate the problem and provide suggestions to solve problem.
    • Aesthetic and minimalist design [" Looks good , works beautifully "] Dialogue should contains only useful information. Any extra unit inform that are rarely any value or no value will reduce visibility.
      • In my opinion design should fit audience. Aesthetic and minimalist design is good in generic cases but will not fit many cases. 
    • Help and documentation ["Okay , I need help "]
      • I don't have opinion about it. It is important to have tutorial to help user to teach basics skills need to find most information in intuitive way but documentation in general means System is too complicated (there are many cases when system is complicated because it performs very complicated tasks).




      Resources:

      30 January 2017

      What I learn from 011 talk: "Death by User Stories" by Jenny Martin

      BDDX ’2016 in London OOPSI MODEL


      It was an very interesting talk which focus on OOPSI model as way to do user stories and epics. It is a very interesting approach to describe work to do. OOPSI model shows one of the approaches to describe project.

      What I learn from this talk?
      • According to Jenny, user stories can be dangerous, because stories can be like virus. Virus has only one purpose, to reproduce. It multiplying until they overwhelm delivery. It is called a creeping scope.
      • Jenny used very interesting definition of acceptance criteria:  "Acceptance criteria define the boundaries of a user story,and are used to confirm when a story is completed and working as intended."  For Jenny, problem with them is that they looks like stories too.
        • I like this definition, For me Acceptance criteria verify understanding of task and define when a story is completed with enough confidence.
      • Catching large amount of users stories (as Jira ticket or post it note) on beginning on project is not  good use of time, because we cannot do enough analysis. It generates massive backlog that is not good use of time either.  it is  difficult to manage , many of these tickets nobody cares and they will be thrown away in the end. Many people doing this mistake of explosion of stories and output is similar or the same as  in waterfall.
        • I called this water-scrum-fall problem where we are using agile tools but we still deliver project in waterfall style.
      • Good thing about user stories are:
        • Act as a token for conversation, to discover value.
        • Helps us deliver things in smaller chunks, so that we can get value earlier.
        • Help us track and estimates work
        • Stories are to helps us understand what awesome outcome looks like.
      • Stories in Oopsi contains following components:
        • Outcome - it helps us focus on value and impact of the project that is describe as “In Order to xxx, As a xxx, I need xxx” (based on impact mapping)
        • Output - Illustrate output with examples without details but with general case
        • Process - where we split into Activities (linear)  tasks
        • Scenarios - Given,When,Then . A different path though process to generate the outputs (test cases)
        • Inputs - Inputs (concrete example and living documentation). Input and data needed to drive the scenarios.  Like test conditions or detailed examples.
      • Story mapping. It helps you to describe epic and split into deliverable chunks. Look for the picture of incremental delivery by henrik kniberg delivery to help you picture this point. ( http://blog.crisp.se/wp-content/uploads/2014/10/Screen-Shot-2014-10-07-at-08.20.00.png ) where from his blog when he talking about .
      • Other things that was mention in this talk:
        • Documentation is treat as a rude word in agile
        • Oopsi in reverse looks like  “Is poo”.
      I think, there  are many  bits and pieces that can be useful to use in the place where I work now as in my opinion, it will help deliver project smoother. Describing output through conversation  drives whole process into deliverable chunks of work. Story mapping is a technique that can help you do that. Oopsi can help you to have living documentation 



      23 January 2017

      What I learn from 010: talk "Testable Software Architecture" by Aslak Hellesøy

      BDDX ’2016 in London TESTABLE SOFTWARE ARCHITECTURE


      Aslak Hellesøy is creator of Cucumber. Cucumber is a collaboration and communication tool .It helps create living documentation. It is used as regression test but this is side effect.
      This is what I learn from this talk:
      1. Test should inspire confidence. In order to be confident about tests:
        1. They shouldn’t be any false positive or false negative. They can fail only, when system is broken).
        2. They must be lighting fast. 
          1. Fast feedback (you should not wait more than than 1 hour for test to complete. If test takes hours , there is an architecture problem.
          2. Remove all IO file/network  . No DB, No HTTP. No external architecture.
        3. Low cost (as Ken Beck said :  “I pay to write code (solving problems ), so I don’t want spend time to maintain tests. 
        4. They need be consistent and you cannot depend on third party ,
      2. You must have decoupled architecture to get confidence through tests. Decoupled architecture allowed you to swap elements. In testing you can swap real thing with fake. TDD helps you to write decoupled architecture.
      3. Low cost tests
        1. Cost of writing test.
        2. Cost of maintain test.
        3. Test should gives you precision what , why and where went wrong.
        4. If you CANNOT do above things if you do it through UI , because in the system UI changing all the time  . UI tests doesn’t give précised diagnose what went wrong. It is take long time to fix them.
      4. (I need to do more research about it) Fakes with Port and Adapter patterns. Use Adapter pattern for fake service. Fake service should be tested by contract that need be passed in real and fake implementation.
      5. What’s QA role ? Programmers writes tests  after QA design tests. QA do not write tests). Test are written before the production code. QA is involved from start by writing acceptance criteria based on requirements from BA and PO says. QA focus on prevent defects not finding them in later stage.
      6. Acceptance and regression tests should be automated because machine can do boring repeatable task, while QA could do more valuable things and perform  manual exploring tests.

      It was an awesome talk. I learn more about QA role and how I as developer should fit to testing part of developing lifecycle.