Holistic Software Development
- 18:45 - 19:00 - Q&A session
- 19:00 - 19:30 - Piotr Śliwa - Holistic Systems Design
- 19:30 - 19:45 - Q&A session
- 19:45 - 20:15 - Wouter Lagerweij - Don't Refactor. Rebuild. Kinda.
- 20:15 - 20:30 - Q&A session
- 20:30 - 21:00 - Networking
Join us
if you are interested, curious or already convinced by an approach to software engineering that finds the sweet spot through inputting good models, processes and people in equal measure.
The inspiration for this approach came from the following three ideas:
- The separation between the business and software engineers is a superstitious fad of the past that should forever rest in peace.
- Many of the automation problems we solve through software building can be done in a predictable manner but to achieve this an organisation needs the right process and a culture of sharing knowledge at its core, combined with well trained, experienced team members.
- Most organisations can't afford low diligence solutions. However, they continue on this path because their competitors face a similar situation or their owe their existence to the non-software related aspects (Such as a pre-existing business deal with an airline if your business is selling flight tickets)
We believe in taking care of the three pillars of the holistic software design, those being a thorough model, processes and people that will help organisations satisfy the needs of their customers and make our lives as software engineers easier, rendering us accomplished, confident individuals, deeply immersed in society.
That is all well and good but how do these three pillars interact with each other?
Imagine you want to solve a business problem. Through engaging in discussion with businesses you gain a common understanding of the problem and concepts that best describe them (this process which fosters knowledge sharing with a humane touch, whilst working together shows bilateral respect)
You discuss issues together and suggest surface business' assumptions such as: "we believe the quick buy button will lead to a 2% rise in conversion." Combined with technical/modelling assumptions such as; "We shall change the existing sell-item subdomain and leave the product look-up subdomain untouched so as to sustain the current loose coupling between the two." (the discovery oriented process). Afters designing a good model to deliver the required changes at both the strategic - interaction between modules/subdomains - and tactical level - design of the code building blocks (thorough design processes backed up by knowledge and experience of working on such solutions). Together you plan a gradual delivery which tests the assumptions as quickly as possible (again discovery oriented process plus respect for customers who may not fully agree with our business assumptions.).
Thanks to experience, expressive design that mimics business concepts and the right processes based on discovery and knowledge sharing, you deliver with your team the necessary changes in a predictable way not only in terms of a schedule, but in terms of business outcomes.
Ok, enough about the general statements. In practice, during our meet ups we will cover a plethora of topics that are necessary for the holistic approach including:
- Tactical modelling of different problems based on object oriented DDD, FP, Enterprise Design Patterns, Event Driven Approach, Actors Model etc.
- Strategic modelling - especially in the context of distributed applications that are inspired by the concepts described in Evans' DDD book
- Efficient user interface design
- Dev-ops
- Organisation and practices to tackle difficult endeavours in a predictable manner
That sounds like a lot but there are still some topics we would like to pay a little attention to, in particular:
- Details about the programming language (but of course you are welcome to show design examples in the programming language of your choice)
- A very detailed description of frameworks and/or tools when necessary to show some design and/or building approaches
You are welcome to propose any topics and presentations that fit the subject or challenge its ideas.
See you there!
Speakers:
Wouter Lagerweij is an independent Agile Coach who covers the whole spectrum: from the technical practices of Dev and Ops, through process and organisation all the way to business and product.
He loves spending time with teams and organisations, from small startups to large enterprises, to figure out how to improve the way they make software, and make it more fun. To make that happen Wouter uses the knowledge and skills gathered in twenty years of experience applying Agile processes and practices from XP, Scrum, Kanban, Continuous Delivery, DevOps, Lean and Systems Thinking.
To turn those improvements into real business opportunities, Wouter has added Lean Startup/Lean Enterprise approaches. He's even been known to, occasionally, use common sense.
Web: http://www.lagerweij.com/
Twitter: @wouterla
LinkedIn: https://www.linkedin.com/in/lagerweij/
Piotr Śliwa - Solution Architect / Principal Software Engineer by day, Organization and Management PhD student by night, with a passion for colliding the two worlds to see what quarks are they built from. His goal is to break down the walls between engineering and social sciences, unveil the whole lotta fascinating discoveries hiding in between and explaining how does it all work holistically as the People+Technology Systems, and, ultimately, prove that the Answer to the Ultimate Question of Life, the Universe, and Everything is, in fact, 42. Likes planes.
Bartłomiej Witczak: "I believe there is no silver bullet. Everyday I try to learn new things and test different tools to be able to pick right tool for particular job. After gaining experience both in startups and enterprise companies, i understood that team work is key aspect to success. I'm totally fascinated by functional programming and I dig into functional domain modeling."
Bartłomiej Witczak - Types in Frontend world
Building large-scale JavaScript application is really challenging. Even JavaScript enthusiasts need to agree that developing and maintaining big frontend project is very demanding. Major changes to large codebases can be scary. There is no help in IDEs as well. Programming in JS being both dynamic and weak typed language doesn't really provide a safety net. There are several technologies that try to fill that gap and promise to make building scalable projects easier. TypeScript is superset of JS, which provides static typing and many other features. Flow provides type annotations, which helps to define signatures for objects and functions. Elm is a statically typed functional language that compiles to JS. During presentation I'd like to discuss those different approaches and if they can help us.
Piotr Śliwa - Holistic Systems Design
We will rewind to the roots of Systems Design in an attempt to extend the traditional, technology-centric approach with a more holistic perspective, encompassing non-technological foundations as well. We will try to find out how to drive such a Holistic Systems Design process in order to create software (and hardware) that is not only a technological gem but also serves as an efficient form of communication for the team so that it can focus more on making awesome things.
Wouter Lagerweij - Don't Refactor. Rebuild. Kinda.
Each and every time, the situation is the same: a big, messy code-base, few (if any) tests and many production issues. It's no accident that, when he joined what would be the first XP team, the first thing Kent Beck said was: "*Let's scrap it!*"
Even with a world class team, these problems can be almost insurmountable. And we don't usually start out with world class teams. Learning all the XP practices is hard enough without a Big Ball (of Mud) and Chain holding you back.
So maybe we *should* rebuild. But the Agile way: incrementally, iteratively, and with close involvement from the business.
Using examples from practice, I'll show that:
* We can set up a clear, loosely coupled architecture **around** the existing system, so we can replace parts *while its running*
* We are then free to use all our modern practices for the new parts, and start Continuous Delivery from the first sprint
* We can closely involve the business to surface the actually needed functionality, and build up Living Documentation in the process
* We can get even an inexperienced team using and accepting practices such as TDD and ATDD quickly