In my journey, from being a Developer up to my current career level as Technology Manager, I stumbled into the field of marketing several times. Mainly because the sales team was working on a big opportunity and that customer-to-be had more serious technical questions as the salesman tech-book provided answers.
That is not only where I learnt to manage expectations of all parties, that is where I realized: These marketing guys love “disruption”, “USPs” and “unique, individual approaches”! But what they really need is standards!
No, hear me out on this! I am not talking about “Out of the Box” standards! I am talking about standardized processes and procedures in software development for the efficient achievement of goals. And yes, working in an agile environment like in netz98, it is “people over processes”. Let us see how we can resolve this perceived conflict of interest.
Perceived? Yes, because we are talking about two different things that often get thrown together because we use the same words for them. When I talk about standardizations, I am talking about the creation of the environment and not the usage of the environment. Let me explain!
As one of Germanys biggest Magento agency, netz98 has many active customers. Since resources, sorry, developers are limited, we struggle to implement a unified “One team per customer” workflow, where a developer only must care for one project on a given time. And with several developers working in several projects we find our first issue: Each project IS individual. Each project comes with different setups and complexities. The developer working on n projects needs to config and maintain n development-environments on his machine.
Frontend developers, even the brilliant ones, and I do not want any trouble with you guys – that is just my experience, often have problems with system setup when for example managing multiple nginx or Varnish configurations on a Linux or MacOS. But also, many backend developers are brilliant developers, but they do not know how a nginx.conf file must look like when handling multiple configurations.
And do not get me started on Magento setups. There are literally thousands of configurations possible and in a worst-case world, every developer on one project has different nginx configs, different or none varnish configs, different Magento settings and therefore a billiontrillion possibilities to f**k things up.
So, we want to create individual, unique and disruptive solutions, but since everything around us is individual, unique and – given some nginx configs I have seen – disruptive. It is hard to focus on the real issues when also “works on my machine” becomes a bad habit. We want to focus on people, not on processes. So we have to create an environment that makes enables people to focus on things that matter!
Our CTO, Christian Münch, calculated that with every project, we lose up to 10 days of development time because of bad configurations and missing standards. Even through he created a fool-proof Magento Project-Setup skeleton, there were still developers with … let us call it “individual setup issues”. And that is the guy behind n98-magerun, so you know this Magento Project-Setup skeleton is serious business!
That was until he stumbled over ddev (https://ddev.readthedocs.io/). ddev is an open source tool that makes it easy to create local PHP development environments up and running within minutes. – At least that is what they say on the project website. But talk is cheap, so he gave it a deep dive…
ddev uses docker to create per-project environment configurations, which can be extended, version controlled and shared among the teams. At the end of his deep dive, we rolled our new netz98 ddev setup out on all teams and projects. Additionally, he created standards for most-used services and setups, and created implementations for our QA workflows, so that these workflows are now a uniform component of every project setup.
Which brings us back to the statement from the beginning of this text: Standards enable and support individual solutions.
The solution itself should still be an individual one, but the environment in which this solution is created must be highly standardized so that each member of a large team can work under the same conditions and the same prerequisites. That is why, when my customers tell me about their disruptive ideas and their unique selling point, I always say “Great, let us create a standard for it!”
A standard environment, that gives each project member the power to focus on the complexity of the solution, not the complexity of the environment.