Marco Meisen (agilegemba.wordpress.com) and I held a talk on Shopware Community Days. Shopware Community Days is one of the largest eCommerce conferences in Germany. The shopware AG (a provider of open source shop software shopware) had invited their customers, open source community members, service providers and speakers to Ahaus, near the border of Netherlands.
Our talk is based on my article “Process Kintsugi – repair what is broken“. We enjoyed the great athmosphere and the futuristic architecture. Thanks for the invitation!
You can find more details about the talk on Cassini-Homepage.
I love cooking and I enjoy spending time with my friends and family. But cooking is not always trivial. Everything more complex than scrambled eggs can not be done by just putting all ingredients in a pot and waiting until it’s done. Cooking is a process of mixing right ingredients at right temperature with appropriate dishes. As a cook you often taste the meal to make sure that it evolves to a meal you want it to be. It is the cycle of adding ingredients and tasting the meal, that makes the cooking a great experience. And when the air is full of smells of different spices, vegetables, fruit, wine, and fish. Hmmm….
Making a good architecture for a complex system is like cooking. First you need some planning to find out what kind of meal you want to cook (what do we want to build). Than you go shopping to buy all ingredients you don’t already have at home (COTS, Tools). And only than you can start cooking. Step by step, either from the experience or by following a recipe (best practices), but never by mixing everything at once. You can even do it together with other people, and make the process a part of the collaborative experince. So learn how to cook, experience new flavours and have a delicious dinner in the end 😉 Bon appétit!
When you take a look around your company, the best people around are probably in their mid-thirties and have 10 and more years of experience in whatever they do. They’ve probably seen it all, exciting, dead-march and challenging projects.They’ve reached everything developers can reach in their careers so eventually they start to ponder. Are we doing the best we can? Is there a way to do things better than we currently do?
It is no longer definitively apparent as to whether the prominence of agile methodologies or the change in society are the trigger for the mindset change. But most of the peple I’ve talk to strive for change. They want to do something new, meaningfull and interessting. And most of them want to become self determined. And if they can’t, they look for ways outside of their companies, leaving empty chairs. “I want to make the world a better place.” – a friend of mine told me before he left the company.
There is a growing demand throughout the development world for adoption of agile methodologies. Companies which stick to established practices, e.g. pure waterfall; top-down management etc., will loose their best people on companies which adopted or are currently adopting agile. People working in agile companies describe the work as happy, interessting, and active, with a strong desire to do the work. What about your best people? Are they happy with status-quo?
Software models are subjected by our inability to comprehend them by just looking at them. I’ve seen many plausible models which turned to be wrong as soon as they were fed with data.
Software is a simplified abtraction of the world designed to get the work done, at least in the business environment. To define all needed entites, we build formal and strict models which play a crucial role in the knowledge exchange between IT and business departments. Models are IT-focused, regardless how much information we ommit for simplification. Therefore it is sometimes hard for the business to understand all the subtleties of the IT model language (e.g. UML).
Tests are a good way to check the validity of models. When it comes to creating the test data, we rely more on the business than IT, because the test data are business-focused. The models help define the structure of the data, but only while creating the test data the business department can grasp the complexity of the model and find out what is wrong with it’s structure.
Therefore it is inevitable to engage business in the test data construction. Don’t generate syntetic data from models, use data from the real world scenarios instead. Let the tests shape the way you view your business.
Imagine your software development process is broken. If you can not make a configuration, build, run unit and integration tests and deploy your software, your process is broken. All these activities require extra effort to fix, thus they prevent you from making progress. We tend to ignore and hide things that are broken.
But don’t give ’em up, don’t just throw them away. Do process kinstugi – repair everything with gold.
In Japan, people don’t throw away broken pottery if it’s valuable or has a moving history. Instead they repair it with a gold lacquer. The items become even more beautiful for having been broken.
If we manage to set up decent QA with code reviews, continuous integration, automated testing, deployment automatization etcetera, we can make the broken parts of the development process shine. The broken parts will stand out and In the long run, they will speed up the development. See the broken parts of your process as a chance to make your organization a better place to work by continually exploring new ways to maintain and improve quality standards and applying best practices.
What would you like to repair in your working environment?
“So much has been done — more, far more, will I achieve: treading in the steps already marked, I will pioneer a new way, explore unknown powers, and unfold to the world the deepest mysteries of creation…”
— Victor Frankenstein
A lightning strike on an oak tree and the death of his mother inspired mad scientist Victor Frankenstein to continue working on his experiments to reanimate dead tissue. He dreamed about a beautiful creature, but instead he created an eight foot monster. The creature itself has often been mistakenly called “Frankenstein” but it actually has no name. Victor refers to it in the novel
as a “monster”, “fiend”, “demon” or “it”. When speaking to Victor, monster calls himself “Adam of your labour”.
What is most intriguing about Victor Frankenstein, is not only his knowledge at chemistry and other sciences, it is his deliberate decision to create something really fascinating and new. He uses experimentation to validate his crazy ideas. I want to be like him. My IDE is my laboratory, unit tests the lightnings. I just love seeing my ideas coming to live. Only by experimenting I can decide which one is a good one. I fire tracer bullets, I refactor, I apply TDD I write Mocks and I write working code. I am a mad architect.
Or am I just an ordinary architect? Shouldn’t every architect test the ideas before sharing them with others? Is your architect writing code? Do you? What are your experiences?
I have a confession to make. Few years ago, I did something I’m not very proud of today. I taught waterfall. Back than, there was a lot of mess going on. Most (if not all) systems were monoliths, object orientation and design patterns were new to most of us and even source configuration management was a great unknown to most developers I worked with.
Waterfall was a great deal. It enabled us to create the overall project vision, to narrow the focus of developers on what is really important and it allowed management to define project cost and schedule based on project plans. It still works for many projects and organizations. Yet, since few years we know that there is a better way to make software, Agile development. And so we try time and again to prove how much better agile is compared to waterfall. And I believe that this is why it is so hard to implement agile in waterfall organizations. For some organizations waterfall still works and they are not ready yet to throw their standard procedure aboard.
Instead, we should concentrate on importance and benefits of being agile. Agile is not the solution to all waterfall problems, it is only the next logical step in the evolution of software methodologies. So don’t stigmatize waterfall, because it is a prerequisite for the emergence and success of agile.