A Brief of My Thoughts and Beliefs regarding development of software – and other things.
January 2020, a winter resembling a mix of late autumn and early spring (stretching February – why is it so hard to finish this article? 😊
Finishing off, end of August, it was a long summer “holiday”, and now the need to transfer the writings from Word into wordpress, always a pain, another obstacle to fight..
Apart from being a believer in test driven design, quick feedback loops and delivery of real value…
I believe in Magic.
Reading and understanding; the article “Programming as Theory Building – by Peter Naur”, the book “Design Thinking – by David West & Rebecca Rikner”, the concepts of “Mob programming – by Woody Zuill” and “Domain Driven Design – by Eric Evans”, pretty much sums up my core beliefs regarding development of software, systems, products and teams.
Perhaps the most important, in software products, is to create a ubiquitous language, connecting business and programmers with a common understanding of the domain, pushing the development into the domain knowledge space; with this in place there is a good chance of doing the right thing.
All above, together with the many other optional tools born in the thriving community around DDD Europe – I am convinced magic things will happen.
- Software development – is all about the outcome based on the theories built by one or more persons, often a team; a team is all the people involved, such as experts, developers/programmers, users and other stake holders that can affect the team and the product.
- The actual fit – of the outcome of an implementation in the real world, is highly effected by the designers understanding of the problem space, the current system and the wanted state, and the designers abilities and his intentional alteration of that system by adding, removing or changing some part(s) while hoping for the intended outcome.
The question of when and how well a solution fits, hints that short feedback loops are extremely important during the design, prototyping and implementation of a system – unfortunately many teams don´t work with feedback until they deliver a “ready to ship” product or feature.
- Mob programming could be compared to modern processors with multiple cores. A single brain does not have the same capacity, for thinking and exploring, as two or more brains do; therefore, I see this as a fundamentally better way to do qualitative knowledge work, while also gaining social stimuli, and providing a more challenging and creative environment.
I believe one of the reasons we left the mob programming style in favour for individual work is due to management seeing software production as something that can be broken up to a manufacturing production line, and when computers became less expensive than people this was a natural step in the “factory setup”; this is in many ways how “teams” work today, even “agile” teams, with a Kanban board and tickets for as small tasks as possible, sometimes even broken up by “upper level people”.
- Trust – the more we know the people we work with on a personal level, the more we trust them for their proven track record; working in tight teams forces you to become closer.
- Flow – according to science, the most fulfilling type of flow is achieved in collaboration, like in a football team or solving problems together with colleagues. I believe it is also easier to maintain a flow state in a group of engaged people, than when working alone – especially if working “alone” in an open plan office
- Magic teamwork – when work becomes teamwork, work becomes play; when work is play, work becomes fun; when work is fun people get on fire; when people get on fire by doing work they love – magic things starts to happen. I want magic teamwork in any game I play.
Reading “Design thinking – The key to enterprise agility, innovation and sustainability”, by David West and Rebecca Rikner gave me an awakening, of some kind, realizing who I am and what lights my fire.
I have always loved to understand how things work, fascinated by the beauty of nature and in love with functional design. Being creative with my hands since childhood, forming for usability or mimicking nature, I guess other paths could have led me to become a carpenter or architect (of buildings).
This is me, Design Thinking + IT Thinking + Business Thinking
When I opened this page, it was like Dave had picked my brain and soul and found my core interests, background and future.
An “explanation” of the mapping I see when I read this picture…
A former colleague told me “you are an organizational genius – that’s just how it is”, others have said “You are extremely quick in picking up and understand the core of the overall system”.
I studied to become avionics engineer and liked the idea of fixing airplanes but didn’t love it, so I moved on.
I have studied business finance and liked the accounting but loved the marketing and had fun, with my friend, creating print and web marketing for restaurants and nightclubs – and a golf course panorama overview (long before street maps).
I have studied history of arts and design, materials and production techniques, and liked the ideas of Lean manufacturing but loved the creative process of product design with brand recognition.
I have worked in many non-IT related areas such as mechanics, manufacturing, sales, support, warehouses, and in a variety of IT related areas such as tech support, infrastructure (servers, network etc.), and since 2013 in different software development teams, mainly in product companies but also as consultant.
Wherever I have been, I have seen ways to improve things, like management, the way of working or the physical working environment – in most of the places I have left a footprint, either by changing a process, way of working, or at least by challenging the ways of doing things. If needed I also act as a secret janitor to fix or improve things at the physical work place just because I care about my environment (have problems with broken and filthy things, not OCD but probably closer than many 😉)
I need to feel joy and ease in my working environment
To be continued… part 2 in this context is about ”Teams – and groups”