You're not connected to the Internet.
Company news 14103

How our software development is developing

The challenges of growth mean we need to make intelligent adjustments easily and quickly. The organisation has to keep adapting and so does the software architecture. Read on to find out what we’re working on at the moment and what topics we’re grappling with.

It’s been ages since I gave you an insight into the development work at Digitec Galaxus AG – too long ago, in fact. Perhaps you remember this article:

Some time has passed since then and in the meantime the development department has expanded from five to twelve scrum teams. This brings with it its own problems that have to be carefully addressed. Various challenges arise from that, and we don’t think these will reduce in the coming years.

As a result of the swift growth of the development department, we noticed growing inertia linked with the company’s growth and saw growing need for development to develop further. (That sounds logical… or like a tongue twister. You decide.)

The challenges

  • Over the last year, our scrum teams have grown from five to twelve.
  • We’re anticipating further growth in the development department in the next few years.
  • Many new members of staff require structured training.
  • There are increased demands on reaction times to application (performance matters).
  • We have to ensure scalability so we can up orders and user interaction.
  • We have to make complexity transparent with clear modules (bounded contexts) and clean interfaces.
  • The whole solution has to be transferred to the Cloud.

Making complexity manageable

It goes without saying that complexity is complicated. «Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple,» as Steve Jobs succinctly put it. Simplifying processes and problems requires not only technical knowledge but also detailed understanding of business procedures.

If a system is divided up in a strange manner, you just make the whole process unnecessarily more complicated. Instead, you could split it in such a way that you stay on top of things. Modularisation is good, but it’s not a cure-all. Creating purposeful modules doesn’t automatically remove complexity from the equation. It just transfers complexity to the interfaces between the systems.

In an ideal world, there would only be a few interfaces that would be as stable as possible. This would let teams concentrate on the work in one single module, rather than having to worry about the rest of the application.

Complexity can only be reduced when the requirements and capabilities of the system are reduced. Consequently, the primary goal isn’t to reduce complexity but to keep it under control.

How do you make it easier to keep control of complexity?

The theory:

  • Partitioning involves splitting the whole system into various subsystems and having these communicate with each other using clear and simple interfaces.
  • A clear hierarchy of the subsystems lets you review the whole system and gives clear dependencies and interfaces. This also makes it easier to correctly prioritise.
  • Independence of individual subsystems allows you to focus on the responsibility of each of these systems.

What I think are the important takeaways:

  • We should remove any unnecessary processes and tasks that don’t add any value for the customer. After all, easy things can also be made complicated and bureaucratic. That is the definitely the most important point.
  • We should bring the focus back to the customer. We need to ask if it benefits the customer and if so, if the the benefit is comparative.
  • We need to look at our prioritisation process and ensure it has a clear strategy and vision.
  • Everyone can contribute by complaining about complicated processes and discussing relevant problems in the open. But it is important that we don’t go looking for irrelevant problems.
  • Flat hierarchies and team-oriented processes are essential.
  • Responsibilities should be delegated amongst teams as much as possible.
  • We should be able to make clear decisions in cases of doubt, even if not everyone is in agreement on a certain topic. Otherwise we could get stuck for ages, as there isn’t just one answer to any problem.
  • We need take a constructive and optimistic approach and think about problems as being there to be solved. Even solutions can bring new problems to light. This is every engineer’s dream – it’s what makes them tick ;-).

How do we deal with challenges?

Here is a quick look at what happened at Digitec Galaxus AG in the last 15 months. You also get a sneak preview of what we have planned to further grow our development department.

Specialisation according to domain

The scrum teams were given a specific domain – in other words, a specific business area, such as logistics, product management or the online shop. This meant each team could specialise in their domain and develop improved and more elegant solutions thanks to a greater depth of knowledge. Each business area is normally represented by a department. The development teams work as closely as they can with the relevant departments to find out how to generate the most added value for customers with the current options. It’s also very important for us to have the most stable teams possible. Ideally, teams should work so well together that they’re in the zone.

Interdisciplinary teams

Our teams are no longer comprised of just software developers. We think it is important to combine all of the skills needed in the domain or subdomain. For instance, our online shop team includes interaction designers and front-end developers. Depending on the context, there may also be a requirements engineer, business intelligence specialist or systems engineer. The purpose is to reduce interfaces and shorten communication paths. A set-up like this should let teams work independently and stop them being held up by any obstacles.

Coaching new teams

On the whole, we build new teams from new members of staff. This stops the team makeup forever changing and ensures greater stability. To get staff trained and up to speed quickly, we give them a coach who covers specialist knowledge and methodology. Each new team is assigned a software developer who knows our environment inside out. They stay with the team for a set amount of time so they can answer any questions. A coach also focuses on the methodical side with the whole team when they’re working on scrum and agile software development.

Skills and individual responsibility in teams

It’s vital that every member of staff has the relevant information at their fingertips so they can work as enterprisingly as possible. This means that there is almost no company information that isn’t available to employees, be it our strategy, mission and vision or the results of staff surveys. This lets everyone check that what is supposed to be done is, in fact, in line with the company strategy. We think all our staff should know what kind of service we want to offer our customers. Our value proposition is public and transparent, meaning every customer can see how we measure up when it comes to performance versus promise.

Cloud strategy

