0 Comments

This year the Developer Open Space took place in a new location: Basislager Coworking. (Of course I have that space in my portal: https://coworking-spaces.info/basislager-coworking-leipzig) The atmosphere has improved, especially since we could use the rooms without having to close for the night between Friday and Sunday. The organization was top as every year – thanks Olga and Torsten. It was a pleasure to attend – I like to go there every year. What follows now are short notes and summaries:

Workshop: JavaScript, React and GraphQL

  • we used Atomic Design to model our requirements
  • Mike lectured us about GraphQL, we dove into Apollo GraphQL
    • queries and mutations – separate components accordingly
    • GraphQL simplifies data details in the queries (in comparison to REST services, for instance): you can specify what data exactly you want to retrieve without having to create a new service endpoint for that (in REST you need multiple end-points for different types and combination of types)
    • GraphQL saves requests and data transfer, simplifies end-points
    • many Links possible: decide which service takes care of which queries (client, state, http)
  • Mikes library (see workshop branch)
  • GraphQL hub and playground
  • teamaton: We might use it for a side project, but it increases the complexity quite a bit (queries have to written and translated).

Session: Cypress

  • cypress is a framework for frontend testing which can be part of continuous integration (CI –> TeamCity)
  • is an alternative to Selenium (or coypu)
  • can run on headless chrome or electron, can run locally
  • LocalStorage in browser can be manipulated (for instance to simulate logged-in user), to separate testing concerns
  • cypress provides snapshots for each test step
  • build up a library example:
    • define features in cucumber (usually with QA)
    • reuse steps where possible
    • translate steps into cypress language
  • teamaton:We might want to write integration tests for important features and run them after each stage deployment.

Session: Time Tracking

  • HourGlass plugin for RedMine: connection to US/Bug –> immediate labels, open source, mobile App, Git integration
  • programmers do not really want to track time – only if needed, it needs to be simple
  • managers want to have a Freeze Time: everything what came before that (in that project) cannot be changed anymore (has been transferred to an invoice)
  • ManicTime: records which programs you have been working in – can be tagged afterwards
  • Netresearch TimeTracker: JIRA synchronization (JIRA could be an alternative for us to Zendesk)
  • teamaton: lemon: no example on marketing page (getlemon.com), so it cannot be shown very well (we had one in the olden times)
  • teamaton: An integration with PivotalTracker does not seem reasonable: Starting US/Bug in PT results in starting record in lemon, record will be stopped as soon as US/Bug is finished in PT. Too many exceptions I can think of. Code review and testing would still need manual starts/stops in lemon.

Session: Key Performance Indicator

  • formulate goals –> define success parameters –> measure (automated): predefine boundaries for “not good”, “good”, “very good”
  • for instance “delight customers”: What are success parameters for teamaton? How can we measure them?
  • ask customers what they want –> formulate goals out of feedback
  • feature development: KPI: estimation vs. actual hours
  • use KPIs for self reflection in team (for instance code issues per code line per person) –> celebrate successes
  • teamaton: Do we have a need to make “delight customers” more measurable? I generally like the “ask customers what they want –> formulate goals out of feedback” – if we think about finding out what portal owners want.

Session: BenchmarkDotNet

  • can be used after profiling to measure impact of changes in code
  • BenchmarkDotNet should only be used on code fragment / function
  • runs both code versions many, many times and compares results – can take some time
  • Could it be used in Continuous Integration? Maybe for critical methods which need to be fast?
  • teamaton: I think we do not need this.

Session: Azure, AWS, Google Cloud

  • abstraction of hardware and OS – no need to worry about these, you get CDNs
  • might cost more on the face of it, but you save admin costs, license costs, scaling costs (paying just what you are using)
  • Azure functions: lightweight processes
  • firebase alternative: heroku
  • teamaton: In the long-term we probably need to be more flexible and reactive: adding resources if portals need more, move quickly from faulty instance (server) to another one. Oliver’s proposal to use containers might be a beginning in mid-term. Maybe using VMs to faster setup environments could also help.

Session: ASP.NET Core

  • PageModel instead of Controller: controller and model in one
  • .NET Core is generally faster than .NET Framework: less legacy, re-implemented from scratch
  • teamaton: Use .NET Core for next new projects!

Session: How to Collect Requirements Well

  • path-to-requirementsflow: event storming and/or domain storytelling (customer with sales person) results in User Stories (one US per event or action), structure USs in Epics, add key specifications (gherkin: who+what+why) to USs, use Story Mapping to plan releases, refine USs with Specifications
  • create prototypes (sketches) for fast feedback
  • treat customer as part of the team: make sure team can contact customer with follow-up questions
  • teamaton: Maybe use event storming to show customer discoverize and see where customers process overlaps with our software and where customer needs more features.
  • teamaton: For more complex features we might want to use part of this flow: to better understand the needs of the customer, to address most questions beforehand, to make better architectural decisions, to implement features faster (because of better specifications).

Session: Nothing / Psychology

  • be aware of the psychology of words: for instance “technical debt” – you might want to use a different term, like “software betterment”, “actually ok” – address the reservations
  • men vs. women: there is a region “nothing” which only gets activated in men’s brains (in MRT): seems like men really can think about nothing if a subject does not fit a category (brain region), women jump from one category to another if something does not fit (I have requested more literature on this, because I could not believe that there is such a definite distinction between the sexes. Will read about that soon.)
  • “do sometime later” – We should ask ourselves: When is “sometime later”? Is it never?
  • How can you change the behavior of someone (for instance to use a clean code pattern)?
    • invite to make new experiences
    • be a good role model
    • prepare the change well
    • allow for as few obstacles as possible, so that that someone does not have to jump too high / change too much
  • try to do a meeting like an Open Space
  • teamaton: Do more DiscoTECH: might result in perceptive improvements, could lead to feeling of mastery (one of the key motivators for creative people: autonomy, mastery, purpose)

Session: JavaScript Frameworks

  • vue.js
    • has an extra GUI to create projects, add libraries, install packets, run server
    • similar to react/redux (state mangement)
    • HTML not inline, but in a template
    • change-management: looks like magic, difficult to grasp for big sites (simpler in react on component level)
    • relatively light-weight
  • ag-grid: table infrastructure for multiple JS frameworks
  • Angular:
    • a bit unwieldy, large
    • documentation not as fast as platform development
    • is here to stay: used by Google and Microsoft for projects
  • discordapp: many discussions about JS frameworks in forums, fast help with problems

Session: Team Organization

team-organisation

  • playing :) cooperative game (street kitchen) to test out different communication strategies (silence, without preparation, with preparation, with feedback loop, specialized, one meal per player, …)
  • best score when everyone has a specialization on one or two tasks, helping out the tasks in the chain before or after, with directions in-between the players

Session: Distributed Teams

  • use digital white board when brainstorming or talking about features
  • Visual Studio has live-sharing option: both people working on same machine, no need to merge
  • working in different time zones / during different times: it’s just a matter of getting used to
  • teamaton: information asymmetry due to people being in office or alone: tackle by posting a summary of discussions / infos in slack
  • teamaton: get together more often (do not forget to repeat Brzezno)

Session: Hands-On Configuration of a Azure Function

  • helping in a specific case: update information after every git commit to repository

Session: Objectives and Key Results

  • objectives should be inspiring, motivating to help team outperform
  • objectives should be challenging – therefore not often suitable for continuous development cycles (KPIs have been developed for product development)
  • choose objectives so that they are achievable in 50% of the cases
  • break down quarterly OKRs into 4-week priorities, and then into weekly priorities
  • objectives could be: customer satisfaction, code health metrics like not too many bugs, team satisfaction, number of unit tests
  • teamaton: Andréj already has looked into OKRs.

Session: Culture Hacks (did not attend)

culture-hacks-2

 

culture-hacks-1