Developer Open Space 2018
October 23. 2018 0 Comments
- Posted in:
- Developer Open Space
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
flow: 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
- 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)
- how to hack the culture of your firm :)
- in real life: https://www.youtube.com/watch?v=2lXh2n0aPyw