Advances in technology have led us to the conclusion that the future lies completely in the cloud. Even today, new features are first or exclusively offered in the Cloud. With the multibillion investment in various Cloud platforms, this is set to further pick up pace. We won’t be relying on one sole provider to use Cloud services but on several. The deciding factors for us are the flexibility and innovation you get from the Cloud. That’s why new services will only be developed there. This will also be the case for overhauled business areas. We’ll be moving them as much as possible to the best Cloud platforms. At the moment, we have a few services on the Google Cloud Platform, Microsoft Azure and Elastic. Any parts of the application that haven’t been adapted will still run on our dual data centres on the premises. It doesn’t get more hybrid than that. This is yet further justification for the increasing importance of DevOps and why it is only set to get more important in future. After all, in the Cloud, infrastructure will be part of the application.

I can’t think of any more changes at the moment, which probably means this article is already too long. With that, I had best sign off and try not to leave you waiting too long for the next update – well, not for a year. At least if I do that, I’ll be less likely to forget what has changed.

Find out more about our software development

Want to join us as a developer?

We want to be able to develop even faster. If you like the sound of our vision, you may be interested in one of the jobs in our development department. It goes without saying that growth comes with an array of challenges. But if you’re the right fit, we know you’ll want to roll up your sleeves and get stuck in.

User
Cool: Creating interfaces between the real world and the world of pure information. Not cool: Driving by car to the mall to shop. My life happens online, the information age is where I feel at home.

14 comments

User Athrandir

Ein Kompliment an alle Entwickler, Architekten und Designer bei Digitec. Die Nutzung Eurer Plattform macht nicht nur Spass sondern ist auch Inspiration. Man merkt als Nutzer sofort, dass hier Hingabe dahinter steckt - deshalb auch der Vorsprung gegenüber den Plattformen globaler Mitbewerber.

11.10.2017
Report abuse

You must log in to report an abuse.

You must be logged in to reply to a comment

User juhahartmann

12 Teams mit Scrum? Vielleicht bald Zeit auf SAFe umzusteigen ;)

09.10.2017
Report abuse

You must log in to report an abuse.

User raphaelrenaud

Ist schon Realität: digitec.ch/de/page/wie-entw...

09.10.2017
Report abuse

You must log in to report an abuse.

You must be logged in to reply to a comment

User reinhold86

Wie gross sind denn eure Scrum Teams?

09.10.2017
Report abuse

You must log in to report an abuse.

User Oliver Herren

Die sind zwischen fünf und neun Personen gross.

10.10.2017
Report abuse

You must log in to report an abuse.

You must be logged in to reply to a comment

User ianazch90

What technologies are you using (programming language(s), framework,...)?

03.11.2017
Report abuse

You must log in to report an abuse.

User witold.baryluk

Looking at job offerings it looks to be mostly C#, ASP.NET, MS SQL. I have no idea how well it scales, but is probably costly in the long run. And moving this to cloud is probably limited. For the frontend, I have no idea. Would be nice to have so ideas about architecture, caches, load balancing, etc. (I see static content is mostly stored in Akamai caches).

14.11.2017
Report abuse

You must log in to report an abuse.

User Tobias Käppeli

Like Witold.baryluk said. We mostly use C# ASP.NET and MSSQL.
Other technologies we use are:
- Javascript. The frontend team wants to go an isomorphic approach in the future.
- .NET Core for our newer projects
- Elasticsearch, Logstash, Kibana for search, filtering and as key/value store.
- MSSQL for all relational databases and as Datawarehouse
- Azure Service Bus is coming soon as new messaging service
- Application Insights for Logging
- Akamai as CDN
- BigQuery, DataProc, Datastore, Dataflow in the Google Cloud

For Development we use:
- Visual Studio 2017 or Rider
- Visual Studio Team Services for Git Repositories and Continuous Integration
- NDepend and SonarQube for code analysis

@Witold.baryluk the move to the cloud is getting a lot easier when we migrate more of our code to .NET Core and start using Containers for those workloads. The recently released version 2.0 of the .NET Standard should help here.

17.11.2017
Report abuse

You must log in to report an abuse.

You must be logged in to reply to a comment

User zilti

"Die Komplexität kann nur reduziert werden, wenn auch die Anforderungen und die Fähigkeiten des Systems reduziert werden." - Ein Trugschluss! Komplexität zeugt von unpassenden Herangehensweisen, nicht von Systemanforderungen.

11.10.2017
Report abuse

You must log in to report an abuse.

User daniel.tobler

Ich unterscheide zwischen Komplexität, die Anforderungen geschuldet ist und "Accidential Complexity". Für erstere gilt das Zitat im Titel. Die zweite Art der Komplexität, die ich auch häufig antreffe stammt von falschen oder falsch angewandten Technologien, Unwissen, falschen Wissen, von "gut gemeint" und Realisierung von Anforderungen, welche gar nie Anforderungen waren oder dessen Funktion dann doch nie gebraucht wurde.

22.10.2017
Report abuse

You must log in to report an abuse.

User jacksuisse

Sprachlich sollte man differenzieren zwischen komplex und kompliziert. Dann gibt es da auch keine Missverständnisse. Für den richtigen Umgang mit Letzterem braucht man vor allem Kompetenz.

14.11.2017
Report abuse

You must log in to report an abuse.

User rg

Die Unterscheidung zwischen kompliziert und komplex ist uns wohl bewusst. Sowie in einem System eine gewissen Anzahl von Menschen stecken, ist es komplex. Ein Online-Shop im E-Commerce ist korrekt formuliert ein soziotechnisches Ökosystem. Es interagiert mit den Benutzern in vielfacher Weise und spricht den Menschen auch emotional an. Daher ist dieses System an sich schon komplex. Kompliziert ist zum Beispiel die Aufbereitung der Bestellungen in Versandeinheiten. Dies ist ein Algorithmus.

17.11.2017
Report abuse

You must log in to report an abuse.

You must be logged in to reply to a comment


Please log in.

You have to be logged in to create a new comment.

Corporate logo